Você está na página 1de 477

ITIL Verso 3

Design de Servios

ITIL V3 - Service Design - Pgina:

1 de 477

O Core ITIL composto por cinco publicaes. Cada uma


delas fornece a orientao necessria para uma
abordagem integrada, tal como exigido pela ISO / IEC
20000 padro especificao:

Estratgia de Servio
Design de Servios
Transio de Servio
Operao de Servio
Melhoria de Servio Continuada.

ITIL V3 - Service Design - Pgina:

2 de 477

INDICE
Prefcio ............................................................................................................. 10
Prefcio da OGC........................................................................................................... 10
Prefcio Arquiteto Chefe............................................................................................... 10

Prefaciar ............................................................................................................ 12
Informaes de contato ................................................................................................ 13

Agradecimentos................................................................................................. 14
Arquiteto-chefe e autores ............................................................................................. 14
ITIL autoria da equipe ................................................................................................... 14
Mentores ....................................................................................................................... 14
Outras contribuies ..................................................................................................... 15
O ITIL Grupo Consultivo .................................................................................................. 15
Revisores......................................................................................................................... 15

1 Introduo ...................................................................................................... 16
1.1 Viso Geral ............................................................................................................. 18
1,2 Contexto .................................................................................................................. 19
1.2.1 Gesto de Servios ................................................................................................ 19
1.2.2 Boas prticas no domnio pblico ........................................................................... 19
1.2.3 ITIL e boas prticas em Gesto de Servios .......................................................... 21
1.2.3.1 Estratgia de Servio .................................................................................................. 23
1.2.3.2 Design de Servios ..................................................................................................... 23
1.2.3.3 Transio de Servio .................................................................................................. 24
1.2.3.4 Operao de Servio .................................................................................................. 24
1.2.3.5 Melhoria de Servio Continuada.................................................................................. 24

1,3 Propsito ................................................................................................................. 26


1,4 Uso .......................................................................................................................... 26

2 Gerenciamento de Servio como uma prtica ................................................ 27


2.1 O que Gerenciamento de Servios? ................................................................... 27
2.2 O que so servios? ............................................................................................... 29
2.2.1 O valor proposio.................................................................................................. 29

2.3 Funes e processos atravs do ciclo de vida ...................................................... 30


2.3.1 Funes .................................................................................................................. 30
2.3.2 Processos ............................................................................................................... 30
2.3.3 Especializao e coordenao em todo o ciclo de vida.......................................... 31

2,4 Projeto fundamentos Servio ................................................................................. 33


2.4.1 Finalidade objetivo / / objetivo................................................................................. 33
2.4.2 mbito .................................................................................................................... 33
2.4.3 Valor para os negcios ........................................................................................... 40
2.4.4 Otimizando o desempenho do projeto .................................................................... 40
2.4.5 Processos dentro de Design de Servios ............................................................... 41

3 Projeto princpios do servio ........................................................................... 43


3,1 Metas ...................................................................................................................... 47
3,2 projeto equilibrado .................................................................................................. 48
3,3 Identificar necessidades de servio ....................................................................... 51
3,4 Identificar e documentar os requisitos de negcios e motoristas .......................... 53
3,5 As atividades de projeto ......................................................................................... 56
3,6 aspectos de design ................................................................................................. 58

ITIL V3 - Service Design - Pgina:

3 de 477

3.6.1 Projetando servio de solues .............................................................................. 59


3.6.2 Projetando sistemas de apoio, especialmente o portflio de servios .................... 62
3.6.3 arquiteturas de tecnologia Projetando .................................................................... 67
3.6.3.1 Gesto de Tecnologia ................................................................................................. 74

3.6.4 processos Projetando ............................................................................................. 79


3.6.5 Projeto de sistemas de medio e mtricas ........................................................... 82

3.7 As seguintes atividades de design ......................................................................... 86


3.7.1 Avaliao de solues alternativas ......................................................................... 86
3.7.2 Aquisio de a soluo preferida ............................................................................ 86
3.7.3 Desenvolver a soluo de servio .......................................................................... 87

3,8 restries de design................................................................................................ 88


3,9 Arquitetura Orientada a Servios ........................................................................... 90
3,10 Business Service Management ............................................................................ 92
3,11 design modelos de servio ................................................................................... 94
3.11.1 modelo opes de entrega ................................................................................... 95
3.11.2 Design e opes 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 solues ............................................................................................. 103

4 design processos de servio......................................................................... 105


4.1 Gesto Catlogo de Servios ............................................................................... 108
4.1.1 Finalidade objetivo / / objetivo............................................................................... 108
4.1.2 mbito .................................................................................................................. 108
4.1.3 Valor para o negcio............................................................................................. 108
4.1.4 Polticas, princpios e conceitos bsicos............................................................... 109
4.1.5 as atividades de processo, mtodos e tcnicas.................................................... 112
4.1.6 Triggers, entradas, sadas e interfaces................................................................. 113
4.1.7 Gesto da informao .......................................................................................... 114
4.1.8 Indicadores Chave de Desempenho..................................................................... 114
4.1.9 Desafios, Fatores Crticos de Sucesso e riscos.................................................... 114

4.2 Gesto de Nvel de Servio .................................................................................. 116


4.2.1 Finalidade objetivo / / objetivo............................................................................... 116
4.2.2 mbito .................................................................................................................. 117
4.2.3 Valor para o negcio............................................................................................. 118
4.2.4 Polticas / princpios / conceitos bsicos............................................................... 118
4.2.5 As atividades de processo, mtodos e tcnicas ................................................... 119
4.2.5.1 SLA estruturas Projetando ........................................................................................ 121
4.2.5.2 Determinar, documentar e acordar requisitos para novos servios e produzir SLRs ... 124
4.2.5.3 desempenho servio Monitor contra SLA .................................................................. 126
4.2.5.4 Intercalar, medir e melhorar a satisfao do cliente ................................................... 128
4.2.5.5 Anlise e rever os acordos subjacentes e escopo de servios ................................... 129
4.2.5.6 servio relatrios Produzir ......................................................................................... 131
4.2.5.7 Conduta revises do servio e instigar melhorias dentro de um SIP geral.................. 132
4.2.5.8 e Reviso de SLAs, o escopo de servios e acordos subjacentes ............................. 133
4.2.5.9 Desenvolver contatos e relacionamentos .................................................................. 133
4.2.5.10 Reclamaes e elogios ........................................................................................... 134

4.2.6 Triggers, entradas, sadas e interfaces................................................................. 135


4.2.6.1 processo entradas SLM ............................................................................................ 135
4.2.6.2 sadas processo SLM................................................................................................ 135

4.2.7 Indicadores Chave de Desempenho..................................................................... 136


4.2.7.1 KPIs.......................................................................................................................... 138

4.2.8 Gesto da Informao .......................................................................................... 139


4.2.9 Desafios, Fatores Crticos de Sucesso e riscos.................................................... 139
4.2.9.1 Fatores Crticos 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 - Pgina:

4 de 477

4.3.3 Valor para o negcio............................................................................................. 147


4.3.4 Polticas / princpios / conceitos bsicos............................................................... 147
4.3.4.1 Gerenciamento da Capacidade de Negcios ............................................................. 149
4.3.4.2 Gerenciamento da Capacidade Servio .................................................................... 149
4.3.4.3 Gerenciamento da Capacidade Componente ............................................................ 149

4.3.5 as atividades de processo, mtodos e tcnicas.................................................... 151


4.3.5.1 Gerenciamento da Capacidade de Negcios ............................................................. 151
4.3.5.2 Gerenciamento da Capacidade Servio .................................................................... 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 gesto e controle ............................................................................................ 163
4.3.5.6 Gerenciamento da Demanda .................................................................................... 165
4.3.5.7 Modelagem e tendncias .......................................................................................... 166
4.3.5.8 Aplicao dimensionamento...................................................................................... 168

4.3.6 Triggers, entradas, sadas e interfaces................................................................. 169


4.3.6.1 Entradas ................................................................................................................... 169
4.3.6.2 Sadas ...................................................................................................................... 170

4.3.7 Indicadores Chave de Desempenho..................................................................... 171


4.3.8 Gesto da Informao .......................................................................................... 172
4.3.8.1 Capacidade do Sistema de Informao de Gesto .................................................... 173

4.3.9 Desafios, Fatores Crticos 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 negcio............................................................................................. 179
4.4.4 Polticas / princpios / conceitos bsicos............................................................... 180
4.4.5 as atividades de processo, mtodos e tcnicas.................................................... 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, sadas e interfaces................................................................. 222


4.4.6.1 Entradas ................................................................................................................... 222
4.4.6.2 Sadas ...................................................................................................................... 223

4.4.7 Indicadores Chave de Desempenho..................................................................... 224


4.4.8 Gesto da Informao .......................................................................................... 225
4.4.9 Desafios, Fatores Crticos de Sucesso e riscos.................................................... 227

4,5 Gerenciamento de Continuidade do Servio ....................................................... 229


4.5.1 Finalidade objetivo / / objetivo............................................................................... 229
4.5.2 mbito .................................................................................................................. 230
4.5.3 Valor para o negcio............................................................................................. 231
4.5.4 Polticas / princpios / conceitos bsicos............................................................... 231
4.5.5 as atividades de processo, mtodos e tcnicas.................................................... 233
4.5.5.1 Fase 1 - Iniciao...................................................................................................... 233
4.5.5.2 Fase 2 - Requisitos e estratgia ................................................................................ 234
Requisitos - Business Impact Analysis .....................................................................................................234
Requisitos - Anlise de Risco ...................................................................................................................237
Estratgia de TI da Continuidade do Servio ...........................................................................................242
Resposta medidas de risco.......................................................................................................................242
Armazenamento off-site ............................................................................................................................243
Opes de recuperao ITSCM ...............................................................................................................243

4.5.5.3 Estgio 3 - Implementao ........................................................................................ 247


Planejamento, organizao ......................................................................................................................250
Teste .........................................................................................................................................................250

4.5.5.4 Fase 4 - Operao Contnua ..................................................................................... 251


Invocao ..................................................................................................................................................252

4.5.6 Triggers, entradas, sadas e interfaces................................................................. 254


4.5.6.1 Entradas ................................................................................................................... 255
4.5.6.2 Sadas ...................................................................................................................... 256

4.5.7 Indicadores Chave de Desempenho..................................................................... 256


4.5.8 Gesto da Informao .......................................................................................... 257
4.5.9 Desafios, Fatores Crticos de Sucesso e riscos.................................................... 257

ITIL V3 - Service Design - Pgina:

5 de 477

4.6 Gesto de Segurana da Informao .................................................................. 259


4.6.1 Finalidade objetivo / / objetivo............................................................................... 259
4.6.2 mbito .................................................................................................................. 260
4.6.3 Valor para o negcio............................................................................................. 261
4.6.4 Polticas / princpios / conceitos bsicos............................................................... 261
4.6.4.1 estrutura de segurana ............................................................................................. 261
4.6.4.2 A Poltica de Segurana da Informao..................................................................... 262
4.6.4.3 O Sistema de Gesto da Segurana (SGSI) .............................................................. 262

4.6.5 as atividades de processo, mtodos e tcnicas.................................................... 266


4.6.5.1 Os controles de segurana........................................................................................ 267
4.6.5.2 Gesto de violaes de segurana e incidentes ........................................................ 269

4.6.6 Triggers, entradas, sadas e interfaces................................................................. 270


4.6.6.1 Entradas ................................................................................................................... 271
4.6.6.2 Sadas ...................................................................................................................... 272

4.6.7 Indicadores Chave de Desempenho..................................................................... 272


4.6.8 Gesto da Informao .......................................................................................... 273
4.6.9 Desafios, Fatores Crticos de Sucesso e riscos.................................................... 274

4,7 Gesto de Fornecedores ...................................................................................... 277


4.7.1 Finalidade objetivo / / objetivo............................................................................... 277
4.7.2 mbito .................................................................................................................. 277
4.7.3 Valor para o negcio............................................................................................. 279
4.7.4 Polticas / princpios / conceitos bsicos............................................................... 279
4.7.5 as atividades de processo, mtodos e tcnicas.................................................... 281
4.7.5.1 Avaliao de novos fornecedores e contratos ............................................................ 282
4.7.5.2 categorizao Fornecedor e manuteno 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 renovao do Contrato e / ou resciso ...................................................................... 299

4.7.6 Triggers, entradas, sadas e interfaces................................................................. 300


4.7.6.1 Entradas ................................................................................................................... 301
4.7.6.2 Sadas ...................................................................................................................... 302

4.7.7 Indicadores Chave de Desempenho..................................................................... 302


4.7.8 Gesto da Informao .......................................................................................... 303
4.7.9 Desafios, Fatores Crticos de Sucesso e riscos.................................................... 303

5 Servios 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 Gesto e requisitos operacionais............................................................................... 308
5.1.1.3 Os requisitos de usabilidade ..................................................................................... 309

5.1.2 Requisitos para apoio - a viso de usurio ........................................................... 309


5.1.3 Requisitos tcnicas de investigao ..................................................................... 310
5.1.3.1 Entrevistas ................................................................................................................ 310
5.1.3.2 Workshops................................................................................................................ 311
5.1.3.3 Observao .............................................................................................................. 313
5.1.3.4 Anlise de Protocolo ................................................................................................. 313
5.1.3.5 Shadowing ................................................................................................................ 313
5.1.3.6 Anlise de Cenrio.................................................................................................... 314
5.1.3.7 prototipagem ............................................................................................................. 314
5.1.3.8 Outras tcnicas ......................................................................................................... 315

5.1.4 Problemas com a engenharia de requisitos .......................................................... 316


5.1.4.1 Resoluo de problemas de engenharia requisitos .................................................... 317

5.1.5 Documentao de requisitos ................................................................................ 319


5.1.5.1 O Catlogo de Requisitos ......................................................................................... 320
5.1.5.2 documentao de requisitos completo....................................................................... 322

5.1.6 Requisitos e terceirizao..................................................................................... 323


5.1.6.1 requisitos tpicos cenrios de terceirizao................................................................ 324

ITIL V3 - Service Design - Pgina:

6 de 477

5.2 Dados e Gesto da Informao ........................................................................... 325


5.2.1 Gerenciamento de ativos de dados ...................................................................... 326
5.2.2 mbito da Gesto de Dados ................................................................................. 326
5.2.3 Gesto de Dados e do Ciclo de Vida do Servio .................................................. 328
5.2.4 Apoio ao Ciclo de Vida do Servio........................................................................ 328
5.2.5 Valorizao 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 migrao de dados ............................................................................................ 331
5.2.10 O armazenamento de dados .............................................................................. 331
5.2.11 A captura de dados............................................................................................. 332
5.2.12 recuperao de dados e uso .............................................................................. 332
5.2.13 A integridade de dados e questes relacionadas ............................................... 332

5,3 Gerenciamento de Aplicativos .............................................................................. 334


5.3.1 O portflio de aplicativos ...................................................................................... 335
5.3.2 Vinculao portflios de aplicativos e servio....................................................... 335
5.3.3 frameworks de aplicao ...................................................................................... 336
5.3.4 A necessidade de ferramentas CASE e repositrios ............................................ 337
5.3.5 Design de aplicaes especficas ......................................................................... 337
5.3.6 Gerente trade-offs................................................................................................. 339
5.3.7 tpicas sadas de projeto ....................................................................................... 339
5.3.8 Os padres de design........................................................................................... 339
5.3.9 Desenvolvimento de aplicaes individuais.......................................................... 340
5.3.10 consistentes convenes de codificao ............................................................ 341
5.3.11 modelos e gerao de cdigo ............................................................................. 341
5.3.12 instrumentao aplicativo embutido.................................................................... 342
5.3.13 ganchos de diagnstico ...................................................................................... 342
5.3.14 Principais sadas de servio de desenvolvimento............................................... 343

6 Organizador para Design de Servios .......................................................... 344


6.1 Anlise Funcional papis...................................................................................... 346
6.2 Anlise de Atividade ............................................................................................. 346
6,3 habilidades e atributos .......................................................................................... 347
6,4 Funes e responsabilidades ............................................................................... 348
6.4.1 Processo de proprietrio....................................................................................... 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 Catlogo de Servio........................................................................... 354
6.4.6 Gerente de Nvel de Servio ................................................................................. 354
6.4.7 Availability Manager.............................................................................................. 355
6.4.8 Gestor de Continuidade de Servios de TI ........................................................... 356
6.4.9 Capacity Manager................................................................................................. 357
6.4.10 Security Manager................................................................................................ 359
6.4.11 Gerente de Fornecedor ...................................................................................... 360

7 consideraes de tecnologia ........................................................................ 362


7,1 projeto Ferramentas de servio............................................................................ 363
7,2 Ferramentas de Gesto de Servio ..................................................................... 367

8 Design de Servios Implementar .................................................................. 372


8.1 Anlise de Impacto no Negcio ............................................................................ 373
8,2 Nvel Requisitos de Servio.................................................................................. 374
8,3 Riscos para os servios e processos ................................................................... 374
8,4 Service Design Implementar ................................................................................ 375
8.4.1 O que a viso?................................................................................................... 377

ITIL V3 - Service Design - Pgina:

7 de 477

8.4.2 Onde estamos agora? .......................................................................................... 378


8.4.3 Onde que ns 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 Medio de Design de Servios ........................................................................... 382


8.5.1 Pr-requisitos para o sucesso .............................................................................. 383
8.5.2 Fatores Crticos de Sucesso e Indicadores Chave de Desempenho .................... 383

9 Desafios, Fatores Crticos de Sucesso e riscos ............................................ 386


9,1 Desafios ................................................................................................................ 386
9,2 Riscos ................................................................................................................... 388

Posfcio........................................................................................................... 389
Apndice A: O Pacote de Desenho de Servio................................................ 390
Apndice B: Critrios de aceitao do servio (exemplo) ................................ 393
Anexo C: modelos de processo de documentao (exemplo) ......................... 395
C1 Process Framework .............................................................................................. 395

Anexo D: Design e Planejamento documentos e seus contedos ................... 396


D1 Design e documentos de arquitetura e padres .................................................. 397
D2 planos de TI........................................................................................................... 398

Apndice E: arquiteturas e padres ambientais ............................................... 400


Edifcio 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 escritrio ............................................................................... 404

Anexo F: SLA e OLA Amostra ......................................................................... 405


Service Level Agreement (SLA - Amostra) ................................................................ 405
Descrio do servio: .................................................................................................... 405
mbito do acordo:.......................................................................................................... 405
Horas de servio: ........................................................................................................... 406
Disponibilidade do servio: ............................................................................................ 406
Confiabilidade: ............................................................................................................... 406
Atendimento ao cliente: ................................................................................................. 407
Pontos de contacto e de escalao: .............................................................................. 407
Desempenho do servio: ............................................................................................... 407
Turnaround vezes lote: .................................................................................................. 408
Funcionalidade (se for o caso):...................................................................................... 408
Gesto da Mudana: ..................................................................................................... 408
Continuidade de servio: ............................................................................................... 408
Segurana: .................................................................................................................... 409
Impresso: ..................................................................................................................... 409
Responsabilidades: ....................................................................................................... 409
Carregamento (se aplicvel):......................................................................................... 409
Servio de relatrios e analisar:..................................................................................... 409
Glossrio: ...................................................................................................................... 410
Folha de alterao: ........................................................................................................ 410

Acordo de Nvel Operacional (ANO - Amostra) ......................................................... 410


Detalhes de alteraes anteriores: ................................................................................ 410
Suporte Descrio do servio: ....................................................................................... 410
mbito do acordo:.......................................................................................................... 411
Horas de servio: ........................................................................................................... 411
Metas de servio:........................................................................................................... 411

ITIL V3 - Service Design - Pgina:

8 de 477

Pontos de contacto e de escalao: .............................................................................. 411


Posto de servio e tempos de resposta a incidentes e responsabilidades: ................... 411
Problema tempos de resposta e responsabilidades: ..................................................... 411
Gesto da Mudana: ..................................................................................................... 411
Gerenciamento de lanamento: ..................................................................................... 411
Gerenciamento de Configurao: .................................................................................. 411
Gesto de Segurana da Informao: ........................................................................... 412
Gerenciamento de Disponibilidade: ............................................................................... 412
Gesto da Continuidade de servio: .............................................................................. 412
Gerenciamento da Capacidade: .................................................................................... 412
Gerenciamento de Nvel de Servio: ............................................................................. 412
Gesto de Fornecedores: .............................................................................................. 412
Prviso de informaes: .............................................................................................. 412
Glossrio: ...................................................................................................................... 412
Folha de alterao: ........................................................................................................ 413

Anexo G: Catlogo de Servio Exemplo .......................................................... 414


Anexo H: O Servio de Gerenciamento quadro maturidade do processo ........ 415
Inicial (Nvel 1) ............................................................................................................ 417
Repetitivo (Nvel 2) ..................................................................................................... 418
Definido (Nvel 3) ........................................................................................................ 419
Gerenciado (Nvel 4) ................................................................................................... 420
Otimizao (Nvel 5) ................................................................................................... 421

Apndice I: contedo exemplo de uma declarao de Necessidade (SOR) e / ou


concurso (ITT) ................................................................................................. 422
Anexo J: Os contedos tpicos de um plano de capacidade ............................ 423
1 Introduo ................................................................................................................ 423
2 Resumo de Gesto .................................................................................................. 423
3 cenrios de negcios ............................................................................................... 423
4 mbito e termos de referncia do plano de ............................................................ 423
5 Os mtodos utilizados ............................................................................................. 424
6 suposies feitas ..................................................................................................... 424
7 resumo Servio ........................................................................................................ 424
8 resumo de Recursos................................................................................................ 425
9 Opes para melhoria do servio............................................................................ 425
10 Custos previstos .................................................................................................... 425
11 Recomendaes .................................................................................................... 426

Apndice K: Os contedos tpicos de um plano de recuperao ..................... 427


Outras informaes ......................................................................................... 435
Referncias ................................................................................................................. 435

Glossrio ......................................................................................................... 436


Lista de siglas ............................................................................................................. 436
Lista de definies ...................................................................................................... 440

ITIL V3 - Service Design - Pgina:

9 de 477

Prefcio
Prefcio da OGC
Desde a sua criao, 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 orientao
mantm o ritmo com um ambiente de negcios em constante mudana global.
Servio de Gesto de Requisitos so inevitavelmente moldado pelo
desenvolvimento de tecnologia, negcios revisto modelos e aumentando cliente
expectativas. Nossa mais recente verso do ITIL foi criado em resposta a estes
desenvolvimentos.
Este um dos cinco publicaes principais que descrevem a TI Servio de
Gesto de prticas que compem a ITIL. Eles so o resultado de um de dois
anos projeto para rever e atualizar a orientao. O nmero de Servio de Gesto
de profissionais em todo o mundo que ajudaram a desenvolver o contedo
dessas publicaes impressionante. Sua experincia e conhecimentos que
contriburam para o contedo para trazer-lhe um conjunto consistente de alta
qualidade orientao. Isto suportado pela contnua desenvolvimento de um
sistema de qualificao abrangente, juntamente com formao acreditada e
consultoria.
Se voc faz parte de uma empresa global, um departamento ou uma pequena
negcio, ITIL d acesso a nvel mundial Servio de Gesto de percia.
Essencialmente, ele coloca De servios de TI onde eles pertencem - no
corao do sucesso operaes comerciais.

Peter Fanning
Atuando Executivo
Office of Government Commerce

Prefcio Arquiteto Chefe


Grande servios no existem por acaso. Eles tm de ser cuidadosamente
planejado e projetado. Design de Servios o meio para alcanar este objectivo.
O melhor Estratgia de Servio no pode ser realizado sem bem desenhados
servios. Design de Servios eficaz pode levar organizaos para maiores

ITIL V3 - Service Design - Pgina:

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 servios que se destinem e trazer valor mensurvel para o
objetivo de negcios.
No passado, 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 negcio
no so cumpridas.
Um dos objectivos principais do Design de Servios eliminar essa viso do
velho mundo e trazer De servios de TI em uma viso nica e consolidada de
projetar servios dentro das realidades, constrangimentos e oportunidades da
vivo operao.
A oportunidade de tirar partido das novas tecnologias, maximizar a utilizao da
infra-estrutura existente, aplicaes, dados e conhecimentos ganha vida nas
pginas desta publicao.
Design de Servios amplia nossos horizontes e nos ajuda a ver uma tela maior,
mais coeso de TI Servio de Gesto de.
Qualquer organizao de TI que quer maximizar seu potencial para atender
objetivo de negcios e valor de negcio precisa dessa publicao no seu arsenal
de recursos.
Design de Servios uma orientao poderosa e uma pedra angular de
habilidades prticas, ferramentas e mtodos para a excelncia do servio.

Sharon Taylor
Arquiteto Chefe, Prticas ITIL Service Management

ITIL V3 - Service Design - Pgina:

11 de 477

Prefaciar
"Qualidade de um produto ou servio no o que o fornecedor coloca dentro o
que o cliente sai e est disposto a pagar. 'Peter Drucker, o guru americano de
gesto.

O ITIL Servio de Gesto de prticas so baseados nesta idia. Servios so


bens a partir do qual o cliente ganha valor. Como bem os servios so
projetados com as necessidades dos clientes em mente ir prever o valor que
pode ser derivada a partir deles. Na falta de Design de Servios, O servio ir
evoluir informalmente, muitas vezes sem aproveitando a perspectiva mais ampla
- a viso de negcio.
A fase de Desenho de Servio da ITIL Service Ciclo de Vida tem requisitos de
negcios e, usando cinco aspectos de Design de Servios, cria servios e seu
apoio prticas que atendam s demandas de negcios para qualidade,confiana
e flexibilidade. Design de Servios iterativo ao longo do Ciclo de Vida do
Servio, e comea com um projeto slido, que permite o construir,teste e liberar
fases Transio de Servio atravs da Pacote de Desenho de Servio.
O leitor ir aprender sobre princpios de design para infra-estrutura, aplicao,
processoes e recursos, bem como fornecimento modelos. Service Managers
tambm vai encontrar orientaes sobre a engenharia de requisitos de som,
Gesto de Fornecedores e chave projeto consideraes para o servio
terceirizao.
Se voc um interno ou prestador de servios externo, Voc parte de um rede
de valor e preencher uma crtica papel no Ciclo de Vida de Servio, atravs da
integrao do melhores prticass para Design de Servios eo ITIL Lifecycle
Servio em produtos inovadores para o empresa cliente. A publicao Service
Design proporciona os conhecimentos e habilidades necessrios para montar a
melhor combinao de servio ativos para produzir mensurveis, servios
escalveis e inovadora, no caminho para a excelncia do servio.
Qualquer Provedor de servios de TI que esperado para entregar qualidade
para o cliente de negcios deve ter o capacidade projetar servios que atendam
s expectativas, ento v para exceder essas expectativas.
A orientao desta publicao ir ajudar a alcanar isso.

ITIL V3 - Service Design - Pgina:

12 de 477

Informaes 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 alteraes que possam ser
necessrias para esta publicao, faa o login los em www.best-managementpractice.com/changelog.
Para mais informaes sobre qualificao e acreditao da formao, visite
www.itil-officialsite.com. Alternativamente, favor contatar:
APMG Service Desk
Espada Casa
Totteridge Estrada
High Wycombe
Buckinghamshire
HP13 6DG
Tel: +44 (0) 1494 452450
E-mail: servicedesk@apmgroup.co.uk

ITIL V3 - Service Design - Pgina:

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 criao contribuiu para este guia atravs de comentrios sobre
o contedo e alinhamento em todo o conjunto. Ento, graas tambm so
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 - Pgina:

14 de 477

Outras contribuies
Um nmero de pessoas contriburam generosamente seu tempo e conhecimento a este Design
de Servios publicao. 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 tambm gostariam de agradecer ao Tony Jenkins, DOMAINetc e Steve Rudd TI
Enterprise Management Service Limited (itens).
Para desenvolver ITIL v3 para refletir as melhores prticas actuais e produzir publicaes de
valor duradouro, OGC amplas consultas com diferentes das partes interessadass em todo o
mundo em todas as fases do processo. OGC tambm gostaria de agradecer s seguintes
pessoas e suas organizaes, por suas contribuies orientao 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, Joo 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, Esprito Consultoria; Rajeev Andharia, Sun; Antonio Arvalo, 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 Exrcito dos EUA; Wills Damasio, Quint Wellington Redwood;
Catalin Danila, GlaxoSmithKline, SRL Romnia; 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 Estratgica; Daniel Keller, SUIT Sua; Brian Kerr,
Axios Systems, Robert Kuhlig, mITSM; Hendrikje Kuhne, KTP-organisationsterberatung; Dirk Koetting, EDV - Konzepte;
Madhav Lakshminarayanan; Jane Link, Acerit Limited; Ernst Guido Leidheuser , Telelogic; Ryan Lloyd, MKS; Eduardo
Magalhes, 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; Frances 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 Servios; Geoffrey Wyeth, Independente; Rob Young, Fox IT, Michael Zimmermann , NETCONS

ITIL V3 - Service Design - Pgina:

15 de 477

1 Introduo
O primrio objetivo de Servio de Gesto de o de assegurar que o De servios
de TIs esto alinhados com as necessidades do negcio e apoiar ativamente
deles. imperativo que os servios de TI apoiar o processo de negcioes, mas
tambm cada vez mais importante que a TI atua como um agente de mudana
para facilitar a transformao de negcios.
Todos organizaos que usam a TI vai depender de TI para ser bem sucedido.
Se os processos de TI e servios de TI so implementados, geridos e apoiados
de forma adequada, o negcio ser mais bem sucedido, sofrem menos
perturbaes e perda de horas produtivas, reduzir custars, aumentar a receita,
melhorar as relaes pblicas e alcanar o seu objetivo de negcios.
A maioria das autoridades agora identificar quatro tipos de ativos de TI que
precisam ser adquiridas e geridas de forma a contribuir para a prestao de
servios de TI eficaz. Estes so infraestrutura de TI, aplicaos, informaes e
pessoas. Especificamente h uma forte nfase na aquisio, gesto e
integrao desses ativos ao longo do seu "nascimento aposentadoria" ciclo de
vida. A entrega de servios de TI de qualidade depende de uma gesto eficaz e
eficiente desses ativos.
Esses ativos por conta prpria, no entanto, no so suficientes para atender a
Servio de Gesto de necessidades do negcio. ITIL Servio de Gesto de
prticas usar esses tipos de ativos quatro como parte de um conjunto de
capacidades e recurso chamado de 'servio ativos '.

Figura 1.1 Recursos e capacidades so a base para a criao de valor

Um De servios de TI, Utilizado para apoiar processo de negcioes, construdo


a partir de uma combinao de ativos de TI e externamente, desde 'que
sustentam' servios. Uma vez no local, um servio de TI deve ser apoiado ao
longo de sua "vida", durante o qual pode ser modificado muitas vezes, seja

ITIL V3 - Service Design - Pgina:

16 de 477

atravs da inovao tecnolgica empresarial, mudando ambiente, O uso de


mudana da servio, Alterando seus parmetros de qualidade de servio, ou
alterar seus ativos de TI de apoio ou recursos (por exemplo, um mudar em uma
aplicao de software componente para fornecer funcionalidade adicional).
Eventualmente, o servio de TI aposentard, quando o negcio processoes no
tem mais um uso para ele ou ele no mais custo-efetiva para correr. Transio
de Servio est envolvida na construir e desenvolvimento do servio e do dia-adia, apoio e entrega do servio a papel de Operao de Servio, Enquanto
Melhoria de Servio Continuada implementa melhores prticas no otimizar e se
aposentar etapas.
A partir desta perspectiva, Design de Servios pode ser visto como a recolha de
necessidades de servios e mape-los s necessidades de servios integrados
e de criar o projeto especificaos para o servio ativos necessrios para
prestao de servios. Uma caracterstica particular dessa abordagem uma
forte nfase na reutilizao durante o projeto.
O principal objetivo do Service Design projetar servios de TI, juntamente com
as que regem as prticas de TI, processos e polticas, para realizar o estratgia
e para facilitar a introduo dos servios para o viver ambiente garantir a
qualidade do servio de entrega, satisfao do cliente e custo-eficaz prestao
de servios. Design de Servios tambm deve projetar os servios de TI de
forma eficaz, de modo que eles no precisam de uma grande quantidade de
melhoria durante a sua ciclo de vida. No entanto, a melhoria contnua deve ser
incorporado em todas as atividades de design de servio para garantir que as
solues e os projetos tornam-se ainda mais eficaz ao longo do tempo e
identificar novas tendncias no negcio que podem oferecer oportunidades de
melhoria. As atividades de projeto de servios podem ser peridicas ou exceo
baseada em quando pode ser desencadeada por uma necessidade de negcio
ou evento especfico.
Se os servios ou processos no so projetados eles vo evoluir organicamente.
Se evoluir sem a devida controlars, a tendncia simplesmente a reagir s
condies ambientais que ocorreram em vez de compreender claramente a
global viso e necessidades globais do negcio. Projetando para combinar com
o ambiente esperado muito mais eficaz e eficiente, mas muitas vezes
impossvel - da a necessidade de se considerar iterativo e abordagens
incrementais Design de Servios. Iterativo e abordagens incrementais so
essenciais para assegurar que os servios introduzidos no ambiente real se
adaptar e continuar em linha com as necessidades de negcio em evoluo. Na
ausncia de Design de Servios formalizada, servios, muitas vezes, ser
excessivamente caro para ser executado, propenso a falha, Os recursos sero
desperdiados e servios no ser completamente alinhado com as necessidades
do negcio. pouco provvel que qualquer melhoria programa nunca vai ser
capaz de conseguir o que projeto adequado seria alcanar em primeiro lugar.
Sem Design de Servios, o custo-benefcio servio no possvel. Os aspectos

ITIL V3 - Service Design - Pgina:

17 de 477

humanos do Design de Servios tambm so de extrema importncia, e estes


sero explorados em detalhe mais tarde nesta publicao.

1.1 Viso Geral


Esta publicao faz parte do ITIL geral Servio de Gesto de prticas e abrange
o projeto de adequadas e inovadoras de TI servios para atender atuais e
futuros requisitos de negcios acordados. Ele descreve os princpios do
Desenho de Servio e olha para identificar, definir e alinhar a soluo de TI com
as necessidades dos negcios. Alm disso, introduz o conceito de Pacote de
Desenho de Servio e olha para selecionar o apropriado Design de Servios
modelo. A publicao tambm aborda os fundamentos dos processos de design
e os cinco aspectos do projeto:

Servios
Projeto de sistemas de gerenciamento de servios e ferramentas,
especialmente o Portflio de Servios
Tecnologia arquiteturas e sistema de gestos
Processoes
Mtodos de medio e mtricos.

A publicao abrange os mtodos, prticas e ferramentas para alcanar a


excelncia em Design de Servio. Ele aplica o princpio de que o Design de
Servios inicial deve ser conduzido por uma srie de fatores, incluindo os
requisitos funcionais, os requisitos dentro do Contratos de Nvel de Servio
(SLAs), os benefcios de negcio e as restries de design em geral.
Captulo 4 explica o processo de ponta a ponta das reas chave para o sucesso
Design de Servios. Estes processos so utilizados por todas as outras fases do
Servio Ciclo de VidaE outros processos so levados em conta por Design de
Servio. No entanto, aqui que o Gerenciamento de Catlogo de Servio,
Gerenciamento de Nvel de Servio,Gerenciamento da
Capacidade,Gerenciamento de Disponibilidade,Gerenciamento da Continuidade
do Servio,Gesto de Segurana da Informao e Gesto de Fornecedores so
abordados em detalhes.
Os apndices para esta publicao dar exemplos da Pacote de Desenho de
Servio,Critrios de aceitao de servios, Modelos de documentao de
processos, design e documentos de planejamento, arquiteturas e padres
ambientais, amostra de SLAs, e OLAs Catlogo de Servios e a Servio de
Gesto de estrutura de maturidade de processo.

ITIL V3 - Service Design - Pgina:

18 de 477

1,2 Contexto
1.2.1 Gesto de Servios
Tecnologia da informao (TI) um termo comumente usado que muda de
significado com o contexto. A partir da perspectiva de primeira, sistemas de TI,
aplicaos, infra-estrutura e so componentes ou subconjuntos de um produto
maior. Eles permitem ou so incorporados em processos e servios. A partir da
segunda perspectiva, uma organizao com seu prprio conjunto de
capacidades e recursos. Organizaes de TI podem ser de vrios tipos, tais
como funes de negcios, unidades de servios partilhados, e as unidades de
nvel empresarial do ncleo.
A partir da terceira perspectiva, uma categoria de servios utilizados pelas
empresas. Eles so tipicamente de TI aplicaos e infra-estrutura que so
embalados e oferecida como servios internos de TI por organizaes ou
prestador de servios externos. TI custars so tratados como despesas
comerciais. A partir da quarta perspectiva, a TI uma categoria de ativos de
negcios que fornecem um fluxo de benefcios para seus proprietrios, incluindo,
mas no limitado a renda de receita e lucro. Os custos de TI so tratados como
investimentos.

1.2.2 Boas prticas no domnio pblico


Organizaes operar em ambientes dinmicos com a necessidade de aprender
e se adaptar. Existe uma necessidade de melhorar atuao enquanto gestora
trade-offs. Sob presso semelhante, clientes procuram vantagem de prestadores
de servios. Eles perseguem estratgias de sourcing que melhor servem os
seus prprios interesses comerciais. Em muitos pases, agncias
governamentais e organizaes sem fins lucrativos tm uma tendncia
semelhante de terceirizar para o bem da operacional eficcia. Isso coloca uma
presso adicional sobre os prestadores de servios para manter uma vantagem
competitiva em relao s alternativas que os clientes possam ter. O aumento
em terceirizao se particularmente expostas prestador de servios internos
concorrncia incomum.
Para lidar com a presso de referncia das organizaes, se contra colegas e
buscam fechar brechas em capacidades. Uma forma de fechar essas lacunas
a adoo de boas prticas na utilizao de toda a indstria. Existem vrias
fontes de boas prticas, incluindo estruturas pblicas, padres e conhecimento
de propriedade de organizaes e indivduos (Figura 1.2).

ITIL V3 - Service Design - Pgina:

19 de 477

Figura 1.2 Fornecimento de prtica Gesto de Servios

Estruturas pblicas e as normas so atraentes quando comparados com


conhecimento de propriedade:

Conhecimento proprietrio est profundamente enraizado na


organizaos e, portanto, difceis de adotar, replicar ou transferir, mesmo
com a cooperao dos proprietrios. Tal conhecimento muitas vezes na
forma de conhecimento tcito que indissolvel e mal documentadas.
Conhecimento proprietrio personalizado para o contexto local e as
necessidades especficas do negcio, a ponto de ser idiossincrtico. A
no ser que os destinatrios de tais conhecimentos tm correspondncia
circunstncias, o conhecimento no pode ser to eficaz em uso.
Proprietrios de conhecimento proprietrio esperam ser recompensados
por seus investimentos de longo prazo. Eles podem fazer tal
conhecimento disponvel apenas em termos comerciais, atravs de
compras e de licenciamento acordos.
Estruturas disponveis publicamente e padres como ITIL,COBIT, CMMI,
eSCM-SP, PRINCE2,ISO 9000, ISO / IEC 20000 e ISO / IEC 27001 so
validados atravs de um conjunto diversificado de ambientes e situaes,
em vez de limitada experincia de uma nica organizao. Eles esto
sujeitos a ampla reviso atravs de vrias organizaes e disciplinas.
Eles so controlados por diversos conjuntos de parceiros, fornecedors e
concorrentes.
O conhecimento das estruturas pblicas mais provvel a ser
amplamente distribudo entre uma grande comunidade de profissionais
por meio de treinamento disponveis publicamente e certificado. mais
fcil para as organizaes a adquirir tais conhecimentos por meio do
mercado de trabalho.

ITIL V3 - Service Design - Pgina:

20 de 477

Ignorando estruturas pblicas e padres podem desnecessariamente colocar


uma organizao em desvantagem. As organizaes devem cultivar seu prprio
conhecimento proprietria em cima de um corpo de conhecimento baseado em
quadros pblicos e padres. Colaborao e coordenao entre as organizaes
so mais fceis com base compartilhada prticas e padres.

1.2.3 ITIL e boas prticas em Gesto de Servios


O contexto desta publicao o framework ITIL como uma fonte de boas
prticas Servio de Gesto de. ITIL usado por organizaes em todo o mundo
para estabelecer e melhorar as capacidades de gerenciamento de servios. ISO
/ IEC 20000 fornece uma formal e universal padro para organizaes que
buscam ter seus recursos de gerenciamento de servio auditado e certificado.
Enquanto a norma ISO / IEC 20000 um padro a ser alcanado e mantido, ITIL
oferece um corpo de conhecimento til para alcanar o padro.
A Biblioteca ITIL tem o seguinte componentes:

O Core ITIL - melhores prticas orientaes aplicveis a todos os tipos de


organizaes que prestam servios para um negcio
O ITIL Orientao Complementar - um conjunto complementar de
publicaes com orientaes especficas para os setores da indstria,
tipos de organizao, operando modelos e tecnologia arquiteturas.

O Core ITIL composto por cinco publicaes (Figura 1.3). Cada uma delas
fornece a orientao necessria para uma abordagem integrada, tal como
exigido pela ISO / IEC 20000 padro especificao:

Estratgia de Servio
Design de Servios
Transio de Servio
Operao de Servio
Melhoria de Servio Continuada.

ITIL V3 - Service Design - Pgina:

21 de 477

Figura 1.3 ITIL Ncleo

Cada publicao aborda as capacidades que tm direta impacto num provedor


de servios'S atuao. A estrutura do ncleo na forma de um ciclo de vida. Ele
interativo e multidimensional. Ele garante organizaos so criados para
alavancar as capacidades em uma rea de aprendizagem e melhorias em
outras. O Ncleo esperado para dar estabilidade, estrutura e fora para
Servio de Gesto de capacidades com durveis princpios, mtodos e
ferramentas. Isso serve para proteger os investimentos e proporcionar a base
necessria para a aprendizagem, medio e melhoria.
A orientao em ITIL pode ser adaptado para uso em ambientes de negcios
diversos e estratgias organizacionais. Orientao Complementar fornece
flexibilidade para implementar o ncleo em uma variada gama de ambientes.
Praticantes pode selecionar Orientao Complementar, conforme necessrio
para fornecer trao para o Core em um contexto determinado negcio, assim
como os pneus so selecionados com base no tipo de condies de uso do
veculo, e estrada. Isso para aumentar a durabilidade e portabilidade dos
ativos de conhecimento e de proteger os investimentos em capacidades de
Gesto de Servios.

ITIL V3 - Service Design - Pgina:

22 de 477

1.2.3.1 Estratgia de Servio

O Estratgia de Servio publicao fornece orientaes sobre como projetar,


desenvolver e implementar o Gerenciamento de Servio, no apenas como uma
organizao capacidade mas tambm como um estratgico ativos. So
fornecidas orientaes sobre os princpios subjacentes prtica de Gesto de
Servios, que so teis para o desenvolvimento de polticas de gerenciamento
de servios, diretrizs e processoes em todo o ITIL Service Lifecycle. Orientao
Estratgia servio til no contexto de Design de Servios,Transio de
Servio,Operao de ServioE Melhoria de Servio Continuada. Os tpicos
abordados na Estratgia de Servio incluem o desenvolvimento de mercados interno e externo, servio ativos, Catlogo de ServiosE implementao de
estratgia atravs do Ciclo de Vida do Servio. Gesto Financeira, Gesto de
Portflio de Servios, Desenvolvimento Organizacional e riscos estratgicos
esto entre outros grandes temas.
Organizaes usam a orientao para definir objetivos e expectativas de
desempenho para servir clientes e espaos de mercado, e de identificar,
selecionar e priorizar oportunidades. Estratgia de Servio se de garantir que as
organizaes esto em uma posio para lidar com a custars e os riscos
associados ao seu Portflio de Servioss, e so criados no s para operacional
eficcia mas tambm para um desempenho diferenciado. As decises tomadas
em relao Estratgia de Servio tem conseqncias de longo alcance,
incluindo aqueles com efeito retardado.
Organizaes j praticando ITIL usar este volume para guiar um estratgico
rever da sua ITIL baseada Servio de Gesto de capacidades e melhorar o
alinhamento entre esses recursos e suas estratgias de negcios. 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
esto mais prximos da clienteO negcio. Estratgia de Servio expande a
escopo do Quadro de ITIL alm do pblico tradicional de IT Service
Management profissionais.
1.2.3.2 Design de Servios

O Design de Servios publicao fornece orientao para a projeto e


desenvolvimento de servios e Servio de Gesto de processos. Ele abrange os
princpios de design e mtodos para a converso estratgico objetivos em
carteiras de servios e servio ativos. O escopo do Servio de projeto no se
limita a novos servios. Ele inclui o mudars e melhorias necessrias para
aumentar ou manter valor para os clientes durante o ciclo de vida dos servios, a
continuidade dos servios, a realizao de nvel de servios e conformidade com
as normas e regulamentos. Ele orienta as organizaes sobre como desenvolver
capacidades de design para Gerenciamento de Servios.
ITIL V3 - Service Design - Pgina:

23 de 477

1.2.3.3 Transio de Servio

O Transio de Servio publicao fornece orientao para o desenvolvimento e


melhoria de capacidades para a transio de servios novos e modificados para
operaes. Esta publicao fornece orientaes sobre como os requisitos de
Estratgia de Servio codificado em Design de Servios so efetivamente
realizados em operao de servios, enquanto controla os riscos de falha e
ruptura. A publicao combina prticas em Gerenciamento de Liberao, Gesto
de Programa e gesto de risco, E coloca-os no contexto da prtica de Servio de
Gesto de. Ele fornece orientaes sobre o gerenciamento da complexidade
relacionada a alteraes nos servios e Servio de Gesto de processoes evitando consequncias indesejveis, permitindo a inovao. Orientao
fornecida sobre a transferncia do controlar de servios entre clientes e provedor
de servioss.
1.2.3.4 Operao de Servio

Esta publicao incorpora prticas na gesto de operaes de servios. Inclui


orientao sobre a realizao eficcia e eficincia na entrega e suporte de
servios, de modo a garantir um valor para o cliente e o provedor de servios.
Estratgico objectivos so, em ltima anlise realizada atravs de operao de
servios, portanto, que o torna um crtico capacidade. So fornecidas
orientaes sobre como manter a estabilidade em operao de servios, o que
permite mudanas de escala, design, escopo e nvel de servios. Organizaos
so fornecidos com o processo detalhado diretrizs, mtodos e ferramentas para
uso em dois grandes controle de perspectivas: reativa e pr-ativa. Gestores e
profissionais so fornecidos com o conhecimento que lhes permite tomar
melhores decises em reas como a gesto do disponibilidade de servios, a
demanda controle, otimizao capacidade utilizao, programao de operaes
e de fixao problemas. So fornecidas orientaes sobre operaes de apoio
atravs de novos modelos e arquiteturas, tais como servios compartilhados,
utilidade Informtica, Internet e servios de comrcio mvel.
1.2.3.5 Melhoria de Servio Continuada

Esta publicao oferece orientao instrumental na criao e manuteno de


valor para os clientes atravs de uma melhor concepo, transio e operao
de servios. Combina princpios, prticas e os mtodos de gesto da qualidade,
Gesto da Mudana e melhoria de capacidade. Organizaes aprender a
perceber melhorias incrementais e de larga escala em servio
qualidade,operacional eficincia e continuidade dos negcios. Orientao
fornecida para ligar os esforos de melhoria e resultados com estratgia de
servio, Transio, design e operao. Um sistema de retorno de ciclo fechado,
com base na Plan-Do-Check-Act (PDCA) modelo especificado na norma ISO /

ITIL V3 - Service Design - Pgina:

24 de 477

IEC 20000, estabelecido e capaz de receber entradas para a mudana de


qualquer perspectiva de planejamento.

ITIL V3 - Service Design - Pgina:

25 de 477

1,3 Propsito
O objetivo desta publicao dar a orientao sobre o uso de leitor de prticas
recomendadas ao projetar De servios de TIs e TI Servio de Gesto de
processos.
Esta publicao surge na sequncia do Estratgia de Servio publicao, que
fornece orientao sobre o alinhamento e integrao das necessidades do
negcio para a TI. Ele permite que o leitor a avaliar os requisitos na concepo
de um servio e indstria documentos melhores prticas para o projeto de De
servios de TIs e processos.
Embora esta publicao pode ser lido de forma isolada, recomenda-se que seja
utilizada em conjunto com a outra ITIL publicaes. As orientaes do ITIL
publicaes aplicvel genericamente. burocrtica nem pesado se for
utilizado de forma sensata e no pleno reconhecimento das necessidades do
negcio da organizao. Design de Servios importante para o palco para
entregar servios de forma eficaz para o negcio e atender a demanda de
crescimento e mudana. Enhancement tipicamente superior em custar e
recursos do que desenvolvimento. Considerao importante deve ser dado a
projetar para a facilidade e economia de apoio ao longo de todo ciclo de vida,
Mas, mais importante ainda, no possvel eliminar completamente reengenharia um servio de uma vez em produo. possvel chegar perto, mas
vai ser impossvel voltar a um projeto uma vez que algo est sendo executado.
Reequipamento do projeto difcil e caro e nunca alcana o que poderia ter sido
alcanado se projetado

1,4 Uso
Esta publicao relevante para qualquer pessoa envolvida na concepo,
implementao ou suporte de servios de TI. Ela ter relevncia para o arquiteto
de TI, gerentes de TI e profissionais de todos os nveis. Todas as publicaes do
ITIL Servio de Gesto de Biblioteca ncleo precisa ser lido para apreciar e
entender o ciclo de vida total dos servios e do IT Service Management.
Existem vrias maneiras de entregar um servio de TI, tais como em casa,
terceirizados e parceria. Esta publicao geralmente relevantes para todos os
mtodos de prestao de servios. Assim, os envolvidos na prestao de
servios de TI - dentro de sua prpria organizao, Na prestao de servios
terceirizados ou a trabalhar em parcerias - vai achar que esta publicao se
aplica a eles. Os gerentes de negcios pode encontrar a publicao til para a

ITIL V3 - Service Design - Pgina:

26 de 477

compreenso e definio das melhores prticas de servios de TI e suporte.


Gestores de fornecedor organizaes tambm vai encontrar esta publicao
relevante quando a criao de acordos para a entrega e suporte de servios.

2 Gerenciamento de Servio como uma prtica


2.1 O que Gerenciamento de Servios?
Servio de Gesto de um conjunto de capacidades especializadas
organizacionais para o valor de clientes, sob a forma de servios. As
capacidades de assumir a forma de funes e processoes para gerenciamento
de servios ao longo de um ciclo de vida, com especializaes em estratgia,
Design, transio,operao e melhoria contnua. Os recursos representam um
servio de organizao capacidade, Competncia e confiana para a ao. O
ato de transformar recursos em servios de valor est no centro de
Gerenciamento de Servio. Sem esses recursos, uma organizao de servio
meramente um conjunto de recursos que por si s tem relativamente baixo valor
intrnseco para os clientes.
Service Management um conjunto de capacidades especializadas
organizacionais para o valor aos clientes na forma de servios.
Capacidades organizacionais so moldadas pelos desafios que eles tero de
superar. Servio de Gesto de capacidades so igualmente influenciado pelos
seguintes desafios que distinguem servios de outros sistemas de criao de
valor, tais como minerao, manufatura e agricultura:

Natureza intangvel da produo e produtos intermedirios de processos


de servios: difceis de medir, controlar e validar (ou provar)
A demanda est intimamente ligado com clienteOs ativos: usurios e
ativos dos clientes, tais como processos, aplicaos, documentos e
transaos chega com a demanda e estimular a produo de servios
Alto nvel de contato para os produtores e consumidores de servios:
buffer pouca ou nenhuma entre o cliente, o front-office e back-office
A natureza perecvel da produo de servios e de servio capacidade:
No h valor para o cliente de garantia da continuidade do fornecimento
de consistente qualidade. Provedores precisam garantir um suprimento
constante de demanda dos clientes.

Gesto de Servios, no entanto, mais do que apenas um conjunto de


capacidades. tambm um profissional prtica suportado por um extenso corpo
de conhecimento, experincia e habilidades. Uma comunidade global de
indivduos e organizaos nos setores pblico e privado promove seu
crescimento e maturidade. Esquemas formais existem para a educao,
formao e certificado de praticar organizaes e indivduos influenciam a sua

ITIL V3 - Service Design - Pgina:

27 de 477

qualidade. Indstria melhores prticass, a pesquisa acadmica e os padres


formais contribuir para o seu capital intelectual e tirar dele.
As origens da Servio de Gesto de esto em servio tradicional negcioes tais
como companhias areas, bancos, hotis e empresas de telefonia. Sua prtica
tem crescido com a adoo pelas organizaes de TI de uma abordagem
orientada a servios para gesto de TI aplicaoA infra-estrutura, e processoes.
Solues para os negcios problemas e suporte para negcios modelos,
estratgias e operaes so cada vez mais na forma de servios. A
popularidade de servios partilhados e terceirizao contribuiu para o aumento
do nmero de organizaes que esto provedor de servioss, incluindo unidades
organizacionais internas. Este, por sua vez, reforou a prtica de gerenciamento
de servios, ao mesmo tempo, impor desafios maiores sobre ele.

ITIL V3 - Service Design - Pgina:

28 de 477

2.2 O que so servios?


2.2.1 O valor proposio
Um servio um meio de entregar valor aos clientes, facilitando resultados
clientes querem alcanar, sem a posse de determinado custars e riscos.
Servios so um meio de entregar valor aos clientes, facilitando os resultados
que os clientes querem alcanar, sem a posse de custos e riscos especficos.
Servios de facilitar os resultados atravs do aumento da atuao associado de
tarefas e a reduo do efeito de restries. O resultado um aumento na
probabilidade de resultados desejados.
Ao longo dos anos, as organizaes tm debatido a definio de um "servio". A
ilustrao na Figura 2.1 um exemplo de que a realizao do servio
realmente sobre a entrega de valor aos clientes.

Figura 2.1 Uma conversa sobre a definio e significado de servios

ITIL V3 - Service Design - Pgina:

29 de 477

2.3 Funes e processos atravs do ciclo de vida


2.3.1 Funes
Funes so unidades de organizaos especializada para executar certos tipos
de trabalho e responsveis por resultados especficos. Eles so auto-suficientes,
com capacidades e recursos necessrios para o seu desempenho e os
resultados. Os recursos incluem mtodos de trabalho interno para as funes.
Funes tm seu prprio corpo de conhecimentos, que se acumula com a
experincia. Eles fornecem estrutura e estabilidade para as organizaes.
Funes so meios de estruturar as organizaes para implementar o princpio
da especializao. Funes normalmente definem papels ea autoridade
associado e responsabilidade por um determinado atuao e os resultados.
Coordenao entre funes atravs compartilhada processoes um padro
comum na organizao projeto. Funes tendem a otimizar seus mtodos de
trabalho localmente para se concentrarem nos resultados atribudos. M
coordenao entre as funes, combinadas com um foco interno, leva a silos
funcionais que impedem o alinhamento e feedback que so crticos para o
sucesso da organizao como um todo. Processo modelos ajudar a evitar esse
problema com hierarquias funcionais, melhorando a coordenao inter-funcional
e controlar. Processos bem definidos pode melhorar a produtividade dentro e
atravs de funes.

2.3.2 Processos
Processos so exemplos de sistemas de circuito fechado, pois fornecem mudar
e transformao em direo a um objetivo, e utilizar o feedback para a autoreforo e auto-corretiva ao (Figura 2.2). importante levar em considerao
todo o processo, ou como um processo encaixa outra.

Figura 2.2 Um processo bsico

ITIL V3 - Service Design - Pgina:

30 de 477

Definies de processos descrevem aes, dependncias e seqncia.


Processos de ter as seguintes caractersticas:

Mensurvel - Somos capazes de medir o processo de uma forma


relevante. o desempenho conduzido. Os gerentes querem medir
custar,qualidade e as outras variveis enquanto praticantes esto
preocupados com a durao e a produtividade.
Os resultados especficos - A razo existe um processo a entrega de
um resultado especfico. Este resultado deve ser individualmente
identificveis e contveis. Enquanto podemos contar mudanas,
impossvel contar quantas Mesas de servios foram concludos.
Clientes - Cada processo de entrega de seus resultados primrios para
um cliente ou das partes interessadas. Os clientes podem ser internos ou
externos organizao, mas o processo deve atender suas expectativas.
Responde a um especfico evento - Enquanto um processo pode ser
contnuo ou iterativo, deve ser feita com um gatilho especfico.

Muitas vezes h confuso em torno de funes, processoes, papels e


atividades. As funes so muitas vezes confundidos com processos e
processos confundido com funes. Design de Servios, Bem como sendo uma
etapa do ciclo de vida de um servio, pode ele prprio ser vista por alguns
organizaos como um funo, Por outros como um papel ou de um conjunto de
processos ou como um atividade. Se ou no uma funo, atividade, funo
ou conjunto de processos depende inteiramente da dimenso, estrutura e cultura
de uma organizao. importante que no entanto definida e executada dentro
de uma organizao, o sucesso da funo, o processo, papel ou atividade
medido e melhorado continuamente.

2.3.3 Especializao e coordenao em todo o ciclo de vida


Especializao e coordenao so necessrios na abordagem do ciclo de vida.
Feedback e controlar entre as funes e processos dentro e entre os elementos
do ciclo de vida de tornar isto possvel. O padro dominante do ciclo de vida o
progresso seqencial a partir de SS atravs SO-SD-ST e volta a SS por meio de
CSI. Que, no entanto, no o nico padro de aco. Cada elemento do ciclo
de vida fornece pontos de feedback e controle.
A combinao de mltiplas perspectivas permite uma maior flexibilidade e
controle em ambientes e situaes. A abordagem do ciclo de vida imita a
realidade da maioria das organizaes, onde a gesto eficaz requer a utilizao
de mltiplas controle de perspectivas. Os responsveis pela
projeto,desenvolvimento e melhoria de processos para Servio de Gesto de
pode adotar uma perspectiva de controle baseada em processos. Para os
responsveis pela gesto acordos, contratos e servios pode ser melhor servido
por uma perspectiva de controle do ciclo de vida baseado em fases distintas.
Ambos controle benefcio perspectivas do pensamento sistmico. Cada

ITIL V3 - Service Design - Pgina:

31 de 477

perspectiva de controle pode revelar padres que podem no ser evidentes a


partir do outro.

ITIL V3 - Service Design - Pgina:

32 de 477

2,4 Projeto fundamentos Servio


2.4.1 Finalidade objetivo / / objetivo
O principal objectivo do Design de Servios fase do ciclo de vida o desenho de
novos ou alterados servios para introduo na viver ambiente. importante que
uma abordagem holstica para todos os aspectos do projeto adotado, e que ao
mudar ou alterar qualquer dos elementos individuais do projeto todos os outros
aspectos so considerados. Assim, ao projetar e desenvolver um novo
aplicao, Isso no deve ser feito isoladamente, mas tambm deve considerar o
impacto em todo o servio, o sistema de gestos e ferramentas (por exemplo,
Portflio de Servios e Catlogo de Servios), O arquiteturas, a tecnologia, os
processos de gerenciamento de servios e as medidas necessrias e mtricos.
Isso ir garantir que no s os elementos funcionais so atendidas pelo projeto,
mas tambm de que toda a gesto e operacional requisitos so tratados como
uma parte fundamental do projeto e no so adicionados como uma reflexo
tardia.
Uma abordagem holstica deve ser adotada por todos os aspectos de servios
de design e reas para garantir a consistncia e integrao em todas as
atividades e processos atravs da tecnologia de TI inteira, fornecendo fim-a-fim
funcionalidade de negcios relacionados e qualidade.
Nem todos os mudar dentro de um De servios de TI exigir a instigao Design
de Servios atividade. Ele somente ser exigida quando h mudana
"significativa". Cada organizao deve definir o que constitui "significativo" para
que todos dentro da organizao clara quanto ao momento em atividade
Design de Servios instigado. Portanto, todas as alteraes devem ser
avaliadas quanto ao seu impacto sobre as atividades de design de servio para
determinar se eles so significativos em termos de actividade que necessitam de
servio de Design. Isto deve ser parte do Gesto da Mudana impacto processo
avaliao dentro do Transio de Servio publicao de ITIL.

2.4.2 mbito
H cinco aspectos individuais de Design de Servios considerados nesta
publicao. Estes so o desenho de:

Servios novos ou modificados


Servio de Gesto de sistemas e ferramentas, em especial os Portflio de
Servios, Incluindo o Catlogo de Servios
Tecnologia arquitetura e sistema de gestos
O processoes necessrias
Mtodos de medio e mtricas.

ITIL V3 - Service Design - Pgina:

33 de 477

O Design de Servios fase do ciclo de vida comea com um conjunto de


requisitos de negcios novos ou alterados e termina com a desenvolvimento de
uma soluo de servio projetado para atender as necessidades do
documentados negcio. Esta soluo desenvolvida, juntamente com a sua
Pacote de Desenho de Servio (SDP - ver Apndice A), ento passado para
Transio de Servio para avaliar, construir,teste e implantar o servio novo ou
alterado. No termo destas transio actividades, controlar transferido para o
Operao de Servio fase do ciclo de vida de servios. As atividades envolvidas
nestas fases esto descritos na seo 3. O total escopo Servio de Design e os
cinco aspectos do design e como eles interagem so ilustrados na figura 2.3.

Figura 2.3 mbito de Design de Servios

O principal objetivo do Design de Servios o desenho de novo ou alterado


servios. Os requisitos para estes novos servios so extrados da Portflio de
Servios. Cada requisito analisada, documentada e concordou, e um projeto
de soluo que produzido ento comparada com as estratgias e as
restries de Estratgia de Servio para garantir que ele est em conformidade
com corporativa e polticas de TI. Cada Service Design indivduo tambm

ITIL V3 - Service Design - Pgina:

34 de 477

considerada em conjunto com cada um dos outros aspectos do Desenho de


Servio:

O Servio de Gesto de sistemas e ferramentas, em especial os


Carteira de servio: para garantir que este servio novo ou alterado
compatvel com todos os outros servios, e que todos os outros servios
que o apoio de interface, ou dependem dos servios novos ou alterados
so compatveis com o novo servio. Se no, ou o design do novo servio
ou outros servios j existentes tero de ser adaptados. Tambm os
sistemas de gerenciamento de servios e ferramentas devem ser revistas
para garantir que eles so capazes de suportar o servio novo ou
alterado.
A tecnologia arquiteturas e gerenciamento de sistemas: Para garantir
que todas as arquiteturas de tecnologia e sistemas de gesto so
consistentes com o novo servio ou alterados e tm o capacidade para
operar e manter o novo servio. Se no, ento ou as arquiteturas ou
sistemas de gesto ter de ser alterada ou o design do novo servio ter
de ser revisto.
Os processos: Para assegurar que os processos, papels,
responsabilidades e competncias tm a capacidade de operar, apoiar e
manter o servio novo ou alterado. Se no, o projeto do novo servio ter
de ser revisto ou as capacidades de processo existentes tero de ser
reforada. Isto inclui todo e TI Servio de Gesto de processos, e no
apenas a chave Design de Servios processos.
Os mtodos de medio e mtricos: Garantir que os mtodos de
medio existentes podem fornecer as mtricas necessrias no servio
novo ou alterado. Se no, ento os mtodos de medio precisa ser
melhorado ou as mtricas de servio ter de ser revisto.

Se todas as atividades acima estejam concludas durante o Design de Servios


palco, isso ir garantir que no haver problemas mnimos que surgem durante
as fases subsequentes do Ciclo de Vida de Servio. Portanto Design de
Servios deve consolidar as questes fundamentais de projeto e atividades de TI
e todos os Servio de Gesto de processoes dentro de suas atividades de
design prprios, para garantir que todos os aspectos so considerados e
includos dentro de todos os projetos para servios novos ou modificados como
parte do processo cotidiano operao.
A capacidade de medir e demonstrar o valor para o negcio exige a capacidade
de vincular negcio resultados, objetivos e seus processos subjacentes e
funes para os servios de TI e de seus ativos subjacentes, processos e
funes. Este valor deve ser articulado por:

Concordando nvel de servios, SLAs e metas de toda a empresa,


garantindo a crtica processo de negcioes receber mais ateno

ITIL V3 - Service Design - Pgina:

35 de 477

Medio de TI qualidade no negcio /usurio termos, relatando o que


relevante para os usurios (por exemplo, cliente satisfao, o valor do
negcio)
Mapeamento de processos de negcios para Infra-estrutura de TI, Uma
vez que novos componentes so adicionados continuamente,
aumentando a possibilidade de interferncias causadas por TI e perda de
foco servio de negcios e os processos
Mapeamento de processos de negcio para as empresas e servio
medies, tornando os servios de TI se concentrar em medidas
relacionadas aos principais aspectos do negcio atuao
Infra-estrutura de mapeamento recursos para os servios, a fim de tirar
pleno partido das crticas componentes de TI dentro da Gerenciamento da
Configurao Sistema (CMS), que esto ligados a processos crticos de
negcio. Isso tambm pode usar a informao completa dentro do
Sistema de Gesto de Conhecimento Servio (SGCS). Mais informaes
podem ser encontradas no CMS dentro do Transio de Servio
publicao
Fornecer end-to-end de desempenho monitoramento e medio de
processos de negcios on-line, periodicamente relatados contra SLA
alvos.

Muitas vezes, o projeto de um grande servio novo ou alterado vai exigir que o
projeto mudars so considerados, e muitas vezes afectam ou que so afectadas
por todos os outros quatro fases do Servio Ciclo de Vida. essencial, portanto,
que os sistemas de TI e servios so concebidos, planejada, implementada e
gerida de forma adequada para o negcio como um todo. A exigncia, ento
fornecer servios de TI que:

So-business e orientada para o cliente, focado e dirigido


So rentveis e seguras
So flexveis e adaptveis, ainda apto para o efeito no ponto de entrega
Pode absorver uma demanda cada vez maior no volume e velocidade da
mudana
Atender s demandas de negcios crescentes para operao contnua
So gerenciados e operados a um nvel aceitvel de risco
So sensveis, com as devidas disponibilidade adequada s
necessidades de negcio.

Com todas essas presses sobre a TI e os negcios, a tentao - e,


infelizmente, a realidade em alguns casos - 'cortar' no projeto e planejamento
processos ou ignor-los completamente. No entanto, nestas situaes, as
atividades de design e planejamento so ainda mais essenciais para a entrega
total de qualidade servios. Portanto, mais tempo do que menos deve ser
dedicada aos processos de projeto e sua implementao.

ITIL V3 - Service Design - Pgina:

36 de 477

A fim de que o design, da qualidade eficaz pode ser conseguida, mesmo quando
so curtos prazos e presso para fornecer servios elevada, organizaos,
deve assegurar que a importncia do Desenho de Servio funo totalmente
compreendida, e que o suporte fornecido para manter e amadurecer Design de
Servios como um elemento fundamental da Servio de Gesto de. As
organizaes devem se esforar continuamente para revisar e melhorar a sua
Service Design capacidade, A fim de que Service Design pode tornar-se uma
consistente e repetvel prtica, Permitindo que as organizaes forneam
servios de qualidade contra prazos desafiadores. Tendo uma prtica do Design
maduro servio tambm permitir que as organizaes reduzam risco no
transio e operacional estgios de servio.
Em geral, a chave para o sucesso da proviso De servios de TIs um nvel
adequado de projeto e planejamento para determinar qual projetos, processoes
e os servios tiverem maior impacto ou benefcio para o negcio. Com o nvel
adequado de pensamento, design, preparao e planejamento, esforo pode ser
orientada para as reas que produzem o maior retorno. Avaliao de risco e
gesto so requisitos fundamentais dentro de todas as atividades do projeto.
Portanto, todos os cinco aspectos do Desenho de Servio deve incluir a
avaliao e gesto de riscos como uma parte integrada inerente de tudo o que
fazem. Isso ir garantir que os riscos envolvidos na prestao de servios e da
operao de processos, tecnologia e mtodos de medio esto alinhados com
o risco do negcio e impacto, porque a avaliao e gesto de riscos esto
embutidos em todos os processos de projeto e atividades.
Muitos projetos, planos e projetos falham por falta de preparao e de gesto. A
implementao de ITIL Servio de Gesto de como uma prtica sobre como
preparar e planejar o uso eficaz e eficiente dos quatro Ps: as pessoas, os
processos, os produtos (servios, 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 - Pgina:

37 de 477

No entanto, no h nenhum benefcio na produo de desenhos, planos,


arquiteturas e polticas e mant-los para si mesmo. Eles devem ser publicadas,
concordou, divulgado e usado ativamente.
A fim de assegurar que os negcios e servios de TI permanecem
sincronizados, muitas organizaes formar comits de gerncia snior do
negcio e de TI. O comit carrega a responsabilidade geral de fixao governo,
Direo, poltica e estratgia para servios de TI. Muitas organizaes referemse a esse grupo como a Estratgia de TI ou Grupo de Coordenao. (ISG). A
funo de um ISG actuar como um parceria entre a TI eo negcio. Ele deve se
reunir regularmente e analisar o negcio e as estratgias de TI, projetos, planos,
Portflio de Servios, Arquiteturas e polticas para assegurar que eles esto
alinhados uns com os outros. Deve proporcionar o viso, Definir a direo 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 tambm
deve garantir que prazos irrealistas, o que poderia comprometer a qualidade ou
perturbar normais requisitos operacionais, no so impostas ou tentado por
qualquer negcio ou de TI. Veja a Figura 2.5.
O ISG vai incluir discusses sobre todos os aspectos do negcio que envolvem
servios de TI, bem como proposta ou possvel mudar num estratgico nvel.
Assuntos para o ISG para discutir podem incluir:

Reviso de negcios e planos de TI: Para identificar qualquer alterao


em qualquer rea que desencadeiam a necessidade de criar, aumentar
ou melhorar servios
Demanda planejamento: Para identificar eventuais mudanas na
demanda para ambos os horizontes de planejamento de curto e longo
prazo; tais mudanas podem ser aumentos ou diminuies na demanda,
e preocupao tanto de negcios como de costume e projetos
Autorizao do projecto e priorizao: Para garantir que projetos so
autorizados e priorizadas para a satisfao mtua de ambas as empresas
e TI
Comente de projetos: Garantir que os benefcios comerciais esperados
esto sendo realizados de acordo com o projeto caso de negcios, e
identificar se os projetos esto dentro do cronograma
Potencial terceirizao: Identificar a necessidade eo contedo das
estratgias de sourcing para o De servios de TI proviso
Negcios / TI reviso da estratgia: Discutir mudanas importantes
para a estratgia de negcios e as principais mudanas propostas para TI
estratgia e tecnologia, para garantir o alinhamento contnuo
Continuidade de Negcios e de TI da Continuidade do Servio: O
grupo, ou um grupo de trabalho do grupo, responsvel pelo alinhamento
de Continuidade de Negcios e estratgias de TI continuidade de servio
Polticas e normas: O ISG responsvel por garantir que as polticas de
TI e padres, particularmente em relao estratgia financeira e gesto

ITIL V3 - Service Design - Pgina:

38 de 477

de desempenho, Esto no lugar e alinhada com a corporativa global viso


e objetivos.

Figura 2.5 O Grupo de Coordenao de TI / Estratgia

O Grupo de Coordenao de TI estabelece o rumo para as polticas e planos de


empresa para operacional nveis de organizao de TI e garante que eles so
compatveis com estratgias de nvel empresarial. Veja a Figura 2.5.
O ISG tem um importante papel a desempenhar no alinhamento dos negcios e
estratgias de TI e planos como ilustrado na figura 2.5. Como pode ser visto, o
Portflio de Servios uma das principais fontes de entrada para o ISG no seu
papel de tomada de deciso, que permite que o ISG para:

Dirigir e orientar a seleo de investimentos em reas que produzem o


maior valor de negcio e Retorno sobre Investimento
Realize eficaz programa e projeto de seleo, priorizao e planejamento
Exercer a governana eficaz e contnuo de gesto activa do 'pipeline' de
requisitos de negcios
Assegurar que os benefcios de negcios projetados de programas e
projetos so realizados.

ITIL V3 - Service Design - Pgina:

39 de 477

2.4.3 Valor para os negcios


Com boa Design de Servios, possvel entregar qualidade, O custo-benefcio
servios e para assegurar que os requisitos de negcio esto sendo atendidas.
O resultado seguintes benefcios de Service Design boa prtica:

Reduzido Custo Total de Propriedade (TCO):custar de propriedade s


pode ser minimizado se todos os aspectos de servios, processos e
tecnologia so concebidas e implementadas corretamente contra o
projeto
Melhoria da qualidade de servio: Tanto a qualidade de servio e
operacional ser reforada
Melhor consistncia de servio: Como os servios so projetados
dentro da empresa estratgia,arquiteturas e constrangimentos
Mais fcil implementao de servios novos ou alterados: Como no
h integrada e completa Design de Servios e a produo de SDPs
abrangentes
Alinhamento melhor servio: Envolvimento, desde a concepo do
servio, garantindo que os servios novos ou alterados corresponder s
necessidades de negcios, com servios destinados a satisfazer Nvel
Requisitos de Servio
Desempenho do servio mais eficaz: Com incorporao e
reconhecimento de Disponibilidade capacidade financeira, e TI Plano de
Continuidade do Servios
Melhorou TI governo: Ajudar na implementao e comunicao de um
conjunto de controlars para uma governao eficaz da TI
Mais eficaz Servio de Gesto de e processos de TI:processoes ser
projetado com tima qualidade e custo-eficcia
Melhoria da informao e tomada de deciso: Mais abrangente e
eficaz medies e mtricos vai permitir a melhoria melhor tomada de
deciso e contnua de Servio de Gesto de prticas na fase de
concepo do Ciclo de Vida do Servio.

2.4.4 Otimizando o desempenho do projeto


A otimizao de projeto atividades requer a implementao de processos
documentados, juntamente com uma imperiosa sistema de gesto da qualidade
(Tais como ISO 9001) Para sua medio contnua e aperfeioamento.
importante que, ao considerar a melhoria e otimizao do Design de Servios
atividades, o impacto das atividades em todos os estgios do ciclo de vida deve
ser medida e no apenas o impacto na fase de concepo. Portanto medies
de servios de design e mtricas deve olhar para a quantidade de retrabalho
atividade e atividades de melhoria que necessrio em transio,operao e
melhoria atividades como resultado de deficincias na concepo de solues

ITIL V3 - Service Design - Pgina:

40 de 477

de servios novos e modificados. Mais informaes sobre a medio de Design


de Servios pode ser encontrado na seo 8.5.

2.4.5 Processos dentro de Design de Servios


Esta detalhes publicao processos necessrios na fase de projeto do Ciclo de
Vida de Servio. Esses processos no pode ser considerado isoladamente,
como o seu verdadeiro valor s ser realizado quando as interfaces entre os
processos so identificadas e acionadas. Os seguintes processos so
detalhadas neste documento:

Gerenciamento de Catlogo de Servio: Para garantir que uma


Catlogo de Servios produzido e mantido, contendo informao
precisa sobre todos operacional servios e aqueles que esto sendo
preparados para ser executado operacionalmente
Gerenciamento de Nvel de Servio: Negocia, concorda e documentos
apropriados De servios de TI alvos com representantes da negcioE, em
seguida, monitora e produz relatrios sobre a provedor de
serviosCapacidade 's para fornecer o nvel de servio acordado
Gerenciamento da Capacidade: Garantir que custo justificvel de TI
capacidade em todas as reas de TI sempre existe e adaptado s
necessidades atuais e futuras acordadas do negcio, em tempo hbil
Gerenciamento de Disponibilidade: Para assegurar que o nvel de servio
disponibilidade entregues em todos os servios correspondente a, ou
exceder as necessidades atuais e futuras acordadas do negcio, de uma
maneira custo-efetiva
Gerenciamento da Continuidade do Servio: Garantir que as instalaes
de TI necessrios tcnicos e de servios (incluindo sistemas de
computadores, redes, aplicaos, repositrios de dados,
telecomunicaes, ambiente,suporte tcnico e Service Desk) pode ser
retomada dentro necessrio e acordado, negcios prazos
Gesto de Segurana da Informao: Para alinhar a TI com os negcios
de segurana seguranaE garantir que a segurana da informao
gerido de forma eficaz em todos os servios e Servio de Gesto de
atividades
Gesto de Fornecedores: Gerir fornecedors e os servios que eles
fornecem, para oferecer perfeita qualidade de servio de TI ao negcio,
garantindo valor para o dinheiro obtido.

Estes so apenas alguns dos processoes descritas no ITIL Servio de Gesto


de orientao prtica. Todos os processos no Servio de Gesto de ciclo de vida
deve ser ligado em conjunto para gerenciar, projetar, suporte e manuteno dos
servios, Infra-estrutura de TI, Meio ambiente, aplicaes e dados. Outros
processos so descritos em detalhe em outras publicaes na biblioteca ITIL
Service Management ncleo prticas. As interfaces entre todos os processos e
todos os outros processos devem ser claramente definidas na concepo de um

ITIL V3 - Service Design - Pgina:

41 de 477

servio ou melhoria ou implementao de um processo. Estas interfaces so


descritas em detalhe na seco 4 e incluem no apenas as interfaces para cada
um dos Design de Servios processos, mas tambm interfaces para processos
dentro de outras etapas do ciclo de vida.
Ao projetar um servio ou um processo, imperativo que todos os papels esto
claramente definidos. A marca de de alto desempenho organizaos a
capacidade de tomar as decises certas rapidamente e execut-los
rapidamente. Se a deciso envolve estratgico escolha ou uma operao crtica,
ser claro sobre quem tem de entrada, quem decide e quem toma a ao vai
permitir que a organizao para avanar rapidamente.

ITIL V3 - Service Design - Pgina:

42 de 477

3 Projeto princpios do servio


Veja primeiro que o projeto sbio e justo: aquele apurado, persegui-lo
resolutamente, no 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 Servios uma parte do processo geral de mudana negcio. Este


processo de mudana de negcios eo papel de TI so ilustrados na figura 3.1.

Figura 3.1 O processo de mudana de negcios

Uma vez que as informaes exactas tenha sido obtido com o que necessrio
e assinado, no que diz respeito s necessidades modificadas do negcio, O
plano para a prestao de um servio para atender a necessidade concordou
pode ser desenvolvida.
O papel do estgio de Design de Servios dentro desta mudana global de
negcios processo pode ser definida como:
'A projeto de adequada e inovadora De servios de TIs, incluindo as suas
arquiteturas, processos, polticas e documentao, para atender s atuais e
futuros requisitos de negcios acordados. "
importante que as interfaces corretas e links para as atividades de design
existem. Ao projetar servios novos ou modificados, vital que todo o ciclo de
vida de servio e processos de ITSM esto envolvidos desde o incio. Muitas
vezes ocorrem dificuldades em operaes quando um servio recm-projetado
entregue para executar ao vivo no ltimo minuto. A seguir, so aes que
precisam ser realizadas a partir do incio de um Design de Servios para
assegurar que a soluo cumpre os requisitos da empresa:

ITIL V3 - Service Design - Pgina:

43 de 477

A soluo de servio novo deve ser adicionado ao total Portflio de


Servios desde a fase de conceito, e da Carteira de servio deve ser
atualizado para refletir a atual estado atravs de qualquer incremental ou
iterativa desenvolvimento. Isto ser benfico no s do ponto de vista
financeiro, mas tambm de todas as outras reas durante o projeto.
Como parte do primeiro servio/ Sistema de anlise, haver uma
necessidade de compreender o Nvel Requisitos de Servio (SLR) para o
servio 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
suportar o novo servio. Se o tempo permitir, os resultados do
modelagem actividades podem ser incorporadas ao Plano de capacidade.
Se nova infra-estrutura necessria para o novo servio, ou de suporte
estendido, Gesto Financeira ter que ser envolvidos para definir o
oramento.
Uma primeira Anlise de Impacto no Negcio e avaliao de risco deve
ser realizado em servios bem antes da implementao como entrada de
valor inestimvel em Estratgia de TI da Continuidade do Servio, Design
Disponibilidade e Planejamento de Capacidade.
O Service Desk ter de tomar conhecimento de novos servios com
antecedncia de ao vivo operao para preparar e treinar a equipe de
Service Desk e potencialmente equipe de TI do cliente.
Transio de Servio pode comear planejamento a implementao e
construir no cronograma de mudana.
Gesto de Fornecedores ter de ser envolvido se de concurso
necessrio para o novo servio.

A composio de um servio e as suas partes constituintes ilustrado na Figura


3.2.

ITIL V3 - Service Design - Pgina:

44 de 477

Figura 3.2 A composio de servios

Design de Servios deve considerar todos esses aspectos na concepo de


solues de servios para atender s necessidades de negcios novos e em
desenvolvimento:

Processo de negcio: Definir as necessidades funcionais do servio a ser


prestado, por exemplo, televendas, faturamento, pedidos, verificao de
crdito
Servio: O prprio servio que est sendo entregue ao clientes e de
negcios pela provedor de servios, E.g. e-mail de cobrana,
SLAs / SLRs: Os documentos acordados com os clientes que
especificam o nvel, escopo e qualidade de servio a ser prestado
Infra-estrutura: Todos os equipamentos de TI necessrias para a
entrega do servio para os clientes e usurios, incluindo servidors,
circuitos de rede, switches, computadores, telefones
Ambiente: O ambiente necessrio para proteger e operar a infra-estrutura,
por exemplo, centros de dados, energia, ar condicionado
Dados: Os dados necessrios para apoiar o servio e fornecer as
informaes requeridas pelos processos de negcios, por exemplo,
cliente registros, contas contbeis
Aplicaos: Todos os aplicativos de software necessrios para manipular
os dados e fornecer os requisitos funcionais dos processos de negcios,
por exemplo, ERM, Financeiro, CRM
Servios de Suporte: Todos os servios que so necessrios para
apoiar a operao do servio prestado, por exemplo, um servio
compartilhado, um servio de rede gerenciada

ITIL V3 - Service Design - Pgina:

45 de 477

Acordo de Nvel Operacionals (ANO) e contratos: Qualquer fundamento


acordos necessrios para libertar a qualidade do servio acordado no
SLA
Equipas de Apoio: Quaisquer equipes internas de apoio que fornecem
segunda e terceira linha de apoio para qualquer um dos componentes
necessrios para prestar o servio, por exemplo, Unix, mainframe, redes
Fornecedors: Quaisquer partes externas terceiros necessrios para
proporcionar suporte de terceira e quarta linha para qualquer um dos
componentes necessrios para fornecer o servio, por exemplo, redes,
hardware, software.

O projeto actividades no deve considerar apenas cada um dos componentes


acima isoladamente, mas tambm deve considerar o relaos entre cada um
dos componentes e suas interaes e dependncias em quaisquer outros
componentes e servios, a fim de fornecer uma soluo eficaz e abrangente,
que atenda as necessidades do negcio.

ITIL V3 - Service Design - Pgina:

46 de 477

3,1 Metas
Os principais objetivos e objetivos de Design de Servios so os seguintes:

Servios de design para satisfazer objetivo de negcios, com base na


qualidade de conformidade, risco e segurana requisitos, fornecendo
mais eficaz e eficiente de TI e solues de negcios e servios alinhados
s necessidades do negcio, coordenando todas as atividades de projeto
para De servios de TIs para garantir consistncia e foco de negcios
Servios de design que podem ser facilmente e eficientemente
desenvolvidos e melhorados dentro de prazos adequados e custars, e,
sempre que possvel, reduzir, minimizar ou restringir os custos de longo
prazo de prestao de servios
O design eficiente e eficaz processoes para a concepo, transio,
Operao e melhoria dos servios de alta qualidade, juntamente com as
ferramentas de apoio, sistemas e informaes, especialmente os Portflio
de Servios, Para gerenciar os servios atravs de seu ciclo de vida
Identificar e gerenciar os riscos, para que possam ser eliminados ou
reduzidos antes que os servios vo viver
Design seguro e resistente Infra-estrutura de TIs, ambientes aplicaos e
os dados / informaes recursos e capacidade que atendam as
necessidades atuais e futuras do negcio e os clientes
Projeto mtodos de medio e mtricos para avaliar a eficcia e eficincia
dos processos de projeto e de seus entregas
Produzir e manter planos de TI, processos, polticas, arquiteturas,
quadros e documentos para o projeto de qualidade Solues de TI, para
atender as necessidades atuais e futuras de negcios acordados
Auxiliar na desenvolvimento de polticas e normas em todas as reas de
concepo e planeamento de servios de TI e processos, recebendo e
atuando no feedback sobre os processos de design de todas as outras
reas e incorporando as aes em um processo contnuo de melhoria
Desenvolver as habilidades e capacidade dentro de TI, movendo
estratgia e atividades de projeto em operacional tarefas, fazendo uso
eficaz e eficiente de todos os recursos de servios de TI
Contribuam para a melhoria da qualidade global do servio de TI, dentro
das limitaes impostas pelo projecto, especialmente atravs da reduo
da necessidade de refazer e melhorar servios, uma vez que tm sido
implementadas no ambiente ao vivo.

ITIL V3 - Service Design - Pgina:

47 de 477

3,2 projeto equilibrado


Para quaisquer novos requisitos de negcios, o projeto de servios um ato de
equilbrio delicado, garantindo que no s os requisitos funcionais, mas tambm
a atuao metas sejam atingidas. Tudo isso precisa ser equilibrado no que diz
respeito aos recursos disponveis dentro do prazo exigido e custars para os
novos servios. Jim McCarthy, autor de Dinmica de Desenvolvimento de
Software, Afirma: "Como um gerente de desenvolvimento, voc est trabalhando
com apenas trs coisas":

Funcionalidade: O servio ou produto e suas instalaes, funcionalidade


e qualidade, Incluindo todas as funcionalidades de gesto e operacional
necessria
Recursos: As pessoas, tecnologia e dinheiro disponvel
Programar: Os prazos.

Estes so apresentados na Figura 3.3.

ITIL V3 - Service Design - Pgina:

48 de 477

Figura 3.3 Elementos do projeto em uma relao triangular

Este conceito muito importante para Design de Servios actividades e para o


equilbrio entre o esforo que gasto no projeto, desenvolvimento e prestao
de servios em resposta s exigncias do negcio. Design de Servios um ato
de equilbrio delicado dos trs elementos eo ajuste constante dinmica de todos
os trs para atender as necessidades de negcio. Alterando um lado do
tringulo, invariavelmente tem um impacto sobre, pelo menos, um dos outros
lados, se no ambos. vital, por conseguinte, que os condutores de negcios e
necessidades so completamente compreendidos, de modo que as solues
comerciais mais eficazes so concebidos e entregues, utilizando o equilbrio
mais adequado destes trs elementos. provvel que os motoristas de negcio
e as necessidades vo mudar durante o projeto e entrega, devido a presses do
mercado. A funcionalidade e os recursos devem ser considerados para todas as

ITIL V3 - Service Design - Pgina:

49 de 477

fases do ciclo de vida de servio, para que os servios no so apenas


concebido e desenvolvido de forma eficaz e eficiente, mas que a eficcia e
eficincia do servio mantida ao longo de todas as fases da sua ciclo de vida.
A devida ateno deve ser dada dentro de Design de Servios em todas as
fases subseqentes dentro do Ciclo de Vida do Servio. Muitas vezes, os
designers e arquitetos considerar apenas o desenvolvimento de um novo servio
at o tempo de execuo do servio para o viver ambiente. Uma abordagem
holstica para a concepo de servios de TI devem ser adotadas para garantir
que uma soluo totalmente integrada e abrangente foi projetado para atender
os requisitos acordados para a negcio. Esta abordagem deve tambm garantir
que todos os mecanismos necessrios e funcionalidades so implementadas
dentro do novo servio, para que possa ser gerido de forma eficaz e melhorado
ao longo de sua vida operacional para atingir todas as suas metas de servio
acordados. Uma abordagem formal, estruturada devem ser adotadas para
garantir que todos os aspectos do servio so abordados e garantir a sua
introduo suave e operao dentro do ambiente ao vivo.
O mais eficaz Provedor de servios 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
padres, desenhos e arquiteturas que satisfazem todos da gesto e operacional
necessidades dos servios, bem como a funcionalidade exigida pelo negcio.
Este projeto integrado garante que, quando um servio novo ou alterado
implementado, ele no s fornece a funcionalidade exigida pelo negcio, mas
tambm atende e continua a satisfazer todas as suas nvel de servios e metas
em todas as reas. Isso garante que nenhuma fraqueza (ou mnimo absoluto)
ter de ser abordado de forma retrospectiva.
A fim de conseguir isso, a gesto global dessas atividades de projeto deve
garantir:

Boa comunicao entre as atividades de design diferentes e todas as


outras partes, incluindo o negcio e TI planejadores e estrategistas
O mais recente versos de todos os negcios e de TI apropriada planos e
estratgias esto disponveis para todos os designers
Todos os documentos de arquitetura e documentos do projeto so
consistentes com todos os negcios e polticas de TI e planos
O arquiteturas e desenhos:
o So flexveis e permitem que a TI responder rapidamente s
necessidades de novos negcios
o Integrar-se com todas as estratgias e polticas
o Apoiar as necessidades de outras etapas do ciclo de vida de
servio
o Facilitar os servios de qualidade novos ou alterados e solues,
alinhados com as necessidades e prazos do negcio.

ITIL V3 - Service Design - Pgina:

50 de 477

3,3 Identificar necessidades de servio


Design de Servios deve considerar todos os elementos do servio, tendo uma
abordagem holstica para o projeto de um novo servio. Esta abordagem deve
considerar o servio e seu constituinte componentes e suas inter-relaes,
garantindo que os servios prestados atender a funcionalidade e qualidade de
servio esperada pela empresa em todas as reas:

O escalabilidade do servio para satisfazer os requisitos futuros, em apoio


a longo prazo objetivo de negcios
O processo de negcioes e unidade de negcioss suportados pelo
servio
O De servios de TI ea funcionalidade de negcios e requisitos acordados
O servio em si e sua Exigncia de Nvel de Servio (SLR) ou Acordo de
Nvel de Servio (SLA)
Os componentes de tecnologia utilizados para implementar e entregar o
servio, incluindo a infra-estrutura, o ambiente, os dados e os aplicaos
O internamente suportado servios e componentes e suas associadas
Acordo de Nvel Operacionals (ANO)
Os servios de apoio externo e componentes e de seus associados
subjacente contratos, o que, muitas vezes, tm a sua prpria relacionada
acordos e / ou horrios
O atuao medies e mtricos exigido
O legislado ou exigido segurana nveis.

O relaos e dependncias entre esses elementos encontram-se ilustrados na


Figura 3.4.

ITIL V3 - Service Design - Pgina:

51 de 477

Figura 3.4 A relao de servio e dependncias

Nenhum servio pode ser concebido, transio e operado de forma isolada. A


relao de cada servio ao seu apoio componentes e os servios devem ser
claramente compreendida e reconhecida por todas as pessoas dentro da
provedor de servios organizao. Tambm essencial que todas as metas
contidas dentro de apoio acordos, tais como e OLAs contratos, sustentam os
acordados entre o provedor de servios e os seus clientes. Alguns desses
conceitos so discutidos em mais detalhe nas seces posteriores da
publicao, no que diz respeito aos aspectos individuais da Design de Servios.
No entanto, quando um aspecto individual de um servio alterada, todas as
outras reas do servio tambm deve ser considerada para assegurar que as
alteraes necessrias para suportar o mudar esto includas na concepo
global. Cada vez mais, os servios so complexos e so fornecidos por um
nmero de scio ou fornecedor organizaes. Onde mltiplos provedor de
servioss esto envolvidos na prestao de um servio, vital que uma central
Design de Servios autoridade estabelecida, para garantir servios e
processoes esto totalmente integradas em todas as partes.
Dentro da rea especfica de tecnologia h quatro domnios tecnolgicos
distintos que precisam ser resolvidas, como so as componentes de apoio de
todos os servios e contribuir para o seu desempenho global:

Infra-estrutura: A gesto 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, servios pblicos,
apoio sistemas, firewalls, desenvolvimento e teste ambientes, ferramentas
de gesto, etc
Ambiental: A gesto e controlo de todos os aspectos ambientais de todas
as salas de equipamentos principais, incluindo o espao fsico e
disposio, energia, ar condicionado, cabeamento, fsica segurana, Etc
Dados: A gesto e controlo de todos os dados e informaes e de acesso
associado, incluindo dados de teste, quando aplicvel
Aplicaos: A gesto e controlo de todos os softwares aplicativos,
incluindo tanto comprados em aplicativos e em casa desenvolvido
aplicaes de software.

ITIL V3 - Service Design - Pgina:

52 de 477

3,4 Identificar e documentar os requisitos de negcios e


motoristas
TI deve manter informaes precisas sobre os requisitos de negcios e
motoristas se para fornecer o catlogo mais adequada de servios com um
nvel aceitvel de servio qualidade que est alinhada s necessidades do
negcio. Drivers de negcio so as pessoas, informaes e tarefas que
suportam o cumprimento dos objetivos do negcio. Isto requer que a TI
desenvolve e mantm relaes estreitas, regular e adequada e troca de
informaes, a fim de compreender o operacional,ttico e estratgico requisitos
da negcio. Esta informao deve ser obtida e concordou em duas reas
principais para manter o alinhamento do servio:

Informaes sobre os servios existentes - Que mudanas sero


necessrias aos servios j existentes no que diz respeito a:
o Novas instalaes e requisitos de funcionalidade
o Mudanas nas processo de negcioes, as dependncias, as
prioridades criticidade, e impacto
o Mudanas nos volumes de servio transaos
o Aumento nvel de servios e meta de nvel de servios devido a
motorista de novos negcios, ou reduzido para servios de idade,
reduzindo a prioridade para aqueles devido a substituio
o Necessidades adicionais de Servio de Gesto de informao.
o
Informaes sobre as exigncias de novos servios:
o Instalaes e funcionalidades necessrios
o Gesto da informao necessidades requeridas e gesto
o Processos de negcio suportados, as dependncias, as
prioridades criticidade e impacto
o Os ciclos de negcios e variaes sazonais
o Nvel de exigncias de servio e meta de nvel de servios
o Negcio transao nveis, os nveis de transaes de servios,
nmeros e tipos de usurios e crescimento futuro antecipado
o Justificativa de negcios, incluindo a financeira e estratgico
aspectos
o Nvel previsto de mudar, E.g. requisitos futuros conhecidos de
negcios ou de melhoria
o Nvel de negcios capacidade ou o apoio a conceder, por exemplo,
apoio s empresas com base local.

Esta recolha de informao o primeiro passo eo mais importante para a


concepo e oferta de novos servios ou grandes mudanas para os servios
existentes. A necessidade de informaes precisas e representante da negcio
primordial. Isso deve ser acordado e assinado com altos representantes dentro
da empresa. Se a informao incorreta ou enganosa obtido e utilizado nesta
fase, ento todas as fases subsequentes ser a prestao de servios que no

ITIL V3 - Service Design - Pgina:

53 de 477

correspondem s necessidades do negcio. Alm disso, tem de haver alguma


formais processo para o acordo ea aceitao de mudanas nos requisitos de
negcio, uma vez que estes, muitas vezes, mudar e evoluir durante o Ciclo de
Vida de Servio. Os requisitos e as projeto deve evoluir com o negcio em
mudana ambiente para assegurar que as expectativas de negcios so
cumpridos. No entanto, este processo deve ser cuidadosamente controlados
para assegurar que a taxa de modificao mantido a um nvel combinado e
manejvel, e no "pntano" e excessivamente atrasar o projeto sua execuo.
A fim de projetar e entregar De servios de TIs que atendam as necessidades
dos clientes e do negcio, clara, concisa, sem ambiguidades especificaos dos
requisitos devem ser documentados e acordados. O tempo gasto nessas
atividades vai evitar problemas e discusso de surgir mais tarde em relao ao
variaos do cliente e expectativa de negcios. Esse negcio de estgio
requisitos deve ser composto de:

Nomeao de um gerente de projeto, a criao de uma equipa de


projecto e do contrato de projeto governo pela aplicao de uma
metodologia de projeto formal, estruturado
Identificao de todas as partes interessadas, incluindo a documentao
de todos os requisitos de todas as partes interessadas e das partes
interessadas benefcios que ir obter com a implementao
Anlise de requisitos, priorizao de acordo, e documentao
Determinao e acordo de esboo oramentos e benefcios comerciais. O
oramento deve ser cometido pela administrao, porque normal prtica
para decidir oramento do prximo ano, no ltimo trimestre do ano
anterior, portanto, quaisquer planos devem ser apresentados dentro deste
ciclo
A resoluo do conflito potencial entre unidade de negcioss e acordo
sobre os requisitos corporativos
Registe-off processos para os requisitos acordados e um mtodo para
concordar e aceitar mudanas 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 relaos entre a TI e os negcio e como essas relaes e
comunicao necessrias para maior das partes interessadass sero
gerenciados.

Quando os requisitos de servio esto em causa, s vezes eles vm com uma


etiqueta de preo (que pode no ser totalmente conhecido nesta fase), ento
no precisa sempre de haver um equilbrio entre a servio alcanvel eo custar.
Isso pode significar que alguns requisitos pode ser demasiado caro para incluir e
pode ter que ser descartado durante o exerccio avaliao envolvido na projeto
processo. Se isso for necessrio, todas as decises de omitir quaisquer

ITIL V3 - Service Design - Pgina:

54 de 477

requisitos de servio a partir da concepo do servio deve ser documentado e


acordado com os representantes das empresas. H muitas vezes uma
dificuldade quando o que a empresa quer eo oramento alocados para a soluo
no levam em conta os custos de servio completo, incluindo os custos em
curso

ITIL V3 - Service Design - Pgina:

55 de 477

3,5 As atividades de projeto


Todas as atividades do projeto so acionados por mudars em necessidades de
negcio ou melhorias de servios. Uma abordagem estruturada e holstica para
as atividades de projeto devem ser adoptadas, de modo que toda a informao
disponvel considerado para garantir consistncia e integrao alcanada ao
longo do Provedor de servios de TI organizao, Em todas as atividades do
projeto.
Arquiteturas e os projetos devem ser mantidos, clara, concisa, simples e
relevante. Com muita freqncia, os projetos e arquiteturas so complexas e
terico e no se relacionam com o "mundo real".
O principal problema hoje que as organizaes geralmente se concentrar
apenas nos requisitos funcionais. Um projeto ou arquitetura, por definio, tem
de considerar todos os aspectos do projeto. No uma organizao menor que
combina esses aspectos, sensata.
O projeto atividades de processos so:

Requisitos coleta, anlise e engenharia para assegurar que os requisitos


de negcio so claramente documentados e acordados
Design de servios adequados, tecnologia, processomedio da
informao es, e processo para atender aos requisitos de negcios
Comente e reviso de todos os processos e documentos envolvidos na
Design de Servios, Incluindo desenhos, planos, arquiteturae as polticas
Ligao com todo o projeto e outros planejamento atividades e funes,
por exemplo, projeto de soluo
Produo e manuteno de polticas de TI e documentos de projeto,
incluindo desenhos, planos, arquiteturas e polticas
Reviso de todos os documentos de projeto e planejamento para a
desenvolvimento e implementao de estratgias de TI usando 'roteiros',
programas e planos de projeto
Avaliao de risco e gesto de todos os processos de concepo e
entregas
Garantindo o alinhamento com todos corporativa e estratgias de TI e
polticas.

As entradas para as atividades de design diferentes so:

Corporativo visos, as estratgias, objetivos, polticas e planos, vises de


negcios, estratgias, objectivos e planos, incluindo Plano de
Continuidade de Negcioss (SBDC)
Condicionalismos e exigncias para a conformidade com as normas e
regulamentos legislados

ITIL V3 - Service Design - Pgina:

56 de 477

Estratgias de TI e estratgico (a partir de documentos Estratgia de


Servio):
o Todas as estratgias de TI, polticas e planos estratgicos
o Detalhes de requisitos de negcio
o Todas as restries, financeiras oramentos e os planos
o O Portflio de Servios
o Servio de Gesto de visos, estratgias, polticas, objetivos e
planos
o TI e Servio de Gesto de processoes, os riscos e as questes
registra
o Transio de Servio planos (de Mudana, Configurao e
Release e Planos de Gesto de implantao)
o Segurana polticas, manuais e planos
o A aquisio e contrato poltica,fornecedor estratgia e Gesto de
Fornecedores processos
o O conhecimento pessoal atual, habilidades e capacidade
o TI planos de negcios, planos de negcios e de TI de qualidade e
polticas
o Servio de Gesto de planos, incluindo Gerenciamento de Nvel de
Servio Planos, SLAs e SLRs, Plano de Melhoria de Servio (SIP),
Plano de capacidades, Plano de disponibilidades, TI Plano de
Continuidade do Servios
Ferramentas de medio e tcnicas

Os resultados das atividades do projeto so:

Revises sugeridas para as estratgias de TI e polticas


Projetos, planos e revistas de tecnologia e gesto arquiteturas, incluindo:
o O Infra-estrutura de TI e gesto de infra-estrutura e meio ambiente
estratgia, Desenhos, planos, arquiteturas e polticas
o O aplicaos estratgias e dados, desenhos, planos, arquiteturas e
polticas
Projetos para servios novos ou modificados, processos e tecnologias
Processo de relatrios de avaliao e anlise, com processos revistos e
melhorados e procedimentos
Revistos os mtodos de medio e processoes
Nveis gerenciados de riscoRelatrios, de risco e de avaliao e gesto
Casos de negcios e estudos de viabilidade, com as declaraes de
Requisitos (Sors) e concursos (ITTs)
Comentrios e opinies sobre todos os outros planos
Benefcio do negcio e realizao revers e relatrios.

ITIL V3 - Service Design - Pgina:

57 de 477

3,6 aspectos de design


Uma abordagem global e integrada deve ser adotado para as atividades de
projeto documentados na seo anterior e deve cobrir o projeto de:

Servio As solues, incluindo todos os requisitos funcionais, recursos e


as capacidades necessrias e acordadas
Servio de Gesto de sistemas e ferramentas, em especial os Portflio de
Servios para a gesto e controlar de servios por meio de sua ciclo de
vida
Tecnologia arquiteturas e gesto arquiteturas e ferramentas necessrias
para prestar os servios
Processos necessrios para projetar, transio,operar e melhorar os
servios
Sistemas de medio, mtodos e mtricos para os servios, as
arquitecturas e seus constituintes componentes e os processos.

O aspecto fundamental a concepo de solues de servios novos ou


alterados para atender s necessidades empresariais em constante mudana.
Cada vez que uma soluo de servio novo produzido, ele tem de ser
verificado em relao a cada um dos outros aspectos para garantir que ela ir
integrar e interface com todos os outros servios j existentes. Estes cinco
aspectos da Design de Servios so abordados com mais detalhes nas sees
seguintes. Os planos produzidos por Design de Servios para o projeto,
transio e subsequente operao destes cinco diferentes aspectos devem
incluir:

A abordagem adoptada e os prazos associados


O organizacional impacto da nova soluo ou alterados em ambos os
negcio e TI
O impacto comercial da soluo no organizao, Incluindo o
financiamento, custars e oramentos exigido
O impacto tcnico da soluo e do pessoal ea sua papels,
responsabilidades, competncias, conhecimentos, formao e
competncias necessrias para implantar, operar, manter e otimizar a
nova soluo para o negcio
A justificativa comercial avaliao do impacto da soluo em negcios
existentes - este impacto deve ser avaliado a partir do ponto de vista de
TI e Servio de Gesto de os processos, incluindo tanto a sua capacidade
e atuao
A avaliao e mitigao de riscos para os servios, processoes e Servio
de Gesto de atividades
Comunicao planejamento e todos os aspectos de comunicao com
todas as partes interessadas
O impacto da soluo em novos ou existentes contratos ou acordos

ITIL V3 - Service Design - Pgina:

58 de 477

O esperado resultados da operao do servio novo ou alterado em


termos mensurveis, geralmente expressa em novo ou existente
Contratos de Nvel de Servio (SLAs), nvel de servios e satisfao do
cliente
A produo de um Pacote de Desenho de Servio (Ver Apndice A)
contendo tudo necessrio para a subsequente introduo de testes e
funcionamento da soluo ou servio
A produo de um conjunto de Critrios de aceitao de servios (SAC)
(ver o Apndice B), que ir ser utilizado para assegurar que o provedor de
servios est pronto para entregar e suportar o novo servio ou alterados
na viver ambiente.

3.6.1 Projetando servio de solues


H muitas atividades que devem ser concludas dentro do Design de Servios
palco para um servio novo ou alterado. Uma abordagem formal e estruturada
necessrio para produzir o novo servio 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 tero de ser envolvido dentro do processo. Este processo deve
ser iterativo / incremental para garantir que o servio prestado atende s
necessidades em constante evoluo e mudana do negcio durante o processo
de negcio desenvolvimento e do ciclo de vida dos servios de TI. Gerentes de
projeto e equipes de projeto adicionais podem precisar de ser alocado para
gerenciar os estgios dentro do ciclo de vida para o desenvolvimento do novo
servio.
O papel da equipa de projecto no mbito desta atividade de fornecimento de
novo e mudando De servios de TIs para o negcio e seu relao conceber
actividades ilustrada na Figura 3.5.

ITIL V3 - Service Design - Pgina:

59 de 477

Figura 3.5 Alinhar novos servios aos requisitos de negcios

Figura 3.5 mostra o ciclo de vida de um servio do negcio inicial ou alterados


exigncia atravs da projeto,transio e operao as fases do ciclo de vida.
importante que haja efetiva transferncia de conhecimento em todas as fases
entre o operacional pessoal e da equipe do projeto para garantir a progresso
suave atravs de cada uma das etapas ilustradas.
As reas que precisam ser considerados no projeto da soluo de servio deve
incluir:

Analisar os requisitos de negcio acordados


Reveja os existentes servios de TI e infra-estrutura e produo de
solues de servios alternativos, com vista a re-utilizao ou explorao
existentes componentes e servios, sempre que possvel
Projetar as solues de servios para os novos requisitos, incluindo os
seus componentes constituintes, em termos de procedimentos e
documentar este projeto:
As instalaes e funcionalidade necessria, e as informaes
necessrias para o monitoramento do atuao do servio ou
processo
O processo de negcioes apoiado, as dependncias, as
prioridades, criticidade e impacto do servio, juntamente com os
benefcios de negcios que sero entregues pelo servio

ITIL V3 - Service Design - Pgina:

60 de 477

Os ciclos de negcios e variaes sazonais, e os negcios


relacionados transao nveis, os nveis de servios de transao,
os nmeros e tipos de usurios e crescimento futuro esperado, e
os requisitos de continuidade de negcios
Nvel Requisitos de Servio e meta de nvel de servios ea
medio do servio necessrio, relatar e analisar as atividades
Os prazos envolvidos e os resultados planejados a partir do novo
servio e do impacto sobre os servios existentes
Os requisitos para o ensaio, incluindo qualquer Usurio Teste de
aceitao (UAT) e as responsabilidades para a gesto dos
resultados dos testes
Certifique-se de que o contedo do Critrios de aceitao de servios
(SAC) so incorporadas e as conquistas necessrios planejado no projeto
inicial
Avaliar e custam projetos alternativos, destacando vantagens, bem como
desvantagens das alternativas
Concordo as despesas e oramentos
Re-avaliar e confirmar os benefcios do negcio, incluindo a Retorno
sobre Investimento (ROI) de o servio, incluindo a identificao e
quantificao de todos os custos de servios e todos os benefcios de
negcios e aumento de receitas. O custars deve cobrir o Custo Total de
Propriedade (TCO) do servio e incluem custos de arranque, tais como os
custos do projeto, transio custos, o oramento do projeto, e todos em
curso custo operacionals, incluindo suporte, gesto e manuteno
Concordam que a soluo preferida e os seus resultados e metas
planejadas (Exigncia de Nvel de Servio (SLR))
Verifique a soluo est em equilbrio com todos corporativa e de TI
estratgias, polticas, planos e documentos arquitetnicos. Se no, rever
soluo ou a estratgico documentao (tomando em considerao o
efeito sobre outros estratgico documentos, servios e componentes),
sempre que possvel re-uso ou explorao de componentes existentes
(por exemplo, objectos de software, 'corporate dados, hardware), a menos
que o estratgia indique o contrrio. A mudana de estratgia envolver
uma quantidade significativa de trabalho e que ser feita em conjunto com
Estratgia de Servio
Garantir que todos os corporativa apropriada e TI governo e segurana
controlars so includos com a soluo de
Conclua prontido organizacional de TI ' avaliao"Para garantir que o
servio possa ser efetivamente utilizado para atingir os seus objectivos
acordados e que o organizao tem o apropriado capacidade para
entregar ao nvel acordado. Isto incluir:
O impacto comercial sobre a organizao de um negcio e tanto
perspectiva de TI, incluindo todos os benefcios comerciais e toda
a custars (os custos de um projeto-off em curso e os custos de
operao anual) envolvidos na projeto,desenvolvimento e em curso
operao e apoio do servio

ITIL V3 - Service Design - Pgina:

61 de 477

Avaliao e mitigao dos riscos associados com o servio novo


ou alterado, particularmente em relao operao,
segurana,disponibilidade e da continuidade do servio
A capacidade empresarial e maturidade. Este atividade deve ser
realizado pela negcio -se a assegurar que toda a direita
processoes estrutura, pessoas, papels, as responsabilidades e as
instalaes esto no local para operar o novo servio
A capacidade de TI e maturidade:
O ambiente e todas as reas de tecnologia, tendo
considerado o impacto em componentes existentes de infraestrutura e servios existentes
A estrutura organizacional da TI e os papis e
responsabilidades
Os processos de TI e sua documentao
O habilidades, conhecimento e competncia do pessoal
Os processos de gerenciamento e ferramentas de apoio
O fornecedor e apoiar acordos necessrios para manter e fornecer o
servio
A montagem de um Pacote de Desenho de Servio (SDP) para a
subsequente transio, Operao e melhoria da soluo de servio novo
ou alterado.

3.6.2 Projetando sistemas de apoio, especialmente o portflio de


servios
A maneira mais eficaz de gerenciar todos os aspectos dos servios por meio de
sua ciclo de vida usando apropriada sistema de gestos e ferramentas para
apoiar e automatizar processos eficientes. O Portflio de Servios o sistema
de gesto mais crtico usado para apoiar todos os processos e descreve um
provedor do servios em termos de valor de negcio. Ele articula as
necessidades do negcio ea resposta do provedor para essas necessidades.
Por definio, termos de valor de negcios correspondem aos termos de
mercado, fornecendo um meio para comparar a competitividade servio atravs
de prestadores alternativos. Ao agir como a base de uma deciso-quadro, um
Portflio de Servios ou esclarece ou ajuda a esclarecer o seguinte estratgico
perguntas:

Por que um cliente comprar esses servios?


Por que eles deveriam comprar estes servios de voc?
Quais so os preos ou estorno modelos?
Quais so 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 Portflio de Servios devem fazer parte de um


abrangente Sistema de Gesto Servio de Conhecimento (SGCS) e registrado
como um documento no Gerenciamento da Configurao (CMS). Mais

ITIL V3 - Service Design - Pgina:

62 de 477

informaes so fornecidas em ambos o CMS e os SKMS dentro do Transio


de Servio publicao.
Figura 3.6 uma representao da relao do portflio de servios com as
SKMS.

Figura 3.6 Portfolio O Servio - um repositrio central

Uma vez que um estratgico deciso de fretar um servio feita, esta a fase
do ciclo de vida de servios ao Design de Servios comea arquitetar o servio,
que acabar por se tornar parte do Catlogo de Servios. O Portflio de
Servios devem conter informaes relativas a todos os servios e seu status
atual no organizao. As opes de estado na Carteira de servio deve incluir:

Requisitos: Um conjunto de requisitos de destaque foram recebidos do


negcio ou de TI para um servio novo ou alterado
Definido: O conjunto de requisitos para o novo servio esto sendo
avaliados, definidos e documentados e os SLR est sendo produzido
Analisados: O conjunto de requisitos para o novo servio esto sendo
analisados e priorizados
Aprovado: O conjunto de requisitos para o novo servio ter sido
finalizado e autorizado

ITIL V3 - Service Design - Pgina:

63 de 477

Fretado: Os novos requisitos de servios esto sendo comunicados e


recursos e oramentos alocado
Projetado: O novo servio e seu constituinte componentes esto sendo
projetados - e adquiridos, se necessrio
Desenvolvido: O servio e os seus componentes constituintes esto a
ser desenvolvidos ou colhida, se aplicvel
Construdo: O servio e suas componentes esto sendo construdas
Teste: O servio e os seus componentes constituintes esto sendo
testadas
Lanado: O servio e suas componentes esto sendo liberados
Operacional: O servio e suas componentes esto operacionais dentro do
viver ambiente
Aposentado: O servio e suas componentes foram retirados.

O Portflio de Servios seria, portanto, conter detalhes de todos os servios e


suas estado no que diz respeito fase de corrente dentro do ciclo de vida de
servio, tal como ilustrado na Figura 3.7.

ITIL V3 - Service Design - Pgina:

64 de 477

Figura 3.7 Portfolio O Servio e seu contedo

Clientes e usurios s seria permitido o acesso a esses servios na Portflio de


Servios que foram de um estado entre "fretado" e "funcionamento", tal como
ilustrado pela caixa na Figura 3.7, ou seja, os servios contidos dentro do
Catlogo de Servios. Estratgia de Servio e Design de Servios pessoal seria
necessrio acesso a todos registros dentro do portflio de servios, bem como
de outras reas importantes, como a Gesto da Mudana. Outros membros da
provedor de servios organizao teria acesso a um subconjunto permitido dos
registros dentro do portflio de servios. Embora o portflio de servios
projetado por Design de Servios, detida e gerida por Estratgia de Servio
dentro do processo de Gesto de Portflio de Servio. Detalhes completos sobre

ITIL V3 - Service Design - Pgina:

65 de 477

Gesto de Portflio de Servios so discutidos na publicao Estratgia de


Servio.
O Pipeline Service um subconjunto do portflio de servios em geral e contm
detalhes de todos os requisitos de negcio que ainda no se tornaram servios
liberados para o viver ambiente. Ela usada como base para a definio,
anlise, priorizao e aprovao, pelo ISG e Estratgia de Servio, de todos os
pedidos de servios novos ou modificados, para assegurar que os servios
novos e modificados so alinhados com os requisitos de negcios. Ele vai ser
principalmente usado como entrada para as atividades da Estratgia de Servio
e estgios servio de projeto do Ciclo de Vida de Servio. Ele tambm fornece
dados valiosos para as atividades do Transio de Servio fase do ciclo de vida
na determinao dos servios a serem liberados. O Servio de Gesto de
Catlogo processo deve assegurar que todos os detalhes dentro do Portflio de
Servios so precisos e up-to-date como o exigncia e seu servio novo ou
alterado migrado para o ambiente ao vivo. Este ser realizado em estreita
ligao com todas as atividades de Transio de Servio.
Vrios elementos do mesmo servio pode ter diferentes estados ao mesmo
tempo. Caso contrrio, o Portflio de Servios seria incapaz de suportar
"incremental e iterativo ' desenvolvimento. Cada organizao deve projetar
cuidadosamente seu portflio de servios, o contedo eo acesso permitido para
o contedo. O contedo deve incluir:

Nome do servio
Descrio do servio
Servio estado
Servio classificao e criticidade
Aplicaos usado
Dados e / ou esquema de dados utilizados
Processo de negcioes suportada
Os proprietrios do negcio
Negcio usurios
TI proprietrios
Garantia de servio referncias SLA nvel, e SLR
Servios de apoios
Apoiar recursos
Dependente servios
Apoio Olas, contratos e acordos
Servio custars
Taxas de servio (se aplicvel)
As receitas de servios (se aplicvel)
Servio mtricos.

O Portflio de Servios a principal fonte de informao sobre os requisitos e


servios e precisa ser cuidadosamente projetado para atender todas as

ITIL V3 - Service Design - Pgina:

66 de 477

necessidades de todos os seus usurios. O projeto do Portflio de Servios


precisa ser considerado da mesma maneira como o desenho de qualquer outra
De servios de TI para garantir que ele atende a todas essas necessidades.
Esta abordagem dever tambm ser utilizada para todas as outras Servio de
Gesto de sistemas de informao, incluindo a:

Servio do Sistema de Gesto do Conhecimento (SGCS)


Gerenciamento da Configurao (CMS)
Sistema de Service Desk
Capacidade do Sistema de Informao de Gesto (CMIS)
Disponibilidade do Sistema de Informao de Gesto (AMIS)
Gesto de Segurana Sistema de Informao (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 organizao esto
preocupados com o fornecimento global estratgico "Projetos" para o
desenvolvimento e desenvolvimento de um Infra-estrutura de TI - Um conjunto
de aplicaos e dados que atendam as necessidades atuais e futuras do
negcio. Embora estes aspectos sustentam a prestao de servios de TI de
qualidade, sozinhos no podem fornecer qualidade de servios de TI, e
essencial que as pessoas, processo e parceiro /fornecedor aspectos que cercam
estes tecnolgica componentes (produtos) so tambm consideradas.
'Arquitetura" um termo usado em vrios contextos diferentes. Neste contexto,
definida como:
A organizao fundamental de um sistema, incorporada nas suas componentes,
suas relaos um ao outro e ao meio ambiente, e com os princpios orientadores
da sua concepo e evoluo.
'Sistema' nesta definio usada em mais geral, no necessariamente de TI,
sentido:
"Uma coleo de componentes organizados para realizar uma especfica funo
ou conjunto de funes.

Assim, o sistema pode ser, por exemplo, uma organizao de todo, uma funo
de negcios, ou uma linha de produto de um sistema de informao. Cada um
destes sistemas ter uma "arquitectura", tal como definido anteriormente,
constitudo pelo componentes do sistema, as relaes entre eles (como
interfaces de controle e intercmbio de dados), as relaes entre o sistema eo
seu ambiente (polticas, organizacionais, tecnolgicos, etc) e os princpios de
design que informar, orientar e restringir a sua estrutura e operao, Bem como
o seu futuro desenvolvimento.

ITIL V3 - Service Design - Pgina:

67 de 477

Em essncia, a arquitectura pode ser definida como:


"O desenvolvimento e manuteno de polticas, estratgias, arquiteturas,
desenhos, documentos, planos e processos para a desenvolvimento e posterior
operao e melhoria da apropriadas servios de TI e solues de toda a
organizao. "
O trabalho do projeto arquitetnico 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, aplicaos e servios


externos servir as necessidades da empresa, seus produtos e servios.
Este atividade no inclui apenas os componentes de tecnologia, mas
tambm a gesto deles
O justo equilbrio entre a inovao, risco e custar ao buscar uma
vantagem competitiva, onde desejado pela empresa
H a conformidade com as estruturas arquitetnicas, estratgias,
polticas, regulamentos e normas
Uma interface fornecida coordenada entre TI desenhistas e projetistas,
designers, estrategistas de negcios e planejadores.

As atividades de projeto de arquitetura deve usar a entrada do negcio,


Estratgia de Servio, Seus planos, desenhistas e projetistas para desenvolver
projetos adequados, planos, arquiteturas e polticas para todas as reas de TI.
Estes projetos, planos, arquiteturas e polticas devem cobrir todos os aspectos
da TI, incluindo papels e responsabilidades, servios, tecnologia, arquitetura e
estruturas, processoes e procedimentos, parceiros e fornecedors mtodos e
gesto. O processo de projeto arquitetnico tambm deve cobrir todas as reas
de tecnologia, incluindo a infra-estrutura, ambiente,aplicaos e dados e estar
intimamente ligado ao do negcio em geral planejamento e projeto processos.
Qualquer empresa um sistema complexo, com muitos tipos de componentes,
incluindo a equipe, funes de negcios e processos, estrutura organizacional e
distribuio fsica, recursos de informao e sistemas de informao, financeiro
e outros recursos, incluindo tecnologia, e as estratgias, planos, gesto, polticas
e governo estruturas que dirigem a empresa. Uma arquitetura empresarial deve
mostrar como todos estes componentes (e outros) so integradas a fim de
alcanar o negcio objetivos, tanto agora como no futuro.
A Arquitetura Corporativa completa pode ser grande e complexo. Aqui estamos
interessados em pessoas arquiteturaest preocupado com o negcio da
organizao e os sistemas de informao que suportam. Cada uma dessas
arquiteturas apela arquitetnicas distintas disciplinas e reas de conhecimento,
como ilustrado na figura 3.8.

ITIL V3 - Service Design - Pgina:

68 de 477

Figura 3.8 Enterprise Architecture

Arquitetura Corporativa definido pela Gartner como:


"O processo de traduo de negcios viso e estratgia em empresa eficaz
mudar, Com a criao, a comunicao ea melhoria princpios fundamentais e
modelos que descrevem os estados futuros da empresa e permitir a sua evoluo
".

H muitos quadros de proprietrios e no-proprietrios para o desenvolvimento


de uma arquitetura empresarial, como ilustrado na Tabela 3.1.

ITIL V3 - Service Design - Pgina:

69 de 477

Nome quadro completo

Sigla
quadro

Arquitetura do Quadro Integrado de Sistemas de Informao

ARIS

Bredemeyer Quadro

Bredemeyer

Transformao de Negcios Enablement quadro Transformao


do Programa

BTEP

Comando, Controle, Comunicaes, Computadores Inteligncias


Vigilncia 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 Referncia

FEA

Generalizada Enterprise Architecture Referncia e Metodologia

GERAM

Integrated Architecture Framework

IAF

Pilares da EA

Forrester

Modelo de Referncia para Processamento Distribudo Aberto

RM-ODP

Gesto de Informao Tcnico Architectural Framework

TAFIM

Tesouro Enterprise Architecture Framework

TEAF

TOGAF Modelo de Referncia Tcnica

TOGAF

Zachman Framework

Zachman

Tabela 3.1 Arquitetura estruturas empresariais

Estes quadros incluem descries da estrutura organizacional, processo de


negcioes de planejamento e controle de sistemas, gesto e governo
mecanismos, polticas e procedimentos da empresa. Eles mostram como estes
componentes interagir e contribuir para a realizao de objetivos de negcio e
objetivos, e fornecer a base para identificar os requisitos para sistemas de
informao que suportam estes processos de negcios.
ITIL V3 - Service Design - Pgina:

70 de 477

A Arquitetura Corporativa deve ser um elemento integrante da Arquitetura de


Negcios e deve incluir as seguintes reas principais:

Arquitetura de Servio, Que se traduz aplicaos, infra-estrutura,


organizao e atividades de apoio em um conjunto de servios. O
Arquitetura de Servio prev a abordagem de negcios independente,
integrada para a prestao de servios negcio. Ele fornece o modelo
para fazer uma distino entre a arquitetura de servio, a arquitetura do
aplicativo, a Arquitetura de Dados e Infra-estrutura da Arquitetura. Ele
tambm fornece tolerncia a falhas, Preparao para o futuro e
segurana controlos. Isto significa que, potencialmente, quaisquer
alteraes que ocorram na arquiteturas de tecnologia ser transparente
para a usurios da servio - Por exemplo, web-based de entrega
mecanismos de auto-servio. Ela deve incluir no apenas os prprios
servios e sua integrao global, mas tambm a gesto desses servios.
Arquitetura da Aplicao, Que fornece um modelo para a
desenvolvimento e desenvolvimento de aplicativos individuais, mapas de
negcio e requisitos funcionais para aplicaes, e mostra as interrelaes entre as aplicaes. Arquiteturas de aplicao emergentes so
susceptveis de ser baseado em componentes. Essa abordagem
maximiza a reutilizao e ajuda a manter a flexibilidade em mudanas
acomodando em terceirizao poltica.
Dados / Arquitetura de Informao, Que descreve os ativos fsicos e
lgicos de dados da empresa e do gerenciamento de dados recursos. Ele
mostra como os recursos de informao so geridos e compartilhada para
o benefcio da empresa. A estratgia em dados centralizada versus
distribuda quase certamente foram concebidas como parte de uma tal
arquitetura. Os dados / Arquitetura da Informao devero ter em conta
as tecnologias de armazenamento de dados que facilitam a explorao
dos bens de informaes corporativas. cada vez mais cobrir
gerenciamento de contedo e as instalaes para a entrega de
informaes atravs de mltiplos canais.
Arquitetura de TI Infra-estrutura, Que descreve a distribuio de
funcionalidade, estrutura e geogrfica do hardware, software e
componentes de comunicao que servem de base e apoiar a
arquitectura global, bem como as normas tcnicas aplicveis a eles. Esta
tambm deve incluir uma "Arquitetura de Produto" que descreva os
produtos proprietrios particulares e padres da indstria que a empresa
usa para implementar a infra-estrutura em conformidade com os
princpios da arquitetura de TI Infra-estrutura
Arquitetura Ambiental, Que descreve todos os aspectos, tipos e nveis
de ambiente controlars e sua gesto. Uma ilustrao do tipo de
informao sobre o ambiente necessrio est includo no Apndice E.

O relaos entre essas perspectivas arquitectnicos podem ser vistos na Figura


3.9. As arquiteturas de documentao, desenvolvimento e manuteno de

ITIL V3 - Service Design - Pgina:

71 de 477

negcios e de TI, normalmente fazem parte da processoes de estratgico


pensar e estratgia no desenvolvimento organizao.

Figura 3.9 relaes de arquitectura

Dentro da estrutura descrita anteriormente, possvel identificar (pelo menos)


trs arquitectnico papels. Estes poderiam relatar a um idoso "Enterprise
Architect" na organizao:

Negcios / Arquiteto Organizacional: Preocupao com os negcios


modelos, processo de negcioes e organizacional projeto - Estrutural e
funcional componentes da organizao e sua relao, e como o negcio
funes e atividades da organizao so distribudas entre eles, tambm
a governao da organizao e os papis e responsabilidades
necessrias
Arquiteto servio (Muitas vezes papis distintos de Aplicaes Arquiteto
e Informao / Data Architect): preocupados com o Servio, dados e

ITIL V3 - Service Design - Pgina:

72 de 477

arquiteturas de aplicativos - a lgicas arquiteturas apoiar o negcio e as


relaes entre eles
Arquiteto de TI Infra-estrutura: Preocupado com o modelo de tecnologia
fsica, os componentes de infra-estrutura e suas relaes, incluindo
escolhas de tecnologias, interfaces e protocolos, ea seleo de produtos
para implementar a infra-estrutura.

Em algumas organizaes, o papels de Negcios / Arquiteto Organizacional,


Arquiteto de Sistemas de Informao (ou papis possivelmente separados de
Aplicaes Arquiteto e Arquiteto de Dados) e Arquiteto de TI Infra-estrutura ser
funes distintas. Em outras, algumas ou todas as funes podem ser
combinadas. Os papis podem residir em partes separadas da organizao ou
mesmo fora dela. Por exemplo:

O papel Business Architect / organizacional pode residir no negcio


Estratgia e Planejamento funo na sede corporativa
O papel do arquiteto servio podem fazer parte de uma funo interna
com a responsabilidade de lidar com as relaes entre a empresa,
externa fornecedors de TI e parceiros relacionados com questes de
servio. Uma das principais responsabilidades de tal funo a
manuteno da Arquitetura de Servio. Esta funo pode ser dentro de
uma funo de TI ou no lado do negcio de uma organizao
O papel do arquiteto de TI Infra-estrutura pode residir com o provedor de
servios/ Parceiro que responsvel pela produo da Arquitetura de
Infra-estrutura de TI utilizado para a entrega de De servios de TIs para a
organizao.

Se o necessrio arquiteturas esto no lugar, em seguida, o papel de Design de


Servios afetado das seguintes formas:

Deve trabalhar dentro do quadro acordado arquitetura e padres


Ser capaz de voltar a usar muitos dos bens criados como parte da
arquitetura
Devem trabalhar em estreita colaborao com todas as trs funes de
arquitetura para garantir o mximo proveito do trabalho feito na criao da
arquitetura.

Se o projeto de arquitetura deve ser realizado de forma eficaz e


economicamente, os documentos, processos e atividades da empresa e projeto
arquitetnico deve ser estreitamente coordenada e sincronizada. A lista dos
documentos de projeto e seu contedo est contido nos Apndices C e D. Os
detalhes individuais de tecnologia includos no projeto arquitetnico so
considerados nas sees seguintes.

ITIL V3 - Service Design - Pgina:

73 de 477

O real benefcio e ROI do Enterprise Architecture no vem da prpria


arquitetura, mas a partir da capacidade de uma organizao para projetar e
implementar projetos e as solues de uma maneira rpida e consistente.
3.6.3.1 Gesto de Tecnologia

Aestratgico abordagem deve ser adotada com relao ao planejamento de um


tecnologia da informao e sua gesto. Isto implica a criao de "arquiteturas"
ou "esquemas" para o quadro a longo prazo da tecnologia utilizada e planejada.
TI planejadores, projetistas e arquitetos precisam entender o negcio, os
requisitos e da tecnologia atual, a fim de desenvolver TI apropriada arquiteturas
para o curto, mdio e longo prazo. Design de tecnologia tambm precisa levar
em conta os provveis servios de TI que iro apoiar, ou pelo menos os tipos de
servio a partir de um entendimento do negcio e sua orientao futura, porque
o negcio vai exigir servios de TI, e eles vo precisar de uma tecnologia
adequada para oferecer e prestar esses servios. Se possvel para fornecer
uma tecnologia de longo prazo, que podem apoiar uma srie de servios de TI,
em seguida, tendo uma abordagem estratgica proporcionar benefcios a longo
prazo.
Arquiteturas precisam ser desenvolvidos dentro das grandes reas de
tecnologia.
Arquiteturas de tecnologia
Arquiteturas so necessrios em todas as reas de Infra-estrutura de TI. Sempre
que pertinente, devem ser desenvolvidas nas seguintes reas:

Aplicaes e sistemas de software


Informaes, dados e base de dados, incluindo informaes segurana e
confidencialidade, Minerao de dados e armazenamento de dados
Projeto de infra-estrutura e arquitetura:
Central servidor, Arquiteturas de mainframe, distribudos servidores
regionais, incluindo arquivos local e servidores de impresso
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 acesso
mvel (dispositivos portteis, telefones celulares, palmtops, PDAs,
scanners, etc)
Dispositivos de armazenamento, redes de rea de armazenamento
(SANs), Network Attached Storage (NAS), incluindo apoio e
recuperao sistemas e servios (servidores, robs, etc)
Armazenamento de documentos, manuseio e gesto

ITIL V3 - Service Design - Pgina:

74 de 477

reas especializadas de tecnologia, tais como EPOS, caixas


eletrnicos, dispositivos de digitalizao, sistemas de GPS, etc
Sistemas ambientais e equipamentos, incluindo a sua monitoramento e
gesto.

Isto ir resultar numa hierarquia de arquiteturas, o que ter de ser articulados


para a construo de um conjunto integrado de arquiteturas de tecnologia para o
organizao. A Arquitetura de Infra-estrutura dever ter como objectivo fornecer
relativamente poucas plataformas padronizadas para hospedagem aplicaos.
Tambm deve estabelecer normas para arquiteturas de aplicaes que esto a
ser hospedado em centros de dados controlados de modo que estes se
encaixam no padro de funcionamento, monitoramento e segurana requisitos
Arquitecturas de gesto
TI deve gerir custars, entregar os servios certos no momento certo, os ativos de
informaes seguras, fornecer um servio confivel e levar o negcio para
alavancar tecnologias. Isto requer automatizado procedimentos e ferramentas de
gesto, a fim de alcanar este objectivo de forma eficaz e eficiente. A seleo de
uma arquitetura de gesto adequado fundamental para estabelecer o nvel de
controlar e automao. Existem duas abordagens distintas para o
desenvolvimento de uma arquitetura de gerenciamento:

Seleo de uma arquitetura de gerenciamento de propriedade: Esta


baseia-se na seleco de um conjunto nico de produtos e ferramentas
de gesto de uma nica administrao de solues proprietrias
fornecedor. Esta abordagem ir normalmente exigem menos esforo, 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 gesto e de instalaes, o que pode resultar em falhas.
Selecionando 'melhor da raa "uma arquitetura: Esta abordagem
envolve a seleo de um conjunto de "Melhor da Raa" ferramentas de
gesto e produtos a partir de um nmero de fornecedores de solues de
gesto e integr-los para fornecer uma soluo abrangente de
gerenciamento. Isso geralmente requerem mais esforo na integrao
das ferramentas em uma soluo nica de gesto abrangente, mas,
muitas vezes, oferecem maior funcionalidade de gesto e instalaes que
levam a poupana de longo prazo de custos.

Os desafios para a gesto de TI so coordenar e trabalhar em parceria com a


negcio na construo destas solues de gesto, suportando a adequada
processoes e proporcionando as medies necessrias e mtricos. Isso tem que
ser alcanado 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 no desnecessariamente

ITIL V3 - Service Design - Pgina:

75 de 477

comprou (com seus custos associados em curso), ou projetar um apoioSoluo /


recuperao que no requer um conjunto completo de infra-estrutura adicional.
Custos considerveis pode ser salvo por inteligente e cuidadosa projeto,
Utilizando a tecnologia que suportvel e causa poucos problemas no
operacional ambiente.
O principal mtodo de alcanar essas metas criar solues que do a uma
reduo na gesto global da rede e os custos de suporte, mantendo ou
melhorando a qualidade do servio prestado para a empresa.
Para obter os maiores benefcios da utilizao do Quatro Ps, organizaos deve
determinar os papis 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 princpios. Esta arquitetura deve facilitar a
implementao de um conjunto de ferramentas integradas de gesto e
processos que suporte "fim-a-fim" de todas as reas da tecnologia utilizada,
garantindo que no existem lacunas e no "silos tcnicas".
No entanto, ele enfrenta um grande desafio no desenvolvimento e manuteno
das habilidades sociais necessrias para executar essas funes e processos
de gesto eficaz. Nas organizaes verdadeiramente eficazes, estas funes e
processos esto alinhados com os da empresa. Isso garante que os processos
de negcios e de gesto de TI e informaes tm metas e objectivos
semelhantes. No entanto, muitas vezes, as organizaes dedicar tempo e
esforo insuficiente para o desenvolvimento das habilidades sociais (por
exemplo, habilidades interpessoais, habilidades de comunicao, habilidades de
reunies) necessrias para a processoes eo alinhamento do negcio a ser
efetivamente alcanado.
Existem cinco reas que tm de ser considerados em relao projeto de uma
arquitectura de gesto, tal como ilustrado na Figura 3.10.

ITIL V3 - Service Design - Pgina:

76 de 477

Figura 3,10 tecnologia de gerenciamento integrado voltado aos negcios

O relaos entre essas perspectivas de arquitetura pode ser visto no diagrama


acima. As arquiteturas de documentao, desenvolvimento e manuteno de
negcios e de TI, normalmente fazem parte dos processos de estratgico pensar
e estratgia desenvolvimento na organizao.
Estas cinco reas de gesto a serem considerados pode ser rapidamente
definida como:

Negcio: As necessidades, requisitos, processos, objetivos e metas do


unidade de negcioss e gestores dentro da organizao
Pessoas: O escopo, Tarefas e atividades dos gestores e funcionrios
envolvidos na gesto da prestao de De servios de TIs
Processos: Os processos e procedimentos usados para gerenciar
servios de TI para o negcio e seu clientes
Ferramentas: As ferramentas de gerenciamento e suporte necessrios
para gerir eficazmente o Infra-estrutura de TI
Tecnologia: Os produtos de TI e de tecnologia usada para entregar o
servio e informaes para a pessoa certa, no lugar certo, na hora certa.

Tal arquitetura pode ser usado para projetar e implementar solues de gesto
eficiente, eficaz e integrada, que esto alinhados com os requisitos de negcio
da organizao e seus gerentes de negcios. Esta arquitetura de gesto pode
ser aplicada dentro de uma organizao:

ITIL V3 - Service Design - Pgina:

77 de 477

Projeto de cima para baixo, Assegurando que o Servio de Gesto de e


processos de tecnologia de gesto, ferramentas e informaes esto
alinhados com as necessidades e objetivos de negcio
Implementar de baixo para cima, Garantindo que o Gerenciamento de
Servio eficiente e eficaz e processos de gesto de tecnologia so
totalmente integradas com as ferramentas e tecnologias em uso dentro do
organizao
Integrar os processos e ferramentas, Garantindo uma maior explorao
de ferramentas na gesto e suporte de tecnologia e de ponta a pontaprocessos.

Estes pontos so tambm ilustrados na Figura 3.10.


A chave para o desenvolvimento de uma arquitetura de gesto garantir que ele
impulsionado por necessidades do negcio e no desenvolvido para as
necessidades de TI de forma isolada:
Arquitecturas de gesto devem ser:
'... negcios alinhados no, tecnologia orientada ".

Dentro desta estrutura geral, uma arquitetura de gerenciamento necessrio


que possa ser aplicada a todas as reas de Gesto de TI e no apenas
individuais reas isoladas. Isto pode ento ser executado de uma coordenada
programa de inter-funcionamento, para fornecer gerenciamento de empresa
global de ponta a ponta, to essencial para a gesto eficaz da infra-estrutura de
TI atual. Se apenas as reas individuais comprar a arquitetura, Ento individuais
"ilhas de excelncia" vai desenvolver e que ser impossvel fornecer os
completas end-to-end de solues necessrias para suportar hoje solues ebusiness.
Bem como assegurar que todas as reas de TI so integrados, vital que a
arquitetura de gesto desenvolvido a partir da perspectiva de negcios e de
servios ('top down', por exemplo). Portanto, os elementos-chave para acordar e
definir antes de desenvolver a arquitetura de gerenciamento so:

Gesto do processo de negcioes: Quais so os processos de negcios e


como eles se relacionam com a rede e servios de TI e componentes?
Gesto de servio qualidade: O que qualidade de servio? Como e
onde que vai ser medido?

Estes so os elementos-chave que precisam ser determinadas pela SLM e


Gesto de TI. Eles dar um contributo crucial para o desenvolvimento de
arquiteturas de negcios com foco de gesto. Muitas vezes as ferramentas de
gesto e processoes tm sido focados na gesto de componentes e
componentes, em vez de servios e processos de negcios. Isso precisa ser

ITIL V3 - Service Design - Pgina:

78 de 477

mudado, com nfase claramente no projeto de sistema de gestos, processos e


ferramentas que so movidos pelas necessidades do negcio e estamos
focados em gesto de processos de negcios e servios de TI. Se a arquitetura
de gesto adequado projetado e implementado, isso vai permitir Servio de
Gesto de processos para concentrar-se na gesto de servios e servio
qualidade e operar de ponta-a-ponta em toda a empresa de TI inteira,
fornecendo Empresa verdade Servio de Gesto de. Isso vai realmente facilitar
a gesto de servios para garantir que os servios e qualidade de servio esto
estreitamente alinhados com as necessidades do negcio.
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 negcio e Gesto de TI. Estes novos sistemas e
processos j esto comeando a evoluir como as normas de gesto para o
intercmbio de gesto da informao entre as ferramentas se tornam mais
totalmente definido, por organizaes como o Distributed Management Task
Force (DMTF). Em essncia, os sistemas de gesto ser:

Mais focada nas necessidades das empresas


Mais alinhada com a processo de negcioes
Menos dependente de tecnologia especfica e mais "centrada em
servios"
Mais integrado com outras ferramentas de gesto e processos, as normas
de gesto evoluir. Isso vai envolver a integrao de sistemas de gesto,
operacional gesto e Servio de Gesto de ferramentas e processos, com
'silos de tecnologia' e 'menos ilhas de excelncia "
Parte de sistemas end-to-end e processos de gesto, mais focado na
prestao de servios de qualidade e atendimento ao cliente
Mais flexvel. Haver um afastamento de alguns dos mais rgida, nica
fornecedor enquadramentos para uma abordagem mais aberta 'best-ofbreed ".

3.6.4 processos Projetando


Esta seo fornece uma introduo geral ao processar teoria e prtica, Que a
base para o projeto de ITIL os processos que so utilizados no Servio Ciclo de
Vida. Um processo de modelo possibilita a compreenso e ajuda a articular as
caractersticas distintivas de um processo.
Um processo um conjunto estruturado de atividades destinadas a realizar uma
especfica objetivo. Um processo leva uma ou mais entradas e as transforma em
sadas definidas. Um processo inclui todas as papels, responsabilidades,
ferramentas e gesto controlars obrigado a entregar de forma confivel as
sadas. Um processo tambm pode definir ou revisar polticas, normas, diretrizs,
atividades, processos, procedimentos e instruo de trabalhos se eles so
necessrios.

ITIL V3 - Service Design - Pgina:

79 de 477

Controle de processo pode ser definida como:


O atividade de planejamento e regulao 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 controlvel. Graus de controlo sobre
os processos podem ser definidos, e em seguida de medio do processo e
mtricos podem ser construdos em que o processo para controlar e melhorar o
processo, tal como ilustrado na Figura 3.11.

Figura 3.11 Os elementos genricos do processo

Os elementos genricos do processo mostram dados entram no processo,


processado, emitido e o resultado medido e analisado. Esta descrio muito
bsica subjacente a qualquer descrio 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 medies
de processos (mtricas), relatrios e melhoria de processos.
Cada processo deve ser de propriedade de um proprietrio do processo, Quem
deve ser responsvel para o processo e seu aperfeioamento e para assegurar
que um processo cumpre os seus objectivos. Os objectivos de qualquer
processo de TI devem ser definidos em termos mensurveis e devem ser
expressas em termos de benefcios para os negcios e os negcios que
sustenta estratgia e objetivos. Design de Servios devem ajudar cada processo
com o proprietrio projeto de processos, a fim de assegurar que todos os

ITIL V3 - Service Design - Pgina:

80 de 477

processos utilizam termos padro e modelos, so consistentes e integrar com o


outro para fornecer end-to-end integrao de todas as zonas.
A sada produzida por um processo tem de obedecer a normas operacionais que
so 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 administrados). Se as atividades so realizadas
com um uso mnimo de recursos, o processo pode tambm ser considerada
eficaz. Processo de anlise, resultados e mtricas devem ser incorporadas nos
relatrios regulares de gesto e melhorias de processo.
Todas estas reas devem ser includas no projeto de qualquer processo. Estas
novas publicaes ITIL ter sido escrito em torno de "conjuntos de processos"
que refletem as etapas do ciclo de vida de um servio. O Design de Servios
conjunto de processos detalhados nesta publicao abrange os processos,
principalmente com relao a todos os aspectos do projeto.
Trabalhar com processos definidos tem sido a base do ITIL desde o seu incio.
Ao definir o que o organizao'S so actividades que so necessrias entradas
e sadas que ir resultar do processo, possvel trabalhar de modo mais
eficiente e eficaz. Medio e direco das actividades aumenta este eficcia.
Finalmente, atravs da adio de normas para o processo, possvel adicionar
qualidade medidas para a sada.
Esta abordagem sustenta a Plan-Do-Check-Act ciclo de melhoria contnua para
qualquer sistema de gesto da qualidade. Planear a finalidade do processo de
tal modo que as aces do processo podem ser analisados, avaliados ou
controladas para realizar com sucesso e melhorado.
Normas definir certas condies que os resultados devem atender. Normas
definindo introduz aspectos de qualidade para o processo. Mesmo antes de
comear, importante pensar sobre o que os resultados dos processos deve ser
parecida. Para descobrir se ou no as atividades do processo esto contribuindo
de forma otimizada para o objetivo de negcio e da objetivos do processo,
alinhada aos objetivos de negcio, a eficcia deve ser medida em uma base
regular. Medio permite a comparao do que tem sido feito com o que a
organizao se props a fazer, e para identificar e implementar melhorias no
processo.
Cada organizao deve adotar uma abordagem formal para a concepo e
implementao de Servio de Gesto de processos. O objetivo no deve ser o
de "processos perfeitos" de design, mas para projetar processos prticos e
adequados com os mecanismos de "embutido" de melhoria, de modo que a
eficcia ea eficincia dos processos so melhoradas de forma mais adequado
para o organismo. Documentao normas, processos e modelos deve ser usado
para assegurar que os processos so facilmente adoptada em toda a

ITIL V3 - Service Design - Pgina:

81 de 477

organizao. Alguns exemplos de modelos de documentao do processo esto


includas no Apndice C.
A meta para agora e no futuro, a concepo de processos e apoiar essas
ferramentas que podem proporcionar a integrao entre as organizaes. Isso
agora se tornou possvel porque as ferramentas de gesto esto a prestar apoio
de padres abertos, como o Distributed Management Task Force (DMTF), que
suportam a troca de informaes com base em ITIL conceitos, como incidentes,
problemas e mudars com formatos padro e contedos. Isto permite que
provedor de servioss para suportar interfaces de processos eficientes e
eficazes com a sua principal fornecedors com cmbio automatizado de chave
operacional informao em tempo real.

3.6.5 Projeto de sistemas de medio e mtricas


"Se voc no pode medir-lo, ento voc no pode control-lo."

A fim de gerenciar e controlar os processos de design, eles tm que ser


monitorado e medido. Isto verdade para todos os aspectos dos processos de
desenho. Medidas e mtricos so abordados em detalhes na publicao
Melhoria de Servio Continuada. Esta seo aborda os aspectos que so
particularmente relevantes e apropriadas para medir a qualidade dos processos
de projeto e sua entregas.
Deve haver cuidado ao selecionar as medies e as mtricas e os mtodos
utilizados para produzi-los. Isto porque as mtricas e medies escolhidos vo
realmente afetar e mudar o comportamento das pessoas que trabalham no
mbito das actividades e processos que esto sendo medidas, nomeadamente
quando se refere a objetivos, pessoal e da equipe atuao e esquemas
relacionados com o desempenho de pagamento. Portanto, somente medidas
que incentivem a progresso no sentido de cumprir objetivo de negcios ou
desejada mudana de comportamento devem ser selecionados.
Em todas as atividades do projeto a exigncia deveria ser:

Solues de design que so 'apto para o efeito'


Design para o nvel adequado de qualidade - No mais de engenharia ou
em engenharia
Solues de design que so " primeira" e cumprir os seus objectivos
esperados
Solues de design que minimizam a quantidade de "retrabalho" ou "addons" que tm de ser rapidamente desenvolvido aps solues foram
implantadas
Solues de design que so eficazes e eficientes do ponto de vista da
negcio e a clientes. A nfase deve ser sobre as solues que so
eficazes acima de tudo e que so eficientes dentro do constrangimento de
permanecer eficaz.

ITIL V3 - Service Design - Pgina:

82 de 477

Mtodos de medio e mtricas devem refletir esses requisitos e ser projetado


para medir a capacidade de processos de design para combinar com esses
requisitos. Todas as medies e mtricos usado deve reflectir a qualidade eo
sucesso do projeto processoes a partir da perspectiva dos negcios, clientes e
usurios. Eles precisam refletir a capacidade das solues entregues para
atender as necessidades identificadas e acordadas do negcio.
As medies de processos seleccionados devem ser apropriados para o
capacidade e maturidade dos processos a ser medido. Processos imaturos no
so capazes de suportar medies sofisticadas, mtricas e mtodos de
medio. Existem quatro tipos de mtricas que podem ser utilizados para medir
a capacidade e o desempenho dos processos de:

Progresso: Marcos e entregas na capacidade do processo


Observncia: O cumprimento do processo de governo requisitos,
requisitos regulamentares e de conformidade de pessoas para a
utilizao do processo.
Eficcia: A exatido e correo do processo e sua capacidade de
entregar o "resultado certo '
Eficincia: A produtividade do processo, a sua velocidade, rendimento e
recurso utilizao.

Medidas e mtricas devem desenvolver e mudar como a maturidade ea


capacidade de um processo se desenvolve. Inicialmente, com os processos de
imaturos os primeiros dois nveis de mtricas 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 eficcia e eficincia mtricas, mas no em detrimento de comprometer o
progresso ou a conformidade do processo.
A seleo das mtricas, o ponto de medio e os mtodos de medio, clculo e
elaborao de relatrios sobre as mtricas devem ser cuidadosamente
concebido e planejado. As principais mtricas deve sempre se concentrar em
determinar a eficcia ea qualidade das solues fornecidas. Mtricas
secundrias podem ento medir a eficincia dos processos utilizados para
produzir e administrar a soluo. A prioridade deve ser sempre a de garantir que
os processos de fornecer os resultados corretos para o negcio. Portanto, os
mtodos de medio e mtricas deve sempre fornecer esta medida com foco em
negcios acima de tudo.
O mtodo mais eficaz de medida estabelecer uma "rvore Metrics" ou "rvore
de KPI". Muitos organizaos coletar medio em reas individuais, mas no
para agreg-los juntos e ganhar o benefcio total das medies, e, portanto,
sofrem porque:

Medidas no esto alinhados com objetivo de negcios e necessidades

ITIL V3 - Service Design - Pgina:

83 de 477

No h visibilidade global da imagem do 'nvel superior'


H lacunas em reas onde as medies no so registradas
reas individuais so bem medido e os outros so pouco ou no so
medidos medidos
No h coerncia no mtodo de apresentao e clculo das medies
Decises e aes de melhoria so baseadas em informaes incompletas
ou incorretas.

Por isso as organizaes devem tentar desenvolver sistemas automticos de


medio baseado em uma forma de "Mtricas rvore ', como a ilustrada na
Figura 3.12.

Figura 3.12 A rvore Mtricas

A rvore na Figura 3.12 ilustrativa de um exemplo de uma rvore de mtricas


com base em uma tpica Balanced Scorecard. Balanced Scorecards
representam uma sistema de gesto que permite que um nmero crescente de
organizaes para clarificar a sua viso e estratgia em ao. Eles fornecem
feedback em relao ao interno processo de negcioes e externa resultados, a
fim de melhorar continuamente estratgico atuao e resultados. Isso permite
que todos dentro da organizao para obter uma imagem do desempenho da
organizao ao nvel adequado:

Gerentes de negcios e clientes pode obter um 'alto nvel' negcio 'painel


de instrumentos', Alinhados com as necessidades de negcio e processos
Seniores de TI, gestores e clientes podem se concentrar no painel de
gerenciamento de nvel superior de TI

ITIL V3 - Service Design - Pgina:

84 de 477

Service Managers e os clientes podem concentrar-se na execuo de


servios particulares
Proprietrio do processos e os gerentes podem ver o desempenho de sua
processoes
Especialistas tcnicos pode olhar para o desempenho individual
componentes
O painel de instrumentos apresenta tambm uma oportunidade de ver as
tendncias ao longo do tempo, ao invs de dados estticos, de modo que
a degradao do desempenho potencial pode ser identificado e corrigido
em um estgio inicial.

Isto significa que, dentro de um sistema hierrquico de mtricas, cada pessoa no


organizao pode ter acesso a um nvel adequado de informao e de medio
que se adapte s suas necessidades em particular. Ele d a gerncia snior a
oportunidade de acompanhar um painel de alto nvel para garantir que servios
continuam a ser entregues aos seus nveis acordados, e tambm fornece o
capacidade para especialistas tcnicos e proprietrios de processos para
perfurar at ao detalhe para analisar variao de servio acordado, componente
ou um processo de desempenho.
Obviamente, a coleta, anlise e apresentao de dados pode ser uma atividade
muito trabalhoso e, portanto, deve ser automatizado, sempre que possvel. Isto
pode ser conseguido utilizando ferramentas de anlise baseadas em macros,
scripts, folhas de clculo ou, preferencialmente, em especfico solues
baseadas na web. As medies em cada um dos nveis devem ser definidos
especificamente para atender as necessidades do negcio, Clientes e usurios
da informao.
Informaes mais detalhadas sobre as medidas, mtricas e mtodos de medio
esto contidas na publicao Melhoria de Servio Continuada.

ITIL V3 - Service Design - Pgina:

85 de 477

3.7 As seguintes atividades de design


Uma vez que a soluo de servio desejado foi concebido, em seguida, as
atividades subseqentes tambm deve ser preenchida com o Design de
Servios fase antes que a soluo passa para o Transio de Servio fase.

3.7.1 Avaliao de solues alternativas


Um adicional avaliao fase pode ser necessrio se externo fornecedor servios
e solues esto envolvidos. Este consiste no seguinte:

A seleo de um conjunto de fornecedores e completar um processo de


concurso. Isto requerer a produo e a concluso de:
Documentao da escopo do servio e produo de uma
Declarao de Necessidade (SOR) e / ou um Termos de referncia
(TR) documento
Request For Information (RFI), solicitao de proposta (RFP),
solicitao de cotao (RFQ) e concurso (ITT) documentos
Produo e adoptando um conjunto de soluo e fornecedor
critrios de avaliao e uma pontuao processo.
Avaliao e rever de respostas de fornecedores e seleo do preferido
fornecedor(S) e sua soluo proposta (s). Isso tambm pode envolver a
execuo de ensaios ou at mesmo prottipos ou prova de conceito se
atividades significativas novos conceitos ou de tecnologia esto
envolvidas no novo servio, a fim de garantir que os componentes novos
satisfazer as suas expectativas.
Avaliao e custeio dos projetos alternativos, possivelmente incluindo a
identificao de potenciais fornecedores e avaliao de suas propostas
alternativas, tecnologias, solues e contratos. Existe uma necessidade
de garantir que cobre custando one-off custars e custos correntes de
operao e propriedade, incluindo suporte e manuteno.

3.7.2 Aquisio de a soluo preferida


possvel que os elementos externos no ser necessrio para a soluo. No
entanto, isso incomum como fornecedores de software, pelo menos so
altamente propensos a se envolver. Quando os fornecedores externos esto
envolvidos na soluo preferida, as etapas consistem em:

Completando todas as verificaes necessrias sobre o preferido


fornecedor
Finalizar os termos e condies de quaisquer novos contratos, garantindo
que todas as polticas corporativas so aplicadas
A aquisio da soluo selecionada.

ITIL V3 - Service Design - Pgina:

86 de 477

3.7.3 Desenvolver a soluo de servio


O desenvolvimento etapa consiste em traduzir a Design de Servios num plano
para o desenvolvimento, reutilizao ou renovao do componentes obrigado a
entregar o servio e posterior execuo do servio desenvolvido. Ele pode
necessitar de ser convertida numa programa de planos, se trata de um servio
principal mudar. Cada plano ou projeto dentro do programa ser responsvel
pela entrega de um ou mais componentes do servio e incluem:

As necessidades do negcio
O estratgia para ser adoptada para a aquisio e desenvolvimento ou da
soluo de
Os prazos envolvidos
O recursos necessrio, levando-se em considerao instalaes, Infraestrutura de TI e as habilidades certas de pessoal a fim de garantir a
entrega servio atende s necessidades do cliente
O desenvolvimento do servio e dos seus componentes constituintes,
incluindo a administrao e de outros operacional mecanismos, tais como
a medio, monitoramento e elaborao de relatrios
Servio e planos de teste de componentes.

Gesto do projecto cuidadoso ter de ser usado para assegurar que o conflito
evitado e que os componentes compatveis so desenvolvidos a partir das vrias
actividades de desenvolvimento diferentes

ITIL V3 - Service Design - Pgina:

87 de 477

3,8 restries de design


Todas as atividades de design operar dentro de muitas restries. Estas
restries vm do negcio e Estratgia de Servio e cobrir muitas reas
diferentes, como ilustrado na Figura 3.13.

Figura 3.13 As restries de design impulsionado pela estratgia

Isto significa que os designers nem sempre so "livres" para criar a soluo mais
adequada para o negcio, Uma vez que no cai dentro das restries impostas,
conforme ilustrado na Figura 3.13. A limitao mais bvia o financeiro. Pode
haver insuficiente oramento disponvel para a soluo mais adequada,
portanto, uma alternativa mais barata servio teria que ser identificadas e
acordadas com o negcio. O designer s pode fornecer a soluo que se
encaixa dentro de todas as limitaes atualmente conhecidos, ou ento tentar
levantar ou renegociao de alguns dos constrangimentos - por exemplo,
atravs da obteno de um oramento maior. Na Figura 3.13, no s ser mais
do oramento devem ser obtidas para implementar a soluo desejada, mas
tambm por no-conformidade com algumas das normas e regulamentos
pertinentes. Portanto, neste caso uma alternativa, a soluo mais barata
compatvel seria provavelmente necessrio.
Assim, o Design de Servios processos deve reconhecer o fato de que eles
esto livres para solues de design, mas eles esto trabalhando em um
ambiente onde muitos fatores externos podem influenciar o projeto.

ITIL V3 - Service Design - Pgina:

88 de 477

Clique na imagem acima para ver uma verso maior em uma nova janela do
navegador

Muitas dessas influncias externas so da necessidade de corporativa e de TI


governo, E os outros so a partir do requisito de acordo com os regulamentos,
legislao 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 solues que eles produzem tem todo o necessrio controlars e
capacidade dentro deles.

ITIL V3 - Service Design - Pgina:

89 de 477

3,9 Arquitetura Orientada a Servios


Processo de negcio e as solues devem ser concebidos e desenvolvidos
utilizando uma Arquitetura Orientada a Servios abordagem (SOA). A
abordagem SOA considerado melhores prticas e usado por muitas
organizaes para melhorar a sua eficcia e eficincia na prestao de De
servios de TIs.
SOA definido pela OASIS (www.oasis-open.org) como:
'Um paradigma para organizar e utilizando as capacidades distribudas que
podem estar sob o controle de diferentes domnios proprietrios. Ele fornece um
mtodo uniforme para oferecer, descobrir, interagir e usar os recursos para
produzir efeitos desejados consistentes com condies mensurveis e
expectativas. "
OASIS (Organizao para o Avano de Padres de Informao Estruturada)
um sem fins lucrativos consrcio internacional, que impulsiona o
desenvolvimento, Convergncia e adoo de padres de e-business. SOA traz
valor e agilidade a um organizao incentivando o desenvolvimento de "autosuficientes" servios que so reutilizveis. Isto, por sua vez, promove uma
abordagem modular e flexvel para o desenvolvimento de "servios partilhados"
que podem ser usados em muitas reas diferentes do negcio. Mais e mais
organizaes esto a converter os processos de negcio de "pacotes de
servios" comuns que podem ser usados e compartilhados por muitas reas do
negcio.
Sempre que possvel, Provedor de servios de TI organizaes devem usar o
SOA e princpios para desenvolver flexveis, reutilizveis de servios de TI que
so comuns e podem ser compartilhadas e exploradas por diversas reas do
negcio. Quando este mtodo usado, essencial que a TI:

Define e determina o que um servio


Entende e identifica claramente as interfaces e dependncias entre os servios
Utiliza padres para o desenvolvimento e definio de servios
Utiliza tecnologia comum e conjunto de ferramentas
Investiga e compreende o impacto de mudars de "servios 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 implementao e suporte dos
servios novos ou alterados.

Quando os princpios de SOA so utilizadas pela organizao de TI do prestador


de servios, fundamental que um preciso Catlogo de Servios mantido
como parte de uma estratgia global Portflio de Servios e Sistema de
Gerenciamento da Configurao (CMS). Adotando essa abordagem pode
reduzir significativamente o tempo necessrio para fornecer novas solues para
o negcio e avanar para um Business Service Management (BSM) capacidade.

ITIL V3 - Service Design - Pgina:

90 de 477

O Catlogo de Servios tambm ir mostrar o relao entre servios e


aplicaos. Uma nica aplicao pode ser parte de mais de um servio, e um
nico servio poderia utilizar mais de um aplicativo.

ITIL V3 - Service Design - Pgina:

91 de 477

3,10 Business Service Management


Business Service Management (BSM) um estratgia e uma abordagem para
permitir TI componentes para ser ligada aos objetivos do negcio. Desta forma,
o impacto da tecnologia sobre os negcios e como a mudana negcio pode
impactar tanto a tecnologia pode ser previsto. A criao de um Catlogo de
Servio totalmente integrada - incluindo unidade de negcioss, processos e
servios, e suas relaes e dependncias de De servios de TIA tecnologia e os
componentes - crucial para aumentar a capacidade do provedor de servios de
TI para entregar BSM. Todos os aspectos da Design de Servios so elementos
vitais para apoiar e aprimorar os negcios Servio de Gesto de capacidade do
Provedor de servios de TI, Particularmente o projeto do portflio de servios, o
Catlogo de Servios e as individuais de servios de TI. Todas essas atividades
tambm ir melhorar o alinhamento da TI com os negcios de prestao de
servios e de suas necessidades em evoluo. Veja a Figura 3.15.
BSM permite que uma organizao de TI provedor de servio para:

Alinhar a TI com os objetivos de prestao de servios de negcios e


objetivos
Priorizar todas as atividades de TI no impacto nos negcios e urgncia,
Assegurando crtico processo de negcioes e servios recebem mais
ateno
Aumentar a produtividade ea lucratividade do negcio atravs do
aumento da eficincia e eficcia dos processos de TI
Suportar os requisitos para empresas governo com governana de TI
apropriada e controlars
Criar vantagem competitiva atravs da explorao e inovao da
infraestrutura de TI como um todo
Melhorar o servio qualidade, Satisfao do cliente e usurio percepo
Garantir a conformidade regulamentar e legislativo
Garantir nveis adequados de proteco em todas as TI e os ativos de
informao
Garantir que os servios de TI esto alinhados e continuar a estar
alinhado com as necessidades de negcio.

Figura 3.15 ilustra a relao de servio actividades e Servio de Gesto deE do


alcance e da faixa que eles oferecem em termos de valor para o negcio e TI.

ITIL V3 - Service Design - Pgina:

92 de 477

Figura 3.15 O contnuo de gesto de TI

ITIL V3 - Service Design - Pgina:

93 de 477

3,11 design modelos de servio


O modelo seleccionado para o projeto de servios de TI vai depender
principalmente do modelo selecionado para a entrega de servios de TI. Antes
de adotar um modelo de design para um servio novo e importante, uma rever
da corrente capacidade e disposies em relao a todos os aspectos da
entrega de servios de TI devem ser realizados. Esta avaliao deve considerar
todos os aspectos do novo servio, incluindo a:

Drivers de negcio e requisitos


Escopo e capacidade do actual provedor de servios unidade
Demandas, metas e requisitos do novo servio
Alcance e capacidade de externo fornecedors
Maturidade do organizaos presentemente envolvidas e da sua
processoes
Cultura das organizaes envolvidas
Infra-estrutura de TI,aplicaos, dados, servios e outros componentes
envolvidos
Grau de corporativa e de TI governo eo nvel de propriedade e controle
necessrios
Oramentos e recursos disponvel
Nveis de pessoal e competncias.

Esta avaliao /avaliao fornece um mecanismo estruturado para determinar as


capacidades de uma organizao e do estado de prontido para a oferta de
novos servios ou revistas em suporte de drivers de negcio definidas e
exigncias. A informao obtida a partir de tal avaliao pode ser utilizado na
determinao da distribuio estratgia para um servio de TI em particular ou
sistema de TI. A entrega estratgia o mtodo utilizado para mover uma
organizao de um estado conhecido, com base na avaliao de prontido, para
um estado desejado, a determinao dos drivers de negcio e necessidades.
Existem muitas maneiras de preparar um organizao para a implantao de um
novo servio. O mtodo e estratgia escolhida deve ser baseado na soluo a
organizao escolhe para o cumprimento de seus drivers de negcios-chave,
bem como as capacidades da organizao de TI e seus parceiros. A escala de
opes disponveis muito grande, e no todas as necessidades opo ser
considerado em todos os casos. No entanto, manter todas as opes
disponveis para a considerao fundamental para a concepo e operao de
solues inovadoras para os desafios de negcios mais difceis. No final, este
pode ser a diferena entre uma falha projeto - Ou mesmo uma empresa falhou e um sucesso.
Estes dois modelos, para os servios de projeto e entrega de TI, esto
intimamente relacionados e so considerados nas duas seces seguintes.

ITIL V3 - Service Design - Pgina:

94 de 477

3.11.1 modelo opes de entrega


Embora a avaliao de prontido determina a diferena entre os recursos atuais
e desejado, uma organizao de TI no deve, necessariamente, tentar
preencher essa lacuna por si s. H muitas estratgias diferentes de entrega
que podem ser utilizados. Cada um tem seu prprio conjunto de vantagens e
desvantagens, mas todas elas requerem algum nvel de adaptao e
personalizao para a situao em questo. Tabela 3.2 lista as principais
categorias de estratgias de sourcing com um pequeno resumo de cada um.
Entrega prticas tendem a cair em uma dessas categorias ou alguma variante
deles.
Estratgia de
entrega

Descrio

Insourcing

Esta abordagem baseia-se na utilizao de recursos internos da organizao


no projeto,desenvolvimento,transio, A manuteno, operao e / ou apoio
de novo, alterado ou revisto servios ou operaes de data center

Terceirizao

Esta abordagem utiliza o recursos de uma organizao externa ou


organizaes em um acordo formal para fornecer uma parte bem definida de
um servio de design, desenvolvimento, manuteno, operaes e / ou
apoio. Isto inclui o uso de servios a partir de Provedores de Servios de
Aplicao (ASPs) descrito abaixo

Co-sourcing

Muitas vezes, uma combinao de insourcing e terceirizao, usando um


nmero de organizaes de terceirizao trabalhando juntos para elementos
co-fonte-chave na ciclo de vida. Isto geralmente envolve o uso de um
nmero de externa organizaos trabalhando juntos para projetar,
desenvolver, transio, Manter operar e / ou suportar uma poro de um
servio

Parceria ou
multi-sourcing

Acordos formais entre duas ou mais organizaes de trabalhar juntos para


projetar, desenvolver, transio, Manter, operar e / ou apoio De servios de
TI(S). O foco aqui tende a ser em estratgico parcerias que utilizar o
conhecimento crtico ou oportunidades de mercado.

Business
Process
Outsourcing
(BPO)

A tendncia crescente de deslocalizao funes empresariais inteiros


usando acordos formais entre as organizaes onde uma organizao
fornece e gerencia o processo de outra organizao de negcios de todo (s)
ou funes (s) em um local de baixo custo. Exemplos comuns so folha de
pagamento, contabilidade e call center operaes

Prestao de
Servios de
Aplicativos

Envolve acordos formais com um Application Service Provider (ASP) a


organizao que ir fornecer o Shared Computer baseados em servios para
organizaes clientes atravs de uma rede. Aplicaos oferecidos desta
forma so tambm por vezes referido como software on-demand /
aplicaes. Atravs ASPs, as complexidades e custars de software
compartilhado pode ser reduzida, desde a organizaes que poderiam de
outra forma no justificam o investimento

Knowledge
Process

A mais nova forma de terceirizao, KPO um passo frente de BPO em


um aspecto. Organizaes KPO fornecer baseada em domnio processoes e

ITIL V3 - Service Design - Pgina:

95 de 477

Outsourcing
(KPO)

conhecimento de negcio e no apenas conhecimento de processo, e


exigem habilidades avanadas de anlise e especializado a partir da
organizao de terceirizao

Tabela 3.2 Principais estratgias de entrega de servios

Tabela 3.2 destaca um ponto chave: o conjunto de estratgias de entrega varia


muito e varia de uma situao relativamente simples, apenas conseguiu dentro
dos limites de uma empresa, todo o caminho para uma situao 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 estratgia so
discutidos na Tabela 3.3 a seguir.
Todas as disposies acima referidas podem ser fornecidos em ambos um offshore ou em terra situao. No caso em terra, ambas as organizaes so
baseadas no mesmo pas / continente, enquanto que na situao off-shore as
organizaes esto em diferentes pases / continentes. Muito complexos
arranjos de terceirizao existem dentro da indstria de TI e impossvel cobrir
todas as combinaes e suas implicaes aqui. ITIL Service Srie Prtica de
Gesto Complementar ir fornecer orientaes sobre estratgias de
abastecimento.
Fuses e aquisies podem tambm complicar as questes. Estas situaes
ocorrem quando uma empresa adquire ou se funde com outra empresa por
dinheiro e / ou equidade swaps de aes da empresa. Mais uma vez, isso ocorre
geralmente em resposta a consolidao da indstria, a expanso do mercado,
ou em resposta direta s presses competitivas. Se as empresas que tm
estratgias diferentes de entrega de servios so adquiridos ou mesclar, um
perodo de reviso e consolidao muitas vezes necessria para determinar o
fornecimento mais adequado estratgia para a organizao recm-fundidas. No
entanto, as fuses e aquisies muitas vezes pode fornecer organizaos com a
oportunidade de consolidar o melhores prticas de cada organizao,
melhorando assim o servio global capacidade e obteno de sinergias em toda
a organizao. Oportunidades tambm existem para fornecer melhores opes
de desenvolvimento de carreira para Servio de Gesto de pessoal e para a
consolidao fornecedor contrato para servios.

3.11.2 Design e opes de desenvolvimento


As estratgias de entrega so relevantes para ambos o projeto e transio as
fases do ciclo de vida de servio, bem como a fase de operao. Extremo
cuidado deve ser tomado ao selecionar estratgias diferentes para diferentes
fases do ciclo de vida para assegurar que todas as organizaes envolvidas
compreender claramente os seus papis e responsabilidades individuais, e
tambm todos os outros da organizao papel ea responsabilidade de assegurar

ITIL V3 - Service Design - Pgina:

96 de 477

aceitao e entrega de processos esto claramente definidos, acordados e


aceites.
Um banco de tamanho mdio se fundiu com outro banco que tinha um portflio
de produtos complementares. Por isso a integrao de aplicaos era simples.
No entanto, os dois bancos sentiram que a consolidao das operaes seria
benfico, mas no conseguiu alavancar o economias de escala a um nvel
suficiente. Terceirizao tambm foi uma opo, mas sim os dois bancos
escolhemos fazer parceria com uma empresa terceirizada. Os bancos forneceu
o conhecimento especfico do banco para fazer a sua De servios de TIa
organizao de um centro de dados atraentes para os bancos menores. O
parceiro de outsourcing, desde a experincia e tecnologia necessria nova
clientes beneficiar das economias de escala.
Ento como que uma organizao a determinar a entrega ideal estratgia?
No h uma resposta nica ou simples para esta pergunta. muito dependente
da situao singular e especfico em estudo. Por esta razo, a orientao mais
conveniente que pode ser fornecida descrever as principais vantagens e
desvantagens de cada uma das estratgias de entrega. Isto, por sua vez, pode
ser usado como uma lista de verificao para determinar qual a abordagem de
entrega deve ser melhor avaliada e beneficiar mais especfico projeto ou
iniciativa empresarial. Tabela 3.3 lista cada estratgia e suas principais
vantagens e desvantagens para a entrega de uma aplicao ou servio de TI.

ITIL V3 - Service Design - Pgina:

97 de 477

Estratgia de entrega

Vantagens

Desvantagens

Insourcing

Dirigir controlar
Liberdade de escolha
Prototipagem rpida de ponta
servios
Polticas familiares e processoes
Empresa de conhecimentos
especficos

Limitaes de escala
Custo e tempo de mercado para
servios prontamente disponveis
fora
Dependente interno recursos e
suas habilidades e competncias

Terceirizao

Economias de escala
Conhecimentos adquiridos
Suporta foco nas competncias
essenciais da empresa
Suporte para necessidades
transitrias
Test drive / trial de novos servios

Menos controle direto


Barreiras de sada
Risco de solvncia de
fornecedors
Desconhecido habilidades e
competncias fornecedor
Mais desafiador processo de
negcio integrao
Aumento governo e verificao

Co-sourcing

Tempo de mercado
Conhecimentos alavancados
Controlar
Uso de fornecedores
especializados

A complexidade do projeto
Propriedade intelectual e
proteo de direitos autorais
Cultura choque entre empresas

Parceria ou multisourcing

Tempo de mercado
Expanso do mercado / entrada
Resposta competitiva
Conhecimentos alavancados
Alinhamento, confiana e benefcio
mtuo
'Risco e recompensa' acordos

A complexidade do projeto
Propriedade intelectual e
proteo de direitos autorais
O choque de culturas entre as
empresas

Business Process
Outsourcing (BPO)

nico ponto de "Balco nico"


responsabilidade
O acesso a competncias
especializadas
Risco transferido para o
contratante
Baixo custo de localizao

O choque de culturas entre as


empresas
Perda de conhecimento do
negcio
Perda de relao com o negcio

Prestao de Servios
de Aplicativos

O acesso a solues caras e


complexas
Baixo custo de localizao
Suporte e atualizaes includo
Segurana e opes ITSCM
includo

O choque de culturas entre as


empresas
Acesso s instalaes apenas,
no o conhecimento
Muitas vezes com base em uso
de carregamento modelos

Knowledge Process
Outsourcing (KPO)

O acesso a competncias
especializadas, conhecimento e
experincia
Baixo custo de localizao

O choque de culturas entre as


empresas
Perda de competncias internas
Perda da relao com o negcio

ITIL V3 - Service Design - Pgina:

98 de 477

Significativas economias de custo

Tabela 3.3 Vantagens e desvantagens das estratgias de prestao de servios

O estratgia seleccionado depender da capacidade e as necessidades da


organizao especfica, o seu negcio e as pessoas - cultura e capacidades.
Qualquer que seja a estratgia selecionada, seu sucesso e operao devem
ser medidos e revistos regularmente para eficcia e eficincia e adaptado para
atender s necessidades empresariais em constante mudana. A seleo
adotado em relao De servios de TI prestao muitas vezes pode ser
influenciado pela cultura global de negcios e sua abordagem para terceirizao
e parcerias.

3.11.3 abordagens de projeto e desenvolvimento


Tambm importante compreender o genrico atual ciclo de vida tipos, mtodos
e abordagens para o servio de TI desenvolvimento, A fim de decidir sobre as
normas para o Design de Servios fase do ciclo de vida. Para isso, um bom
entendimento necessrio os seguintes aspectos dos vrios Ciclo de Vida
Servio de Desenvolvimento (SDLC) abordagens:

A estrutura (por exemplo, metas / etapas / fases)


As atividades (por exemplo, os fluxos de trabalho ou detalhados passos /
tarefas descritas dentro de uma abordagem)
Os modelos primrios associados com o mtodo escolhido, geralmente
com uma perspectiva de processo, de uma perspectiva de dados, uma
evento perspectiva e, muitas vezes, um usurio perspectiva. Exemplos
incluem caso de uso , diagramas de classe e diagramas de grfico de
estado da Unified Modeling Language (UML).

H mais detalhes sobre SDLC no Captulo 5.


3.11.3.1 Rapid Application Development

necessrio compreender as diferenas entre orientada a objetos e estruturada


de desenvolvimento de sistemas, os princpios bsicos do "Agile" (Rapid
Application Development (RAD) ou o desenvolvimento acelerado so outros
termos usados na rea) movimento e reconhecer como um compromisso com a
uma soluo de pacote de software modifica a estrutura da abordagem.
Estas abordagens, que por padro abordar um nico sistema (e relacionado
servios) apenas, pode ser completada por abordagens de arquitecturas, tais
como aqueles baseados em componente baseado reutilizao (ver a seco
sobre arquitetura para discusso).
O ciclo de vida do aplicativo modelo descrito na seo sobre Gesto de
Aplicaes (seo 5.1.3) pode ser visto como um exemplo de linear ou "cascata"
ITIL V3 - Service Design - Pgina:

99 de 477

(ou modelo 'V') abordagem baseada, e no sero discutidos em mais detalhes


aqui, exceto para fins de comparao com outras abordagens.
A principal caracterstica da RAD a introduo de incrementos e iteraes no
desenvolvimento processo para a gesto dos riscos associados com a incerteza
e mudanas de requisitos. As abordagens tradicionais tm assumido que um
conjunto completo de requisitos pode ser definida no incio do ciclo de vida e que
o desenvolvimento custars pode ser controlado atravs da gesto mudar. No
entanto, a mudana pode significar desanimador sendo indiferente s condies
do negcio. Abordagens RAD aceitar que a mudana inevitvel e tentativa de
minimizar os custos de responder a elas, mantendo a necessria qualidade.
O uso de incrementos implica que um servio desenvolvido pea por pea,
onde cada pea poderia apoiar uma das funes de negcios que as
necessidades de todo o servio. Entrega incremental pode resultar em menor
tempo de mercado para funes especficas do negcio. O desenvolvimento de
cada incremento requer passagem de todos ciclo de vida fases.
O desenvolvimento iterativo implica que o ciclo de vida vai ser percorrido mais
de uma vez, por design. Tcnicas como a prototipagem so usados para obter
uma melhor compreenso dos requisitos (por meio de testes, gesto e funcional
operacional atividades e atravs da comunicao com usurios).
Combinaes de iterativo e abordagens incrementais so possveis. possvel
comear com a especificao de requisitos para o servio completo, seguindose a projeto e ao desenvolvimento do aplicao incremental.
Mtodos de desenvolvimento RAD, incluindo o Processo Unificado e Mtodo de
Desenvolvimento de Sistemas Dinmicos (DSDM) so vistos como uma
resposta s expectativas de negcios, com o objetivo de reduzir o custo da
mudana ao longo de um desenvolvimento projeto. DSDM utiliza contnua
usurio envolvimento em um desenvolvimento iterativo e abordagem
incremental, que sensvel s mudanas de requisitos, para desenvolver um
sistema de software que satisfaa os requisitos de negcio no tempo e no
oramento. Outro exemplo, Extreme Programming (XP), apela para os
desenvolvedores:

Produzir um servio de entrega primeira semana, para conseguir uma


vitria inicial e retorno rpido
Inventar solues simples, para que haja menos de modificar e tambm
facilitar a mudana
Melhorar a qualidade do projeto continuamente
Teste precoce para menos caro de busca de avarias
Use disciplinas bsicas, tais como revers, configurao e gesto da
mudana para manter o controle.

ITIL V3 - Service Design - Pgina:

100 de 477

Para fazer bom uso de uma abordagem incremental, o projeto processo tem de
ser baseada numa separao de interesses, Agrupando as funes dentro de
incrementos, de tal modo que a sua interdependncia minimizado.
Em termos gerais, mtodos de desenvolvimento acelerado de aplicaes adotar
um modelo de trs fases do ciclo de vida: anlise acelerado e design,
desenvolvimento, tempo encaixotado e produo e implementao. Os mtodos
so normalmente apoiadas por tecnologia de engenharia de software, e
dependem de articulao (IT-usurio) Trabalhando e prototipagem rpida para
definir os requisitos e criar um prottipo funcional.
A partir de um perspectiva de negcios, O uso de desenvolvimento incremental
e entrega por desenvolvedores significa que uma parte, vlido distinta do servio
global pode ser entregue antes de a equipe de desenvolvimento est em uma
posio para concluir todo o projeto. Esta abordagem oferece benefcios
imediatos para a negcio, E oferece uma oportunidade para os empresrios e
equipe de desenvolvimento para descobrir emergente servio propriedades e
aprender com a sua experincia. No entanto, muitas vezes difcil encontrar um
incremento suficientemente pequeno primeiro que pode proporcionar um servio
significativo para os negcios.
Mtodos que incorporem RAD iterao e entrega incremental pode ser usado
para reduzir o desenvolvimento e os riscos de implementao. O real projetos
pode no ser necessariamente mais fcil de gerir, mas eles podem facilitar a
implementao e aceitao. Eles oferecem mais opes de contingncia e
permitir aos desenvolvedores a lidar com a mudana de requisitos de negcio e
das condies ambientais. Eles tambm fornecem ambos os marcos e pontos
de deciso para fins de controle do projeto. Estes mtodos podem
adicionalmente ser utilizadas para:

Alcanar ou convergir para um desenho aceitvel para o cliente e viveis


para a equipe de desenvolvimento
Limitar a exposio do projeto para os elementos imprevisveis de
negcios e mudana ambiental
Economize tempo de desenvolvimento, embora para um projeto RAD
sucesso, algo diferente de programao deve ser negocivel. (RAD tem a
melhor chance de sucesso se o negcio est disposto a negociar sobre a
funcionalidade e qualidade).

Importantes Desenvolvimento Rpido de Aplicaes (RAD) restries ou Fator


Crtico de Sucessos (QCA) incluem:

'Aptido para fins comerciais ", como o critrio para aceitao de entregas
Representao de todas as partes que podem afetar os requisitos de
aplicao em todo o desenvolvimento processo

ITIL V3 - Service Design - Pgina:

101 de 477

Clientes, desenvolvedores e gerncia aceitar entregas informais, por


exemplo, notas de usurio oficinas em vez de documentos formais
exigncias
Criando a documentao mnima necessria para facilitar o futuro
desenvolvimento e manuteno
Capacitao das equipes de desenvolvimento para tomar decises
tradicionalmente esquerda para a gesto
Iterao ser usado de tal maneira a convergir para uma soluo comercial
aceitvel
Prottipos que podem incorporar requisitos em evoluo rapidamente,
para obter consenso no incio da ciclo de vida.

A utilizao de abordagens RAD requer qualificados, equipes multidisciplinares,


que so capazes de aconselhar sobre quando aplicar essas abordagens.
Categoria

Desenvolvimento convencional

Desenvolvimento acelerado

Abordagem geral

Fases seqenciais

Evolutivo

Usurio 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 no podem
surgir at bem dentro do
projeto de desenvolvimento

Abaixe - superfcie problemas


no incio da desenvolvimento
processo rpido e que exige
resoluo

Patrocnio executivo

Tem autoridade de aprovao,


mas no ativamente envolvidos

Elevada participao - conjuntos


escopo, Analisa os progressos e
problemas resolve

Utilizao de tcnicas
conjuntas de iterao
sesso, e prototipagem

Opcional

Exigido

Habilidades desenvolvedor

Especialistas, alguns com


experincia limitada aceitvel

Altamente experientes, multiqualificados profissionais


necessrios

Utilizao de processo
tecnologia de suporte, 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 necessria

Gerenciamento de escopo
rigorosa

Necessrio

Crtico

ITIL V3 - Service Design - Pgina:

102 de 477

Estrutura de fase

Fases 4-5

3 fases

Responsabilidade
individual

Difcil avaliar

Prestao de contas precisa

Comparao Tabela 3.4 entre as abordagens convencionais ("cascata") e RAD


3.11.3.2 Off-the-shelf solues

Muitos organizaos agora escolher a cumprir seu De servios de TI requisitos


atravs de compra e implementao de comercial off-the-shelf (COTS) pacote
de solues de software. Uma estrutura para selecionar, personalizar e
implementar essas solues off-the-shelf embalados necessrio e inclui a
necessidade de:

Compreender plenamente as vantagens e desvantagens da abordagem


pacote
Definir um quadro de seleo eficaz pacote de software
Definir um quadro de personalizao e integrao eficaz
Definir os requisitos funcionais ao nvel adequado
Desenvolver uma lista de gesto e operacional requisitos
Definir o produto e fornecedor requisitos
Definir os requisitos de integrao de servios
Identificar e investigar possveis off-the-shelf solues de pacotes de
software
Apresentar recomendaes sobre o ataque de um pacote de software
selecionado off-the-shelf contra os requisitos acordados, e definir as
implicaes desta.

Padres detalhados sero necessrios em:

Pacotes e prototipagem
Definio da estrutura de ponderao avaliao matrizes
Iterao na seleo de pacotes.

Adicionalmente, procedimentos para avaliar e comparar pacotes de


concorrentes em termos de customizao / integrao requisitos so
necessrios e devem incluir:

Avaliando o jogo funcional


Manifestaes escritas e de avaliao orientada para o utilizador
Avaliando a partida de gesto e operacionais
Avaliando os requisitos de implementao corresponder.

Normas para documentar os requisitos antes da investigao de mercado


pacote deve incluir aqueles especificamente mostrando:

ITIL V3 - Service Design - Pgina:

103 de 477

Funes de alto nvel (para fins de definio de escopo)


Funes de negcios e eventos significativos
De entrada e de requisitos de sada
Dados (esttico) estruturas
Identificar relaos entre essas estruturas, funes e eventos
Servio em toda a gesto e requisitos operacionais
Requisitos no-funcionais, tais como atuao,rendimento, Desastre
recuperao capacidades de infra-estrutura e segurana padres.

Ao avaliar solues COTS, considere as seguintes trs maneiras em que um


exigncia pode ser cumprida:

Disponvel off-the-shelf
Pode ser configurado. Estimar o esforo para executar a configurao.
Isso s precisa ser feito uma vez e ser preservado ao longo atualizaes
do produto
Deve ser personalizado. Estimar o esforo para realizar a personalizao
inicialmente e repeti-lo em cada atualizao do produto, tendo em conta
que o conceito de personalizao pode no ser aplicvel a futuros
lanamentos.

Tambm investigar a estratgia e plano de lanamento 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 - Pgina:

104 de 477

4 design processos de servio


Este captulo descreve e explica os fundamentos dos principais processos de
design de apoio de servio. Estes processos so os principais responsveis por
fornecer informaes importantes para o projeto de solues de servios novos
ou alterados. H cinco aspectos de design que precisam ser considerados:

O design dos servios, incluindo todos os requisitos funcionais, recursos e


as capacidades necessrias e acordadas
A concepo de Servio de Gesto de sistemas e ferramentas, em
especial os Portflio de Servios, Para a gesto e controlar de servios
por meio de sua ciclo de vida
O design das arquiteturas de tecnologia e sistema de gestos necessria
para fornecer o servios
O desenho dos processos necessrios para projetar, transio,operar e
melhorar a ateno, os arquiteturas e os processos prprios
O design dos mtodos de medio e mtricas dos servios, 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 negcio desejado resultados e os
resultados planejados deve ser definido de modo que o que entregue atende
s expectativas do clientes e usurios. Assim, esta abordagem estruturada
devem ser adoptadas em cada um dos cinco aspectos para entregar qualidade,
Consistncia repetvel e melhoria contnua em todo o organizao. No h
situaes dentro De servios de TI prviso com interno ou externo provedor de
servioss em que no h processos no Design de Servios rea. Todos
Provedor de servios de TI organizaes j tm alguns elementos de sua
abordagem a estes aspectos cinco no lugar, no importa o quo bsica. Antes
de iniciar a implementao da melhoria das atividades e processos, uma rever
deve ser conduzida de quais elementos esto no lugar e trabalhando com
sucesso. Muitos provedor de servios organizaes j tm maturidade
processoes no lugar para a concepo de servios de TI e solues.
Todos os projetos e atividades do projeto precisam ser impulsionados
principalmente pelas necessidades e requisitos de negcio da organizao.
Dentro deste contexto, tambm deve refletir as necessidades das estratgias,
planos e polticas produzidas por Estratgia de Servio processos, tal como
ilustrado na Figura 4.1.

ITIL V3 - Service Design - Pgina:

105 de 477

Figura 4.1 As ligaes principais, entradas e sadas de Design de Servios

Figura 4.1 d uma boa viso geral das ligaes, entradas e sadas envolvidos
em cada fase do ciclo de vida de servios. Ela ilustra os principais resultados
produzidos por cada fase, os quais so usados como entradas pelas fases
subsequentes. O Portflio de Servios atua como "a coluna vertebral" do Ciclo
de Vida do Servio. a nica fonte integrada de informaes sobre o estado de
cada servio, juntamente com outros detalhes do servio e as interfaces e
dependncias entre servios. A informao na Carteira de servio usado pelas
atividades dentro de cada fase do ciclo de vida de servios.
O resultado fundamental do Design de Servios estgio o projeto de solues
de servios para atender as novas exigncias do negcio. No entanto, ao
projetar essas solues, a entrada de diversas reas precisa ser considerado
dentro das diversas atividades envolvidas na concepo da soluo de servios,
desde a identificao e anlise de requisitos, at a construo de uma soluo e
SDP a entregar a Transio de Servio.

ITIL V3 - Service Design - Pgina:

106 de 477

A fim de desenvolver solues de servios eficazes e eficientes que atendam e


continuam a cumprir os requisitos do negcio e as necessidades de TI,
essencial que todas as entradas e as necessidades de todas as outras reas e
processos so reconsiderados dentro de cada uma das atividades do projeto de
servio , como ilustrado na Figura 4.2. Isso ir garantir que todas as solues de
servios so coerentes e compatveis com as solues existentes e ir satisfazer
as expectativas dos clientes e usurios. Isso vai ser mais eficazes, consolidando
essas facetas da chave processoes em todas essas atividades de design de
servio, de modo que todas as entradas so automaticamente referenciado toda
vez que uma soluo de servio novo ou alterado produzido.

Figura 4.2 Service Design - a grande imagem

ITIL V3 - Service Design - Pgina:

107 de 477

4.1 Gesto Catlogo de Servios


4.1.1 Finalidade objetivo / / objetivo
O objetivo da Gesto Catlogo de Servio oferecer uma nica fonte de
informaes consistentes sobre todos os servios acordados, e garantir que ele
est amplamente disponvel para aqueles que so aprovados para acess-lo.
O objectivo do processo de gesto de servio de catlogo o de assegurar que
um Catlogo de Servios produzido e mantido, contendo informao precisa
sobre todos operacional servios e aqueles que esto sendo preparados para
ser executado operacionalmente.
O objetivo Gesto de Catlogo de Servio gerenciar as informaes contidas
dentro do Catlogo de Servio, e para garantir que ele est correto e reflete os
detalhes atuais, estado, Interfaces e dependncias de todos os servios que
esto sendo executados, ou sendo preparado para correr, no viver ambiente.

4.1.2 mbito
O escopo do processo de Gerenciamento de Catlogo de Servio fornecer e
manter informaes precisas sobre todos os servios que esto sendo
transitaram ou foram transferidos para o meio ambiente ao vivo.
As atividades de servios de Gesto Catlogo deve incluir:

Definio de servio
Produo e manuteno de um preciso Catlogo de Servios
Interfaces, dependncias e de consistncia entre o Catlogo de Servios
e Portflio de Servios
Interfaces e dependncias entre todos servios e servios de apoios
dentro do Catlogo de Servio e da CMS
Interfaces e dependncias entre todos os servios, e de apoio
componentes e Item de Configuraos (IC) dentro do Catlogo de Servio
e da CMS.

4.1.3 Valor para o negcio


O Catlogo de Servios uma fonte central de informaes sobre os servios de
TI entregues pelo provedor de servios organizao. Isto assegura que todas as
reas do negcio pode ver uma imagem precisa e consistente do De servios de
TIs, os seus pormenores e suas estado. Ele contm uma vista de frente para o
cliente dos servios de TI em uso, como se se destinam a ser utilizadas, o
processo de negcioes que permitem, e os nveis e qualidade do servio de
cliente pode esperar para cada servio.
ITIL V3 - Service Design - Pgina:

108 de 477

4.1.4 Polticas, princpios e conceitos bsicos


Ao longo dos anos, as organizaes " Infra-estrutura de TIs tm crescido e se
desenvolvido, e no pode ser uma viso clara de todos os servios atualmente
prestados e os clientes de cada servio. A fim de estabelecer um quadro
preciso, recomenda-se que um portflio de servios de TI contendo um Catlogo
de Servios produzido e mantido para fornecer um conjunto central de
informaes precisas sobre todos os servios e desenvolver um servio com
foco cultura.
O portflio de servios deve conter todos os requisitos futuros de servios e do
Catlogo de Servio deve conter detalhes de todos servios sendo fornecido ou
aqueles que esto sendo preparados para transio para o meio ambiente ao
vivo, um resumo de suas caractersticas, e os detalhes dos clientes e
mantenedores de cada um. Um grau de "trabalho de detetive" podem ser
necessrios para compilar essa lista e concorda com os clientes (peneirar
documentao antiga, procurando bibliotecas de programas, falando com a
equipe de TI e os clientes, olhando para aquisies 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 informao, embora
eles devem ser verificados antes da incluso dentro ou o Servio de Carteira ou
Catlogo de Servios. O Portflio de Servios produzido como parte de
Estratgia de Servio e deve incluir a participao de todos os envolvidos em
Design de Servio, Transio, Operao e Melhoria. Uma vez que um servio
'fretado' (a ser desenvolvido para uso por clientes, Design de Servios produz o
especificaos para o servio e neste ponto que o servio deve ser adicionado
ao Catlogo de Servios.
Cada organizao deve desenvolver e manter um poltica no que diz respeito
tanto Carteira do eo Catlogo, relativo aos servios gravadas no seu interior, o
que os detalhes so gravados e o status so gravadas para cada um dos
servios. A poltica deve conter tambm informaes sobre as responsabilidades
de cada seo do portflio de servios em geral e do escopo de cada uma das
seces que o constituem.
O servio de processo de Gesto de Catlogo produz e mantm o Catlogo de
Servios, garantindo que uma fonte central, precisa e consistente dos dados
fornecido, registrando a estado de todos operacional servios ou servios a ser
transferida para o viver ambiente, Juntamente com os detalhes adequados de
cada servio.
O que um servio? Esta questo no to fcil de responder, pois pode
parecer primeira vista, e muitas organizaes no conseguiram chegar a uma
definio clara em um contexto de TI. A equipe de TI muitas vezes confundem
um 'servio' como percebida pelo cliente com um sistema de TI. Em muitos
casos, um "servio" pode ser feito de outros "servios" (e assim por diante), que

ITIL V3 - Service Design - Pgina:

109 de 477

so 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 aplicaos. Um bom ponto de partida muitas vezes a pedir
aos clientes que os servios de TI que eles usam e como os servios de mapas
para e apoiar a sua processo de negcioes. Os clientes muitas vezes tm uma
maior clareza do que eles acreditam ser um servio. Cada organizao precisa
desenvolver uma poltica de que um servio e como ele definido e acordado
dentro de sua prpria organizao.
Para evitar confuso, pode ser uma boa idia para definir uma hierarquia de
servios na Catlogo de Servios, Qualificando exatamente que tipo de servio
registrado, por exemplo, servio de negcio (O que visto pelo cliente).
Alternativamente, servios de apoios, tais como servio de infra-estruturas
servios, de rede, servios de aplicativos (todos invisveis para o cliente, mas
essencial para a prestao de servios de TI) tambm precisam ser registradas.
Isso muitas vezes d origem a uma hierarquia de servios incorporando servios
ao cliente e outros servios relacionados, incluindo servios de apoio, servios
compartilhados e servios de commodities, cada um com definido e acordado
nvel de servios.
Quando inicialmente preenchido, o catlogo de servio pode ser constitudo por
uma matriz de mesa, ou folha de clculo. Muitas organizaes integrar e manter
a sua Portflio de Servios e Catlogo de Servios como parte de seu CMS. Ao
definir cada servio como um Item de Configurao (IC) e, se for caso disso,
relacionando-as de modo a formar uma hierarquia de servio, o organizao
capaz de se relacionar eventos tais como acidentes e RFCs aos servios
afectados, assim fornecendo a base para o servio monitoramento e relatrios
utilizando uma ferramenta integrada ('lista ou dar o nmero de incidentes que
afectam este servio particular ", por exemplo). Portanto, essencial que as
mudanas dentro do portflio de servios e Catlogo de Servios esto sujeitos
Gesto da Mudana processo.
O catlogo de servio pode tambm ser utilizado para outros Servio de Gesto
de fins (por exemplo para a realizao de um Anlise de Impacto no Negcio
(BIA) como parte da Continuidade do Servio de TI Planejamento, Ou como um
ponto de partida para re-distribuio carga de trabalhos, como parte de
Gerenciamento da Capacidade). O custar e esforo de produzir e manter o
catlogo, com a sua relaos para a tecnologia de sustentao componentes, ,
portanto, facilmente justificvel. Se isso for feito em conjunto com a definio de
prioridades de BIA, ento possvel garantir que os servios mais importantes
so cobertos em primeiro lugar. Um exemplo de um simples Catlogo de
Servios que pode ser usada como um ponto de partida dado no Apndice G.
O Catlogo de Servios tem dois aspectos:

ITIL V3 - Service Design - Pgina:

110 de 477

O Negcio Catlogo de Servios: detalhes contendo de todos os servios


de TI entregues ao cliente, Em conjunto com as relaes para o unidade
de negcioss eo processo de negcios que dependem da De servios de
TIs. Esta a opinio do cliente Catlogo de Servios.
O Catlogo de Servios Tcnicos: Contendo detalhes de todos os
servios de TI entregues ao cliente, juntamente com relaes com os
servios de suporte, servios compartilhados, componentes e CIs
necessrios para apoiar a prestao do servio negcio. Isto deve
apoiar o Catlogo de Servios de Negcios e no fazem parte da viso do
cliente.

A relao entre estes dois aspectos ilustrado na Figura 4.3.

Figura 4.3 O Catlogo de Servios de Negcios e ao Catlogo de Servios


Tcnicos

Algumas organizaes s mantenham um Catlogo de Servios de Negcios ou


de um Catlogo de Servios Tcnicos. A situao preferida adoptada pelas
organizaes mais maduras mantm ambos os aspectos dentro de um catlogo
de servio nica, que parte de um totalmente integrado Servio de Gesto de
atividade e Portflio de Servios. Mais informaes sobre o projeto e contedo
de um Catlogo de Servios est contido no Anexo G. O Catlogo de Servios
de Negcios facilita o desenvolvimento de um processo SLM muito mais prativo ou at mesmo preventiva, permitindo que ela desenvolva mais no campo
de Business Service Management. O Catlogo de Servio Tcnico
extremamente benfica ao construir a relao entre os servios, SLAs, e esteio
OLAs outro acordos e componentes, uma vez que ir identificar a tecnologia

ITIL V3 - Service Design - Pgina:

111 de 477

necessria para suportar um servio eo grupo de apoio(S) que suportam os


componentes. A combinao de um Catlogo de Servios de Negcios e um
Catlogo de Servios Tcnicos de valor inestimvel para avaliar rapidamente o
impacto de incidentes e mudars no negcio. Um exemplo de relaes entre as
partes de negcios e tcnicas de um Catlogo de Servios mostrada na Figura
4.4.

Figura 4.4 Exemplo de Catlogo de Servio

4.1.5 as atividades de processo, mtodos e tcnicas


As principais atividades dentro do processo de Gesto de Servios Catlogo
deve incluir:

Concordando e documentar uma definio de servio com todas as


partes relevantes
Interface com Gesto de Portflio de Servios concordar os contedos da
Portflio de Servios e Catlogo de Servios
Produzir e manter uma Catlogo de Servios e seu contedo, em
conjunto com o portflio de servios

ITIL V3 - Service Design - Pgina:

112 de 477

Interface com o negcio e Gerenciamento da Continuidade do Servio


nas dependncias do unidade de negcioss e a sua processo de
negcioes com os servios de suporte de TI, contido dentro do Catlogo
de Servios de Negcios
Interface com as equipes de apoio, fornecedors e Gerenciamento da
Configurao em interfaces e dependncias entre os servios de TI e os
servios de apoios, e os componentes contidos dentro do IC Catlogo de
Servio Tcnico
Interface com Gesto de Relacionamento com Empresas e
Gerenciamento de Nvel de Servio para garantir que a informao est
alinhado ao processo de negcio e de negcios.

4.1.6 Triggers, entradas, sadas e interfaces


H um nmero de fontes de informao que so relevantes para o processo de
gesto de servio de catlogo. Estes devem incluir:

Informaes de negcios de negcio da organizao e de TI estratgia,


Os planos e os planos financeiros e informaes sobre suas
necessidades atuais e futuras do Portflio de Servios
Anlise de Impacto no Negcio, Fornecendo informaes sobre o
impacto, prioridade e risco associado a cada servio ou mudana de
requisitos de servio
Requisitos de negcios: detalhes sobre qualquer acordados, os requisitos
de negcios novos ou alterados do Portflio de Servios
O portflio de servios
O CMS
Retorno de todos os outros processos.

Os gatilhos para o processo de Gesto de Catlogo de Servio so as


mudanas nos requisitos de negcio e servios e, portanto, uma das principais
causas Requisio de Mudanas (RFCs) e do processo de Gerenciamento de
Mudana. Isso vai incluir novos servios, mudanas nos servios existentes ou
servios que esto sendo reformados.
As sadas do processo de SCM so:

A documentao e acordo de uma "definio do servio '


Atualizaes para o Portflio de Servios: Deve conter o actual estado de
todos os servios e os requisitos para servios
O Catlogo de Servios: Deve conter os detalhes e as atuais estado de
cada viver servio prestado pela provedor de servios ou servio a ser
transferida para o viver ambiente, Em conjunto com as interfaces e
dependncias. Um exemplo de um Catlogo de Servios est contido no
Anexo G.

ITIL V3 - Service Design - Pgina:

113 de 477

4.1.7 Gesto da informao


A informao-chave dentro do processo de Gesto de Servios Catlogo que
continha dentro do Catlogo de Servio. A entrada principal para esta
informao vem do portflio de servios e do negcio, quer atravs da Gesto
de Relacionamento com Empresas (BRM) ou Gerenciamento de Nvel de
Servio (SLM) processos. Esta informao tem de ser verificada para a exatido
antes de ser gravado dentro do Catlogo de Servio. A informao e os servios
de catlogo si devem ser mantidas utilizando o Gesto da Mudana processo.

4.1.8 Indicadores Chave de Desempenho


Os dois principais Key Performance Indicators (KPIs) associado com o Catlogo
de Servios e sua gesto so:

O nmero de servios registradas e gerenciado dentro do Catlogo de


Servios como uma percentagem dos que so fornecidos e transferida no
ambiente real
O nmero de variaos detectado entre as informaes contidas dentro
do Catlogo de Servio e da situao do 'mundo real'.

Outras medidas e KPIs que podem ser utilizados so os seguintes:

Negcio usurioconscincia s 'dos servios prestados, ou seja, no


aumento percentual completude do Catlogo de Servios de Negcios
contra operacional servios
Sensibilizao do pessoal de TI da tecnologia de suporte dos servios:
Aumento percentual integralidade da Catlogo de Servio Tcnico
Contra ele componentes que suportam os servios
Service Desk ter acesso informao para suportar todos os
servios ao vivo, medido pela percentagem de incidentes sem a
informao adequada de servios relacionados.

4.1.9 Desafios, Fatores Crticos de Sucesso e riscos


O maior desafio para o processo de Gesto de Servio de Catlogo a de
manter um preciso Catlogo de Servios como parte de um Portflio de
Servios, Incorporando tanto o Catlogo de Servios de Negcios e da Catlogo
de Servio Tcnico como parte de um CMS geral e SKMS. Este o melhor
abordado por desenvolvimento autnomo planilhas ou bancos de dados antes
de tentar integrar o Catlogo de Servios e Portflio de Servios dentro do CMS
ou SKMS. A fim de alcanar este objectivo, o cultura do organizao tem de
aceitar que o Catlogo e Portfolio so fontes essenciais de informao que todos
dentro da organizao de TI precisa usar e ajudar a manter. Isso, muitas vezes,
ajudar na padronizao do Catlogo de Servio e do portflio de servios e
permitir aumento no custo atuao atravs economias de escala.

ITIL V3 - Service Design - Pgina:

114 de 477

O principal Fator Crtico de Sucessos para o processo de Gesto de Servios


Catlogo so:

Um Catlogo de Servios precisa


Negcio usurioconscincia s 'dos servios que esto sendo prestados
Sensibilizao do pessoal de TI da tecnologia de suporte aos servios.

Os riscos associados com a prestao de um Catlogo de Servios so


precisos:

Inexactido dos dados no catlogo e no estar sob controle de mudanas


rigoroso
Pobre aceitao do Catlogo de Servios e a sua utilizao em todo o
operacional processoes. Quanto mais ativo o catlogo , o mais provvel
ser preciso em seu contedo
Inexatido das informaes recebidas do negcio, TI e Portflio de
Servios, No que se refere informao de servio
As ferramentas e recursos necessria para manter as informaes
Pouco acesso a informaes precisas Gesto da Mudana informaes e
processos
Falta de acesso a e apoio da CMS apropriado e up-to-date e SKMS
Neutralizao da utilizao do Portflio de Servios e Catlogo de
Servios
A informao demasiado detalhado para manter a preciso ou em um
nvel muito alto para ser de qualquer valor. Ela deve ser consistente com
o nvel de detalhe dentro do CMS e os SKMS.

ITIL V3 - Service Design - Pgina:

115 de 477

4.2 Gesto de Nvel de Servio


Gerenciamento de Nvel de Servio (SLM) negocia, concorda e documentos
apropriados De servios de TI alvos com representantes das empresas e, em
seguida monitora e gera relatrios sobre a capacidade do prestador de servios
para entregar o nvel acordado de servio. SLM um processo vital para cada
Provedor de servios de TI organizao na medida em que responsvel por
concordar e documentar meta de nvel de servios e responsabilidades dentro
de SLAs e SLRs, para cada atividade dentro da TI. Se essas metas so
adequadas e refletir com preciso as necessidades do negcio, ento o servio
prestado pelos provedores de servios vo se alinhar com os requisitos de
negcios e atender as expectativas do clientes e usurios em termos de servio
qualidade. Se as metas no esto alinhados com as necessidades do negcio,
em seguida, provedor de servios actividades e nvel de servios no ser
alinhada com as expectativas do negcio e problemas iro desenvolver. O SLA
efetivamente um nvel de garantia ou garantia no que diz respeito ao nvel de
qualidade do servio prestado pelo fornecedor de servios para cada um dos
servios fornecidos para o negcio. O sucesso da SLM muito dependente da
qualidade da Portflio de Servios e a Catlogo de Servios e seus contedos,
porque fornecem as informaes necessrias sobre os servios a serem
gerenciados dentro do processo SLM.

4.2.1 Finalidade objetivo / / objetivo


O objetivo da Gerenciamento de Nvel de Servio processo garantir que um
nvel acordado de servio de TI fornecido para todos os atuais servios de TI,
e que os servios so entregues aos futuros concordou objectivos atingveis.
Medidas pr-ativas tambm so levados a buscar e implementar melhorias ao
nvel do servio prestado.
A finalidade do processo de SLM assegurar que todos operacional servios e
seus atuao so medidos de uma maneira profissional e consistente ao longo
de TI organizao, E que os servios e os relatrios produzidos atender as
necessidades do negcio e clientes.
O objetivos de SLM so os seguintes:

Definir, documentar, concordar, monitor, medida relatrio e analisar o


nvel de servios de TI prestados
Fornecer e melhorar o relao e comunicao com o negcio e clientes
Assegurar que as metas especficas e mensurveis so desenvolvidos
para todos os servios de TI
Monitorar e melhorar a satisfao do cliente com a qualidade do servio
prestado
Garantir que a TI e os clientes tm uma expectativa clara e inequvoca de
o nvel de servio a ser entregue

ITIL V3 - Service Design - Pgina:

116 de 477

Assegurar que as medidas pr-ativas para melhorar os nveis de servio


entregues so implementados onde quer que seja custo-justificvel para
faz-lo.

4.2.2 mbito
SLM deve fornecer um ponto de contato regular e comunicao aos clientes e
gerentes de negcios de uma organizao. Ele deve representar a Provedor de
servios de TI para a empresa, e os negcios TI provedor de servios. Este
atividade deve abranger tanto o uso dos servios existentes e os requisitos
futuros potenciais para novos ou alterados servios. SLM precisa gerenciar a
expectativa e percepo dos negcios, clientes e usurios e garantir que a
qualidade do servio prestado pelo provedor de servio corresponde s
expectativas e necessidades. A fim de fazer isso de forma eficaz, SLM deve
estabelecer e manter SLAs para todos os atuais viver servios e gerenciar o
nvel de servio prestado para cumprir as metas e qualidade medidas contidas
no SLAs. SLM tambm deve produzir e acordar SLR para todos os servios
planejados novos ou alterados.
Isto ir permitir SLM para garantir que todos os servios e componentes so
projetados e entregues a cumprir as suas metas em termos de necessidades de
negcio. A SLM processoes deve incluir o:

Desenvolvimento de relaes com o negcio


Negociao e acordo de necessidades atuais e metas, ea documentao
e gesto de SLAs para todos os servios operacionais
Negociao e acordo das necessidades futuras e metas, ea
documentao e gesto de SLRs para todos os servios propostos novos
ou alterados
Desenvolvimento e gesto de adequada Acordo de Nvel Operacionals
(OLAS) para assegurar que as metas esto alinhadas com as metas de
SLA
Reviso de toda a sustentao fornecedor contratos e acordos com
Gesto de Fornecedores para assegurar que os objectivos esto
alinhados com as metas de SLA
Preveno pr-ativa de servio falhas, reduo de riscos de servios e de
melhoria da qualidade de servio, em conjunto com todos os outros
processos
Elaborao de relatrios e gesto de todos os servios e reviso de todas
as violaes de SLA e fracos
Instigao e coordenao de um Plano de Melhoria de Servio (SIP) para
a gesto, planejamento e implementao de todos os servios e
melhorias de processo.

ITIL V3 - Service Design - Pgina:

117 de 477

4.2.3 Valor para o negcio


SLM oferece uma interface consistente para o negcio para todos os problemas
relacionados ao servio. Ele fornece o negcio com as metas de servio
acordadas e os necessrios gesto da informao para garantir que os
objectivos foram alcanados. Caso os objectivos sejam violados, SLM deve
fornecer feedback sobre a causa da violao e detalhes das aes tomadas
para evitar a violao de recorrentes. Assim SLM oferece um canal de
comunicao confivel e uma relao de confiana com o apropriado clientes e
representantes das empresas.

4.2.4 Polticas / princpios / conceitos bsicos


SLM o nome dado aos processos de planejamento, coordenao, elaborao,
concordando, monitoramento e relatrios de SLAs, eo curso rever de realizaes
de servios para garantir que o servio necessrio e custo-justificvel qualidade
mantido e melhorado gradualmente. No entanto, SLM no se preocupa
apenas com a garantia de que os servios atuais e SLAs so geridos, mas
tambm est envolvido na garantia de que os novos requisitos so capturados e
que os servios novos ou alterados e SLAs so desenvolvidos para atender s
necessidades de negcios e expectativas. SLAs fornecem a base para a gesto
do relao entre o provedor de servios eo cliente, e SLM prev que ponto
central de foco para um grupo de clientes, unidade de negcioss ou linhas de
negcios.
Um SLA um escrito acordo entre um provedor de servios de TI eo cliente de
TI (s), que define as metas de chave e responsabilidades de ambas as partes. A
nfase deve estar em concordncia, e SLAs no devem ser utilizados como uma
forma de realizao de um lado ou do outro de resgate. Um verdadeiro parceria
deve ser desenvolvido entre o Provedor de servios de TI eo cliente, para que
um acordo mutuamente benfico alcanado - caso contrrio, o SLA pode cair
rapidamente em descrdito e uma "cultura da culpa" poderia desenvolver que
impediria qualquer melhoria de qualidade de servios verdadeiros ocorra.
SLM tambm responsvel por garantir que todos os objectivos e as medidas
acordadas em SLAs com o negcio so suportados 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 - Pgina:

118 de 477

Figura 4.5 Service Level Management

Figura 4.5 mostra a relao entre a empresa e seu processoes e a servios, e a


tecnologia associada, servios de apoios, equipes e fornecedores necessrios
para satisfazer as suas necessidades. Isso demonstra a importncia dos SLAs,
OLAs e contratos esto em definio e alcanar o nvel de servio exigido pelo
negcio.
Uma OLA um acordo entre um Provedor de servios de TI e outra parte da
mesma organizao que auxilia na prestao de servios - por exemplo, um
departamento de instalaes que mantm o ar condicionado, ou a equipe rede
de apoio que suporta o servio de rede. Um OLA deve conter metas que
sustentam aqueles dentro de um SLA para garantir que as metas no ser
ultrapassado pelo fracasso do apoio atividade.

4.2.5 As atividades de processo, mtodos e tcnicas


As principais atividades dentro do processo SLM deve incluir:

ITIL V3 - Service Design - Pgina:

119 de 477

Determinar, negociar, documentar e aprovar os requisitos para servios


novos ou modificados em SLRs, e gerenciar e rev-los atravs do ciclo de
vida de servio em SLAs para operacional servios
Monitorar e medir servios atuao conquistas de todos os servios
operacionais contra alvos dentro de SLAs
Cotejar, medir e melhorar a satisfao do cliente
Produzir relatrios de servio
Realizar avaliao de servios e instigar melhorias dentro de um plano
global de Melhoria de Servio (SIP)
Analisar e rever SLAs, servio escopo Olas, contratos, e qualquer outro
esteio acordos
Desenvolver e contatos de documentos e relaes com o negcio,
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 reclamaes e elogios
Proporcionar a adequada gesto da informao para auxiliar gesto de
desempenho e demonstram a realizao de servios
Disponibilizar e manter-se atualizado-SLM documento modelos e
padres.

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


4.6.

ITIL V3 - Service Design - Pgina:

120 de 477

Figura 4.6 O Servio de Gerenciamento de Nvel 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 so descritas nas sees seguintes.
4.2.5.1 SLA estruturas Projetando

Usando o Catlogo de Servios como auxiliar, SLM deve projetar a estrutura de


SLA mais adequado para assegurar que todos os servios e todos os clientes
so abordados de uma forma mais adequada para o organizao'S precisa. H
um nmero de opes potenciais, incluindo o seguinte.
Baseada em servios SLA
Este o lugar onde um SLA cobre um servio, para todos os clientes desse
servio - por exemplo, um SLA pode ser estabelecido para o servio de uma
organizao de e-mail - que abrange todos os clientes que servio. Isto pode
parecer bastante simples. No entanto, as dificuldades podem surgir se os
requisitos especficos de clientes diferentes variar para o mesmo servio, ou se
as caractersticas da infra-estrutura significa que diferentes nvel de servios so

ITIL V3 - Service Design - Pgina:

121 de 477

inevitveis (por exemplo, pessoal de escritrio cabea pode ser ligado atravs
de uma rede local de alta velocidade, enquanto os escritrios locais pode ter que
usar uma menor velocidade de linha WAN). Em tais casos, os alvos distintos
pode ser necessrio no interior de um contrato. Dificuldades podem tambm
surgir na determinao de quem devem ser os signatrios desse acordo. No
entanto, onde os nveis comuns de servio so fornecidos atravs de todas as
reas do negcio, E.g. e-mail ou de telefonia, o SLA baseada em servios pode
ser uma abordagem eficiente de usar. Vrias classes de servio, por exemplo,
prata, ouro e bronze, tambm pode ser usado para aumentar o eficcia de
servio com base SLAs.
Cliente baseado em SLA
Trata-se de um acordo com um grupo de clientes individuais, cobrindo todos os
servios que utilizam. Por exemplo, os acordos podem ser alcanados com uma
organizao 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 so cobertos em um nico documento. Apenas um
signatrio normalmente necessrio, o que simplifica o problema.
Uma combinao de qualquer uma destas estruturas pode ser apropriado,
fornecendo todos os servios e clientes so cobertos, sem sobreposio ou
duplicao.
Multi-nvel SLAs
Algumas organizaes tm optado por adotar uma estrutura SLA multi-nvel. Por
exemplo, uma estrutura de trs camadas como se segue:

Nvel corporativo: Abrangendo todas as questes SLM genricos


apropriados para cada cliente em toda a organizao. Estes problemas
tendem a ser menos volteis, de modo actualizaes so menos
frequentemente necessrio
Nvel de cliente: Abrangendo todas as questes relevantes para o SLM
determinado grupo de clientes ou unidade de negcios,
Independentemente do servio a ser utilizado
Nvel de servio: Abrangendo todas as questes relevantes para o SLM
servio especfico, em relao a um grupo de clientes especficos (um
para cada servio abrangido pela SLA).

Conforme mostrado na Figura 4.7, tal estrutura permite que os SLAs sejam
mantidos a um tamanho administrvel, evita a duplicao desnecessria, e
reduz a necessidade de atualizaes freqentes. No entanto, isso no significa

ITIL V3 - Service Design - Pgina:

122 de 477

que o esforo extra necessrio para manter o necessrio relaos e links


dentro do Catlogo de Servios e do. CMS

Figura 4.7 Multi-nvel SLAs

Muitos organizaos 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. Orientao sobre os itens a serem includos em
um SLA dada no Apndice F. Desenvolvimento de normas e modelos ir
garantir que todos os acordos so desenvolvidos de uma forma consistente, e
isso vai facilitar o seu uso posterior, operao e gesto.
Fazer papels e responsabilidades uma parte do SLA. Considere trs
perspectivas - o provedor de TI, o cliente de TI e do real usurios.
A formulao de SLAs deve ser clara e concisa e no deixam margem para
ambiguidades. Normalmente, no h necessidade de acordos para ser escrito
em terminologia jurdica, e uma linguagem simples ajuda um entendimento

ITIL V3 - Service Design - Pgina:

123 de 477

comum. Muitas vezes, til ter uma pessoa independente, que no foi envolvido
com a redao, para fazer uma final leia-through. Isso muitas vezes joga-se
ambigidades potenciais e as dificuldades que podem ser abordados e
esclarecidos. Por esta razo, recomenda-se que todos os SLAs conter um
glossrio, definindo os termos e proporcionando clareza para todas as reas de
ambiguidade.
Tambm vale a pena lembrar que os SLAs podem ter de cobrir os servios
oferecidos internacionalmente. Nesses casos, o SLA pode ter que ser traduzida
em vrias lnguas. Lembre-se tambm que um SLA redigido em um nico idioma
pode ter que ser revistos para adequao em vrias partes do mundo (ou seja,
um verso redigido na Austrlia pode ter que ser revistos para adequao nos
EUA ou no Reino Unido - e diferenas de estilo, terminologia e cultura Deve ser
tomado em conta).
Onde o De servios de TIs so proporcionados ao outro por uma organizao
prestador de servios externo, Por vezes, o servio alvos esto contidos dentro
de um contrato e em outras vezes eles esto contidos dentro de um SLA ou
cronograma anexo ao contrato. Seja o que for documento usada, essencial
que as metas documentados e acordados so claras, especfica e no ambgua,
uma vez que ser a base da relao e a qualidade do servio prestado.
4.2.5.2 Determinar, documentar e acordar requisitos para novos servios e
produzir SLRs

Esta uma das primeiras actividades dentro do Design de Servios fase do ciclo
de vida de servios. Uma vez que o Catlogo de Servios foi produzido e da
estrutura SLA acordado, uma SLR primeiro deve ser elaborado. aconselhvel
envolver clientes, desde o incio, mas ao invs de ir junto com uma folha em
branco para comear, pode ser melhor para produzir um projecto primeiro
esboo da atuao metas e da gesto e operacional requisitos, como um ponto
de partida para discusso mais detalhada e profunda. Tenha cuidado, porm,
para no ir muito longe e parecem estar apresentando ao cliente um "fato
consumado".
No pode ser over-stressed quo difcil isso atividade de determinar as metas
iniciais para a incluso com uma SLR ou SLA . Todos os outros processoes
devem ser consultados a sua opinio sobre o que so metas realistas que
podem ser alcanados, tais como Gerenciamento de Incidentes em incidente
alvos. A capacidade e Gerenciamento de Disponibilidade processos sero de
particular valor na determinao da disponibilidade de servio adequado e metas
de desempenho. Se houver qualquer dvida, as metas provisrias devem ser
includos em um piloto SLA, que monitorizado e ajustado por meio de um
garantia de servio perodo, tal como ilustrado na Figura 3.5.
Embora muitas organizaes tm de dar prioridade inicial para a introduo de
SLAs para servios existentes, tambm importante estabelecer procedimentos
ITIL V3 - Service Design - Pgina:

124 de 477

por concordar Nvel Requisitos de Servio (SLR) para novos servios a serem
desenvolvidos ou adquiridos.
As SLRs deve ser uma parte integrante do Design de Servios critrios, de que
o funcional especificao uma parte. Eles devem, desde o incio, fazem parte
do teste / experimentao critrios como o servio progride atravs dos estgios
de projeto e desenvolvimento ou aquisio. Este SLR ser gradualmente
refinado como o servio progride atravs dos estgios de seu ciclo de vida, at
que finalmente se torna um SLA piloto durante o incio do perodo de vida de
suporte. Este SLA piloto ou projecto dever ser desenvolvido juntamente com o
servio em si, e deve ser assinado e formalizado antes que o servio
introduzido em uso ao vivo.
Pode ser difcil estabelecer os requisitos, tal como o negcio pode no saber o
que eles querem - especialmente se no pediu anteriormente - e eles podem
precisar de ajuda para entender e definir as suas necessidades, especialmente
em termos de capacidade,segurana,disponibilidade e servios de TI
continuidade. Esteja ciente de que os requisitos inicialmente expressos no
podem ser aqueles finalmente concordou. Vrias iteraes de negociaes
podem ser necessrias antes de um equilbrio econmico est fechado entre o
que pedido eo que vivel e acessvel. Este processo pode envolver uma
reformulao da soluo de servio de cada vez.
Se novos servios esto a ser introduzido de uma forma perfeita para o viver
ambiente, Outra rea que requer ateno o planejamento e formalizao dos
mecanismos de apoio para o servio e sua componentes. Conselho deve ser
solicitada Gesto da Mudana e Gerenciamento da Configurao para
assegurar a planejamento abrangente e cobre a implementao,
desenvolvimento e apoio do servio e seus componentes. Responsabilidades
especficas precisam ser definidos e adicionado ao existente contratos / ANO, ou
novos precisam ser acordados. O regime de apoio e de todos os escalada rotas
tambm precisa de adicionar ao SCC, incluindo o Catlogo de Servios se for o
caso, para que o Service Desk e outro pessoal de apoio esto cientes deles. Se
necessrio, formao inicial e familiarizao para o Service Desk e outros grupo
de apoios e transferncia de conhecimento deve ser concluda antes de apoio
ao vivo necessrio.
Deve notar-se que os recursos de suporte adicionais (isto , mais pessoal) pode
ser necessrio para suportar novos servios. Muitas vezes existe uma
expectativa de que um j sobrecarregado grupo de apoio pode magicamente
lidar com o esforo adicional imposta por um novo servio.
Usando o projecto acordo como base, as negociaes devem ser realizadas
com o cliente (s), ou representantes do cliente para finalizar o contedo do SLA
eo inicial meta de nvel de servios, e com a provedor de servioss para
assegurar que estes so realizveis.

ITIL V3 - Service Design - Pgina:

125 de 477

4.2.5.3 desempenho servio Monitor contra SLA

Nada deve ser includo em um SLA a menos que possa ser efetivamente
monitorados e medidos em um ponto de comum acordo. A importncia desta
no pode ser negligenciado, como a incluso de itens que no podem ser
eficazmente controlado quase sempre resulta em disputas e eventual perda de
f na SLM processo. Um monte de organizaos descobriram o caminho mais
difcil e, como resultado, absorvido pesado custars, tanto no sentido financeiro
como tambm em termos de negativo impactos da sua credibilidade.
Um provedor de rede global acordado metas de disponibilidade para a prestao
de um servio de rede gerenciado. Essas metas de disponibilidade foram
acordados no ponto em que o servio entrou nas instalaes do cliente. No
entanto, o provedor de rede global s poderia monitorar e medir disponibilidade
no ponto de conexo deixaram suas instalaes. As ligaes de rede foram
fornecidos por um nmero de diferentes telecomunicaes nacionais provedor
de servioss, com nveis 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
necessrio. Idealmente isto deve ser feito antes de, ou em paralelo com a
elaborao de SLAs, para que o monitoramento pode estar no lugar para ajudar
com o validao das metas propostas.
essencial que o controlo corresponde a verdadeira percepo do cliente sobre
o servio. Infelizmente, isto frequentemente muito difcil de alcanar. Por
exemplo, a monitorizao de indivduo componentes, tais como a rede ou
servidor, No garante que o servio estar disponvel at o momento que o
cliente est em causa. Percepo do cliente muitas vezes que, apesar de um
falha pode afetar mais de um servio, tudo o que esto preocupadas o servio
que no pode acessar no momento do relataram incidente - Embora isso nem
sempre verdade, ento necessrio cautela. Sem acompanhamento de todas
as componentes do servio de ponta-a-ponta (que pode ser muito difcil e caro
para conseguir) uma imagem verdadeira no pode ser adquirida. Do mesmo
modo, usurios devem ser conscientes de que devem relatar incidentes
imediatamente para diagnstico de ajuda, especialmente se eles esto
relacionadas com o desempenho, de modo que a provedor de servios est
ciente de que as metas de servio esto sendo violados.
Um nmero considervel de organizaes usam seu Service Desk, ligado a um
CMS completo, para monitorar a clientePercepo de disponibilidade. Isso
pode envolver fazer mudanas especficas para incidente /problema log telas e
pode exigir rigorosas observncia com registro de incidentes procedimentos.

ITIL V3 - Service Design - Pgina:

126 de 477

Toda essa discusso necessidades e de acordo com o Gerenciamento de


Disponibilidade processo.
O Service Desk usado tambm para monitorar incidente tempo de respostas e
resoluo vezes, mas mais uma vez a tela de login pode precisar de alteraes
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 tambm podem apoiar
Gesto de Fornecedores.
essencial assegurar que todos os alvos do incidente / problema de
manipulao includos no SLA so os mesmos que os includos nas ferramentas
de atendimento e utilizadas para escalada e efeitos de acompanhamento. Onde
as organizaes tm falhado em reconhecer isso, e talvez usada padres
fornecidos pela ferramenta fornecedor, Eles terminaram em uma situao onde
eles esto monitorando algo diferente do que foi acordado no SLA e, portanto,
incapaz de dizer se as metas de SLA foram cumpridos, sem esforo
considervel para manipular os dados. Algumas alteraes podem ser
necessrias para suportar as ferramentas, de modo a incluir os campos
necessrios para que os dados relevantes podem ser capturados.
Outra rea notoriamente difcil de controlar transao os tempos de resposta
(o tempo entre o envio de uma tela e recebendo uma resposta). Muitas vezes
end-to-end de resposta so tecnicamente muito difcil de controlar. Em tais
casos, pode ser adequado para lidar com este como se segue:

Incluir uma declarao no SLA ao longo das seguintes linhas: Os


servios abrangidos pelo SLA so projetados para alta velocidade de
resposta e no 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
Servio '.
Concordar e incluir no SLA uma meta aceitvel para o nmero de
incidentes que podem ser tolerados no perodo de referncia.
Criar um incidente categoria de 'm resposta' (ou similar) e garantir que
todos esses incidentes so registrados com preciso e que esto
relacionadas com o servio adequado.
Produzir relatrios regulares de ocasies em SLA transao metas de
tempo de resposta foram violados, e abertura de inquritos via
Gerenciamento de Problemas para corrigir a situao.

Esta abordagem no s supera as dificuldades tcnicas de monitoramento, mas


tambm garante que os incidentes de m resposta so relatados no momento
em que eles ocorrem. Isto muito importante, como resposta pobre muitas
vezes causado por uma srie de acontecimentos que interagem transientes que
s podem ser detectados se eles so investigadas imediatamente.

ITIL V3 - Service Design - Pgina:

127 de 477

O mtodo preferido, no entanto, a aplicao de alguma forma de automatizado


cliente/servidor monitoramento de tempo de resposta em estreita consulta com o
Operao de Servio. Sempre que possvel, implementar amostragem ou "rob"
ferramentas e tcnicas para dar indicaes 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 usurios, e esto se tornando cada vez mais disponveis e cada
vez mais rentvel para usar.
Alguns organizaos descobriram que, na realidade, 'm resposta "s vezes
um problema de usurio percepo. O usurio, Tendo-se utilizado a um nvel
particular de resposta ao longo de um perodo de tempo, comea a lamentar,
logo que este mais lenta. Da opinio de que "se o usurio acha que o servio
lento, ento '.
Se o SLA inclui metas para a avaliao e implementao de pedidos de
Mudana (RFC), o acompanhamento das metas relativas ao Gesto da
Mudana devem, idealmente, ser realizada utilizando qualquer ferramenta
Alterar Gesto est em uso (de preferncia, parte de um sistema integrado
Servio de Gesto de Ferramenta de apoio) e mudana telas de registro e
escalonamento processoes devem apoiar isso.
4.2.5.4 Intercalar, medir e melhorar a satisfao do cliente

H um nmero de importantes questes "soft" que no podem ser monitorados


por meio mecanicistas ou processual, tais como clientes sentimentos gerais
(estes no precisam necessariamente coincidir com o 'hard' monitoramento). Por
exemplo, mesmo quando houve uma srie de falhas de servio comunicados, os
clientes ainda podem sentir positivo sobre as coisas, porque eles podem se
sentir satisfeito de que as aes apropriadas esto sendo tomadas para
melhorar as coisas. Naturalmente, o oposto pode ser aplicvel, e clientes podem
se sentir insatisfeito com alguns problemas (por exemplo, o costume de alguns
funcionrios no Posto de Servio) quando as metas de SLA poucos ou nenhuns
foram quebrados.
Desde o incio, sbio para tentar gerenciar as expectativas dos clientes. Isso
significa definir expectativas adequadas e metas apropriadas, em primeiro lugar,
e colocando um processo sistemtico no local para gerenciar as expectativas
daqui para frente, como a satisfao = percepo - expectativa (onde uma
pontuao zero ou positivo indica um cliente satisfeito). SLAs so apenas
documentos, e em si no alterar significativamente a qualidade de servio sendo
fornecido (embora possam afetar o comportamento e ajudar a engendrar um
adequado cultura de servio, Que pode ter um efeito benfico imediato, e fazer
melhorias de longo prazo possvel). Um certo grau de pacincia , portanto,
necessria e deve ser construdo em expectativas.

ITIL V3 - Service Design - Pgina:

128 de 477

Quando as taxas esto sendo feitas para os servios 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 estratgia E ter autorizado oramento para, mas no mais.) Onde encargos directos no
so feitas, o apoio dos gerentes seniores devem ser recrutados para garantir
que as exigncias excessivas ou irrealista no so colocados no provedor de TI
por qualquer grupo individual do cliente.
Portanto, recomendvel que as tentativas de ser feito para monitorar a
percepo do cliente sobre estas questes suaves. Mtodos de fazer isso
incluem:

Questionrios peridicos e pesquisas com clientes


A opinio dos clientes a partir de reunies de avaliao de servios
O feedback dos Comentrios ps implementao (PIRs), realizado como
parte da Gesto da Mudana processo de grandes mudanas,
lanamentos, servios novos ou alterados, etc
Telefone pesquisas de percepo (talvez ao acaso no Service Desk, ou
usando representantes de ligao dos clientes regulares)
Satisfao apostilas de pesquisa (da esquerda com clientes, visitas
seguintes instalaes de servios, etc)
Grupo de usurios ou frum reunies
Anlise das reclamaes e elogios.

Sempre que possvel, deveriam ser fixados objectivos para estes e monitorados
como parte do SLA (por exemplo, uma pontuao mdia de 3,5 deve ser
alcanada pelo provedor de servios em resultados dados, com base em um
sistema de pontuao de 1 a 5, onde 1 pobre atuao e 5 excelente).
Garantir que, se usurios fornecer feedback que recebem algo em troca, e
demonstrar-lhes que seus comentrios foram incorporadas em um plano de
ao, talvez um SIP. Todas as medidas de satisfao dos clientes devem ser
revistos, e onde as variaes so identificados, eles devem ser analisados com
medidas tomadas para corrigir a variao.
4.2.5.5 Anlise e rever os acordos subjacentes e escopo de servios

Provedor de servios de TIs so dependentes em certa medida, o seu prprio


interno suporte tcnico equipes ou em parceiros externos ou fornecedors. Eles
no podem se comprometer com metas de SLA de reunio a menos que sua
prpria equipe de suporte e desempenho de fornecedores apoiar essas metas.
Contratos com fornecedores externos so obrigatrias, mas muitas
organizaes tambm identificaram os benefcios de ter acordos com simples
interna grupo de apoios, geralmente referidos como Olas. Determinao
acordos" um termo usado para se referir a todos OLAs sustentao, SLAs e
contratos.

ITIL V3 - Service Design - Pgina:

129 de 477

Muitas vezes, estes acordos so 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 esto alinhados com e apoio, metas acordadas com o
negcio em SLAs ou Olas. Pode haver vrias camadas de estas subjacentes ou
"back-to-back 'acordos com metas alinhadas. essencial que os alvos em cada
camada esto alinhadas com, e de apoio, os alvos contida dentro dos nveis
mais elevados (isto , os mais prximos das metas de negcios).
OLAs no precisa ser muito complicado, mas deve estabelecer metas
especficas de back-to-back para grupo de apoios que sustentam as metas
includas no SLAs. Por exemplo, se o SLA inclui o tempo global para responder
e fixar objectivos para incidentes (variando no prioridade os nveis), ento os
OLAs deve incluir alvos para cada um dos elementos da cadeia de suporte.
Deve ser entendido, contudo, que os objectivos inerentes de resoluo includos
no SLA no deve, normalmente, coincidir com os mesmos alvos includos em
contratos ou com olas fornecedors. Isto porque os alvos de SLA deve incluir
um elemento para todas as fases do ciclo de suporte (por exemplo, deteco
tempo, tempo de servio registro Secretria, escalada tempo, o tempo de
referncia entre grupos etc, reviso Service Desk e fecho tempo -, assim como o
tempo real, que fixa o falha).
A meta de SLA deve cobrir o tempo necessrio para atender as chamadas,
escalar incidentes suporte tcnico pessoal, e do tempo necessrio para comear
a investigar e resolver incidentes atribudos a eles. Alm disso, em geral horas
de suporte deve ser estipulado para todos os grupos que sustentam os tempos
disponibilidade de servio necessrios no SLA. Se especial procedimentos
existem para funcionrios contactados (por exemplo, o suporte por telefone forade-horas), estes tambm devem ser documentados.
OLAs devem ser monitorados contra alvos OLA e SLA e relatrios sobre as
realizaes previstas como feedback para os gerentes da apropriadas de cada
equipe de suporte. Isso destaca reas de problemas potenciais, que podem
precisar de ser abordados internamente ou por mais rever de SLA ou o OLA.
Sria considerao deve ser dada introduo OLAs formais para todas as
equipes de suporte interno, que contribuem para o apoio de operacional
servios.
Antes de cometer a SLAs nova ou revista, por isso importante que as actuais
disposies contratuais so investigadas e, se necessrio, atualizado. Esta
provavelmente a incorrer adicional custars, que deve ser absorvido pela TI ou
passado para o cliente. Neste ltimo caso, o cliente deve concordar com isso, ou
os alvos mais relaxado em contratos existentes devem ser acordados para
incluso em SLAs. Este atividade deve ser concludo em estreita consulta com o
Gesto de Fornecedores processo, para garantir no s que os requisitos sejam
cumpridos SLM, mas tambm que todos os requisitos de outros processos so
considerados, particularmente fornecedor e polticas contratuais e normas.

ITIL V3 - Service Design - Pgina:

130 de 477

4.2.5.6 servio relatrios Produzir

Imediatamente aps o SLA est acordado e aceite, o monitoramento deve ser


instigado, e os relatrios de realizao de servios devem ser produzidos.
Relatrios operacionais devem ser produzidos com freqncia (semanal - talvez
at com mais freqncia) e, sempre que possvel, relatrio de exceos deve
ser apresentado sempre que um SLA foi quebrado (ou ameaados, se for o caso
limiars foram criados para dar um "alerta precoce"). s vezes, encontrar
dificuldades no cumprimento das metas do novo servios durante o perodo
inicial de suporte de vida por causa do alto volume de RFCs. Limitar o nmero
de RFCs processados durante o perodo inicial de vida de suporte pode limitar a
impacto de mudars.
O SLA mecanismos de notificao, intervalos e formatos de relatrio devem ser
definidos e acordados com os clientes. A frequncia eo formato de reunies de
avaliao de servios tambm deve ser acordado com os clientes. Intervalos
regulares so recomendados, com relatrios peridicos sincronizados com o
ciclo de reviso.
Relatrios peridicos deve ser produzido e distribudo aos clientes (ou seus
representantes) e apropriados gerentes de TI de alguns dias de antecedncia
nvel de servio revises, de modo que quaisquer dvidas ou divergncias
podem ser resolvidas antes da reunio de avaliao. A reunio no ento
desviado por tais questes.
Os relatrios peridicos devem incorporar detalhes de desempenho em relao
a todas as metas de SLA, juntamente com detalhes de quaisquer tendncias ou
aes especficas que esto sendo tomadas para melhorar o servio qualidade.
Uma tcnica til consiste em incluir um SLA Monitoring grfico (SLAM) na parte
frontal de um relatrio de servio para dar uma "a-um-relance 'viso geral de
como as realizaes mediram-se contra alvos. Estes so mais eficazes se
codificados por cores (vermelho, laranja, verde, e algumas vezes referido como
grficos RAG como resultado). Outros relatrios intercalares pode ser exigido
por gerenciamento de TI para OLA ou interno atuao opinies e / ou fornecedor
ou gesto de contratos. Isto susceptvel de ser um processo evolutivo - um
primeiro esforo pouco provvel que seja o ltimo resultado.
O recursos necessrio para produzir e verificar relatrios no devem ser
subestimados. Ele pode ser extremamente demorado, e se os relatrios no
refletem a clientePrpria percepo da qualidade do servio de preciso, podem
piorar a situao. essencial que a informao correcta de todas as zonas e
todas processoes (por exemplo, Gerenciamento de Incidentes,Gerenciamento
de Problemas,Gerenciamento de Disponibilidade,Gerenciamento da
Capacidade, Mudana e Gerenciamento da Configurao) analisado e
compilados em um relatrio conciso e abrangente sobre o desempenho do
servio, medida contra alvos comerciais acordadas.

ITIL V3 - Service Design - Pgina:

131 de 477

SLM deve identificar as necessidades de informao especficas e automatizar a


produo dos relatrios, na medida do possvel. A medida, preciso e facilidade
com que os relatrios automatizados pode ser produzido deve fazer parte dos
critrios de seleco para as ferramentas de apoio integrados. Estes relatrios
de servios no s deve incluir detalhes sobre o desempenho atual contra alvos,
mas tambm deve fornecer informaes histricas sobre o desempenho
passado e as tendncias, de modo que o impacto das aes de melhoria pode
ser medido e previsto.
4.2.5.7 Conduta revises do servio e instigar melhorias dentro de um SIP geral

Reunies de avaliao peridica deve ser realizada em uma base regular com
os clientes (ou seus representantes) para analisar a realizao de servios no
ltimo perodo e para visualizar todas as questes para o prximo perodo.
normal para realizar tais reunies mensais ou, no mnimo, trimestrais.
As aes devem ser colocadas no cliente e fornecedor, conforme apropriado
para melhorar reas fracas que as metas no esto sendo atendidas. Todas as
aes devem ser ata, e os progressos devem ser revistas na prxima reunio
para garantir que os itens de ao esto sendo acompanhados e devidamente
executados.
Particular ateno deve ser focada em cada violao de nvel de servio para
determinar exatamente o que causou a perda de servio eo que pode ser feito
para evitar que se repitam. Se for decidido que o nvel de servio era, ou se
tornou, inatingvel, pode ser necessrio rever, renegociar, rever-acordar metas
de servios diferentes. Se a quebra de servio foi causado por uma falha de um
terceiro ou interno grupo de apoio, Tambm pode ser necessrio rever a base
acordo ou OLA. Anlise dos custos e do impacto das violaes de servio
fornece informaes valiosas e justificao das atividades SIP e aes. A
necessidade constante de melhoria precisa ser equilibrado e focado nas reas
com maior probabilidade de dar o benefcio maior de negcios.
Os relatrios devem tambm ser produzido sobre o progresso e sucesso da SIP,
como o nmero de aes SIP que foram concludas eo nmero de aes que
entregou seu benefcio esperado.
'Espio Um em ambos os campos "- Gestores de Nvel de Servio pode ser visto
com uma certa desconfiana tanto pela Provedor de servios de TI pessoal e os
representantes dos clientes. Isto devido a dupla natureza do trabalho, onde
eles esto atuando como um representante do cliente no-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
'oposio' ponto de vista em qualquer reunio etc Para evitar isso o Gerente de
Nvel de Servio deve ser to aberta e til quanto possvel (dentro dos limites de

ITIL V3 - Service Design - Pgina:

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 Reviso de SLAs, o escopo de servios 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
Mudana e Gerenciamento da Configurao controle e revistos periodicamente,
pelo menos anualmente, para garantir que eles ainda esto atual e abrangente,
e ainda esto alinhados com as necessidades do negcio e estratgia.
Estes revers deve garantir que os servios cobertos e as metas de cada ainda
so relevantes - e que nada de significativo mudou que invalida o acordo de
qualquer forma (isto deve incluir mudanas de infra-estrutura, mudanas
empresariais, fornecedor alteraes, etc.) Onde mudars so feitas, os acordos
devem ser atualizados em Gesto da Mudana controlar a refletir a nova
situao. Se todos os acordos so registados como IC dentro da CMS, mais
fcil avaliar o impacto e implementar as mudanas de uma maneira controlada.
Esses exames devem incluir tambm os documentos estratgia global, para
garantir que todos servios e contratos de servios so mantidos em linha com
os negcios e estratgias de TI e polticas.
4.2.5.9 Desenvolver contatos e relacionamentos

muito importante que SLM desenvolve a confiana e respeito com o negcio,


Especialmente com os contatos de negcios. Usando o Catlogo de Servios,
especialmente o elemento Negcios Catlogo de Servio do mesmo, permite
SLM ser muito mais pr-ativa. O Catlogo de Servios fornece a informao que
permite compreender o SLM relaos entre os servios e os unidade de
negcioss e de processos de negcios que dependem desses servios. Ela
tambm deve fornecer as informaes sobre todos os negcios chave e
contactos relacionados com os servios, a sua utilizao e sua importncia. 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 negcios e


usurios dos servios.
Ajudar com a manuteno de informaes precisas dentro do Portflio de
Servios e Catlogo de Servios.
Seja flexvel e sensvel s necessidades dos negcios, clientes e
usurios, e compreender atual e planejada nova processo de negcioes e
seus requisitos para servios novos ou modificados, documentao e
comunicao a esses requisitos a todos os outros processos, bem como
facilitar e mudana inovando sempre que h o benefcio do negcio.
Desenvolver uma compreenso completa do cliente de negcios, e
usurio estratgias, planos, necessidades de negcio e objetivos,

ITIL V3 - Service Design - Pgina:

133 de 477

garantindo que ele est trabalhando em parceria com a negcio, Clientes


e usurios, desenvolvendo relacionamentos de longo prazo.
Regularmente fazer a viagem do cliente e provar a experincia do cliente,
fornecendo feedback sobre os problemas dos clientes a ele. (Isto aplicase a ambos os clientes de TI e tambm os clientes externos de negcios,
no uso de De servios de TIs).
Garantir que os processos de relacionamento corretas esto no local para
alcanar os objetivos e que eles so submetidos a melhoria contnua.
Conduzir e concluir inquritos aos clientes, ajudar com a anlise dos
inquritos concludos e garantir que as aes so tomadas sobre os
resultados.
Atuar como um representante de TI na organizao e atendimento
usurio grupos.
Proativamente comercializar e explorar o Portflio de Servios e Catlogo
de Servios e a utilizao dos servios dentro de todas as reas do
negcio.
Trabalhar com a empresa, clientes e usurios para garantir que ele
fornece os nveis mais adequados de servio para atender s
necessidades de negcios atualmente e no futuro.
Promover a conscincia de servio e compreenso.
Aumentar a conscincia dos benefcios de negcios a ganhar com a
explorao de novas tecnologias.
Facilitar o desenvolvimento e negociao de SLRs adequados,
exequveis e realistas e SLAs entre o negcio e TI.
Assegurar o negcio, clientes e usurios a compreender suas
responsabilidades / compromissos de TI (ou seja, dependncias).
Ajudar com a manuteno de um registo de todas as melhorias
pendentes e melhorias.

4.2.5.10 Reclamaes e elogios

A SLM processo deve incluir tambm atividades e procedimentos para a


explorao e gesto de todas as reclamaes e elogios. Os procedimentos de
registo so geralmente realizadas pela central de servios que sejam anlogas
s de Gerenciamento de Incidentes e Cumprimento de Requisio. A definio
de uma reclamao e elogio devem ser acordados com os clientes, juntamente
com pontos de contacto e procedimentos acordados para a sua gesto e
anlise. Todas as reclamaes e elogios devem ser registradas e comunicadas
s partes interessadas. Todas as reclamaes tambm devem ser acionadas e
resolveu a satisfao do seu autor. Se no for, dever haver uma escalada
contato e procedimento para todas as queixas que no so acionadas e
resolveu dentro de um prazo adequado. Todas as reclamaes pendentes
devem ser revistos e encaminhado para a gerncia snior quando apropriado.
Os relatrios devem ser produzidos sobre os nmeros e tipos de reclamaes,
as tendncias identificadas e as medidas tomadas para reduzir os nmeros
recebidos. Relatos semelhantes tambm devem ser produzidos para elogios.

ITIL V3 - Service Design - Pgina:

134 de 477

4.2.6 Triggers, entradas, sadas e interfaces


H muitos gatilhos que instigam SLM atividade. Estes incluem:

Mudanas na Portflio de Servios, Como requisitos de negcios novos


ou modificados ou servios novos ou alterados
Acordos novos ou alterados, SLRs, ou SLAs, Olas contratos
Reunies de avaliao de servios e aes
Violaes de servios ou de violaes ameaadas
Elogios e reclamaes
Atividades peridicas, tais como a reviso de relatrios e pesquisas de
satisfao de clientes
Mudanas nas estratgia ou poltica.

4.2.6.1 processo entradas SLM

H um nmero de fontes de informao que so relevantes para o


Gerenciamento de Nvel de Servio processo. Estes devem incluir:

Informaes de negcios: a partir do organizaoEstratgia do negcio,


planos e planos financeiros e informaes sobre suas necessidades
atuais e futuras
Anlise de Impacto no Negcio: Fornecimento de informaes sobre a
impacto,prioridade, Risco e nmero de usurios associados com cada
servio
Requisitos de negcios: detalhes sobre qualquer acordados, os requisitos
de negcios novos ou alterados
As estratgias, polticas e restries de Estratgia de Servio
O Portflio de Servios e Catlogo de Servios
Alterar as informaes: a partir do Gesto da Mudana processo com um
cronograma para a frente das mudanas e uma necessidade de avaliar
todas as alteraes de seu impacto sobre todos os servios
CMS: que contm informaes sobre o relaos entre o servio de
negcios, o servios de apoios e a tecnologia
Cliente e usurio comentrios, reclamaes e elogios
Outros insumos: incluindo aconselhamento, informao 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
relatrios de servios passados no qualidade do servio prestado.

4.2.6.2 sadas processo SLM

As sadas dos Gerenciamento de Nvel de Servio deve incluir:

ITIL V3 - Service Design - Pgina:

135 de 477

Relatrios de servio: fornecer detalhes da nvel de servios alcanados


em relao s metas contidas dentro de SLAs. Estes relatrios devem
conter informaes sobre todos os aspectos do servio e de sua entrega,
incluindo a corrente e histrico atuao, Violaes e fracos, grandes
eventos, mudanas planejadas, atuais e previsto carga de trabalhos,
feedback de clientes e planos de melhoria e atividades
Plano de Melhoria de Servio (SIP): uma geral programa ou plano de
aes de melhoria priorizadas, abrangendo todos os servios e todos os
processos, juntamente com os impactos e riscos associados
O Plano de Qualidade de Servio: documentar e planejamento a melhoria
global da qualidade de servio
Modelos de documentos: padro documento modelos de formato e
contedo para SLAs, SLRs e Olas, alinhada com os padres corporativos
Acordo de Nvel de Servios (SLAs): um conjunto de metas e
responsabilidades devem ser documentadas e acordadas dentro de um
SLA para cada operacional servio
Exigncia de Nvel de Servios (SLR): um conjunto de metas e
responsabilidades devem ser documentadas e acordadas dentro de um
SLR para cada novo servio proposto ou alterados
Acordo de Nvel Operacionals (ANO): um conjunto de metas e
responsabilidades devem ser documentadas e acordadas dentro de um
OLA para cada equipe de suporte interno
Relatrios sobre Olas e subjacente contratos
Minutos de reviso de reunies e aes: todas as reunies devem ser
agendadas em uma base regular, com agendas programadas e suas
discusses e aes gravadas e progrediu
Reviso de SLA e servios escopo rever ata da reunio: resumir aes
acordadas e revisos ao escopo SLAs e servio
Revisado contratos: alteraes 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 mtricas podem ser usadas para julgar o
eficincia e eficcia das atividades SLM eo progresso da SIP. Essas mtricas
devem ser desenvolvidos a partir do servio ao cliente, e perspectiva de
negcios e deve abranger ambas as medies subjetivas e objetivas, tais como
o seguinte.
Objetivo:

Nmero ou percentagem de servio metas a ser cumpridas


Nmero e gravidade das violaes de servios
Nmero de servios com up-to-date SLAs

ITIL V3 - Service Design - Pgina:

136 de 477

Nmero de servios com relatrios oportunos e comentrios de servios


ativos.

Subjetiva:

Melhorias na satisfao do cliente.

Mais informaes sobre KPIs, medies e melhorias podem ser encontradas na


seo seguinte e na publicao contnua Melhoria de Servio.
No caia na armadilha de usar percentagens, a mtrica apenas. fcil de ser
pego quando h um pequeno sistema com pontos de medio limitada (ou seja,
um nico falha numa populao de 100 de apenas 1%, uma nica falha de
uma populao de 50 de 2% -, se o alvo de 98,5%, em seguida, a SLA j
quebrado). Sempre ir para o nmero de incidentes em vez de um percentual
sobre a populao de menos de 100, e ter cuidado quando as metas so
aceitos. Isso algo organizaos aprenderam da maneira mais difcil.
A SLM processo muitas vezes gera um bom ponto de partida para um SIP - eo
processo de reviso de servios pode conduzir este, mas todos os processos e
todas as reas da provedor de servios organizao deve ser envolvido na SIP.
Quando uma dificuldade subjacente foi identificado que est afetando
negativamente no servio qualidade, SLM deve, em conjunto com
Gerenciamento de Problemas e Gerenciamento de Disponibilidade, Instigar um
SIP para identificar e implementar as aces necessrias para superar as
dificuldades e restaurar qualidade do servio. Iniciativas SIP tambm podem se
concentrar em questes como usurio servio de formao e de testes e
documentao. Nestes casos, as pessoas relevantes precisam estar envolvidos
e retorno adequado dado a fazer melhorias para o futuro. A qualquer momento,
uma srie de iniciativas distintas que fazem parte do SIP pode ser executado em
paralelo para resolver dificuldades com uma srie de servios.
Algumas organizaes estabeleceram anual inicial oramento realizada pela
SLM de que iniciativas SIP pode ser financiado. Isto significa que a aco pode
ser efectuada rapidamente e que demonstravelmente efectiva SLM. Este
prtica 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 aes
de melhoria a ser avaliados para risco e impacto em servios, clientes e a
negcio, E ento priorizados, prevista e implementada.
Se uma organizao terceirizao sua prestao de servios a um terceiro, A
questo da melhoria do servio deve ser discutido no incio e coberto (e
oramentado para) na contrato, Caso contrrio, no h incentivo durante a
vigncia do contrato para o fornecedor para melhorar a metas de servio se eles

ITIL V3 - Service Design - Pgina:

137 de 477

j esto cumprimento das obrigaes contratuais e despesas adicionais


necessrio para fazer as melhorias.
4.2.7.1 KPIs

Gerenciar a qualidade geral do De servios de TI necessrio, tanto em nmero e


nvel de servios fornecidos e gerenciados:

Percentual de reduo nas metas de SLA perdeu


Percentual de reduo nas metas de SLA ameaado
Aumento percentual na percepo e satisfao do cliente de realizaes
de SLA, atravs de comentrios e respostas de servio Pesquisa de
Satisfao do Cliente
Reduo percentual em violaes de SLA causado por causa de
contratos de suporte de terceiros (subjacente contratos)
Reduo percentual em violaes de SLA causado por causa de internos
Acordos de Nvel Operacional (ANO).

Oferecer servios como anteriormente acordado a preos acessveis custars:

Nmero total e percentual de aumento em SLAs totalmente documentado


no lugar
Aumento percentual de SLAs acordados contra operacional servios que
esto sendo executados
Percentagem de reduo dos custos associados ao servio prviso
Percentagem de reduo do custo de monitoramento e relatrios de SLAs
Aumento percentual da velocidade e da elaborao e adopo de SLAs
apropriado
Frequncia de reunies de avaliao de servios.

Gerenciar interface de negcios:

Maior porcentagem de servios abrangidos por SLAs


Documentados e acordados processos de SLM e procedimentos esto
em vigor
Reduo do tempo necessrio para responder a pedidos de SLA e
implementar
Maior porcentagem de SLA revers concludas a tempo
Reduo no percentual de SLAs excelente para renegociao anual
Reduo da percentagem de SLAs requerendo mudanas de correco
(por exemplo, no tem como alvo atingvel; mudanas nos nveis de
utilizao). 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 nmero real de acordos
(consolidao e centralizao)

ITIL V3 - Service Design - Pgina:

138 de 477

Prova documental de que as questes levantadas no servio de opinies


e SLA esto sendo acompanhados e resolvidos
Reduo do nmero e gravidade das violaes de SLA
Eficaz de reviso e acompanhamento de todos os SLA, OLA e subjacente
contrato violaes.

4.2.8 Gesto da Informao


SLM fornece informaes importantes sobre todos os servios operacionais, os
seus objectivos esperados e as realizaes de servios e violaes de todos os
servios operacionais. Ela auxilia Gesto Catlogo de Servio com a gesto do
Catlogo de Servios e tambm fornece a informao e tendncias na
satisfao do cliente, incluindo suas reclamaes e elogios.
SLM crucial no fornecimento de informaes sobre a qualidade de De servios
de TI fornecida ao cliente, E informaes sobre a expectativa do cliente ea
percepo de que a qualidade do servio. Esta informao deve estar
amplamente disponveis para todas as reas do provedor de servios
organizao.

4.2.9 Desafios, Fatores Crticos de Sucesso e riscos


Um desafio enfrentado por SLM o de identificar os representantes dos clientes
adequados com quem negociar. Quem 'possui' a servio? Em alguns casos, isso
pode ser bvia, e um gerente nico cliente est disposto a agir como o signatrio
do acordo. Em outros casos, pode levar um pouco de negociao ou bajulando
para encontrar 'voluntrio' um representante (cuidado que os voluntrios muitas
vezes querem expressar seu prprio ponto de vista pessoal e no representam
um consenso geral), ou pode ser necessrio para obter todos os clientes para
assinar.
Se existem representantes dos clientes que so capazes de realmente
representar os pontos de vista da comunidade de clientes, pois eles
freqentemente se reunir com uma grande variedade de clientes, este o ideal.
Infelizmente, muitas vezes representantes so sede base e raramente entram
em contato com os clientes de servios genunos. No pior caso, SLM pode ter de
realizar seu / sua prpria programa de discusses e reunies com os clientes
para garantir verdadeiros requisitos so identificados.
Na negociao do atual e horas de suporte para um servio de grande porte,
uma organizao encontrada uma discrepncia no tempo necessrio de uso
entre a sede eo escritrio de campo clientes. Sede (com um nmero limitado
usurio populao) queria horas de servio cobrindo 8,00-18,00, enquanto o
escritrio de campo (com pelo menos 20 vezes o usurio populao) afirmou
que a partir de uma hora antes seria melhor - mas todos os escritrios fechados
ao pblico por 16,00, o mais tardar, e assim wouldn 't exigem um servio muito

ITIL V3 - Service Design - Pgina:

139 de 477

alm disso. Sede ganhou o argumento "poltico", e ento a banda 8,00-18,00 foi
definida. Quando o servio passou a ser usado (e, portanto, monitorado)
verificou-se que as extenses de servios eram geralmente solicitado pelo
escritrio de campo para cobrir a hora extra no perodo da manh, e os valores
reais de utilizao mostraram que o servio no havia sido acessada aps
17,00, exceto em ocasies muito raras. O Gerente de Nvel de Servio foi
responsabilizado pela equipe de TI para ter de cobrir uma tarde deslocar, E pelo
representante do cliente para carregamento por um servio que no foi utilizado
(ou seja, pessoal e custos de funcionamento).
Cuidados devem ser tomados ao abrir discusses sobre nvel de servios, pela
primeira vez, como provvel que 'problemas atuais "(a falha que ocorreu
ontem) ou de longa durao queixas (aquela impressora velha que temos vindo
a tentar obter substitudo por idades) so susceptveis de ser exibido no incio.
Importante ainda que estes possam ser, eles no devem ser autorizados a
entrar no caminho de estabelecer os requisitos de longo prazo. Esteja ciente, no
entanto, que pode ser necessrio para resolver quaisquer questes levantadas
no incio antes de ganhar alguma credibilidade para avanar.
Se no houve nenhuma experincia prvia de SLM, ento aconselhvel
comear com um projecto de SLA. A deciso deve ser tomada no qual o servio
ou os clientes esto a ser utilizados para o projecto. til se o cliente
selecionado entusiasta e deseja participar - talvez porque eles esto ansiosos
para ver melhorias na qualidade do servio. Os resultados de um levantamento
inicial do cliente a percepo pode dar dicas para um SLA projecto inicial
adequado.
No escolher uma rea onde existem grandes problemas como o SLA primeiro.
Tente escolher uma rea que tende a mostrar alguns benefcios rpidos e
desenvolver o processo de SLM. Nada encoraja a aceitao de uma nova idia
mais rpido do que o sucesso.
Uma dificuldade encontrada , por vezes, que o pessoal em diferentes nveis
dentro da comunidade cliente pode ter diferentes objetivos e percepes. Por
exemplo, um gerente snior raramente pode usar um servio e podem estar
mais interessados em questes como valor para o dinheiro e sada, enquanto
que um membro jnior do pessoal pode usar o servio durante todo o dia, e
podem estar mais interessados em questes como capacidade de
resposta,usabilidade e confiana. importante que todos os requisitos dos
clientes apropriados e relevantes, a todos os nveis, so identificadas e
incorporadas no SLA.
Alguns organizaos ter formado grupos focais de diferentes nveis 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 esforo.

ITIL V3 - Service Design - Pgina:

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 so realistas, viveis e acessveis. Se eles no
estiverem, as negociaes so necessrios at que um compromisso aceitvel
para todas as partes for acordado. Os pontos de vista de fornecedores tambm
devem ser procurados, bem como as implicaes contratuais devem ser levados
em conta durante a fase de negociao.
Caso no existam dados monitorados passado est disponvel, aconselhvel
deixar o acordo em formato de projecto por um perodo inicial, at
monitoramento pode confirmar que as metas iniciais so realizveis. Os alvos
podem ter de ser re-negociado, em alguns casos. Muitas organizaes negociar
um prazo acordado para a TI para negociar e criar uma linha de base para o
estabelecimento de metas de servio realistas. Quando as metas e os prazos
foram confirmados, os SLAs devem ser assinados.
Uma vez que o SLA inicial j foi concluda, e as dificuldades iniciais superar, em
seguida, seguir em frente e gradualmente introduzir SLAs para outros servios /
clientes. Se for decidido, desde o incio para ir para uma estrutura multi-nvel,
provvel que os problemas de nvel corporativo tm que ser cobertos para todos
os clientes no momento do SLA inicial. Tambm vale a pena experimentao as
questes corporativas durante esta fase inicial.
No v para alvos fceis no nvel corporativo. Podem ser fcil de alcanar, mas
no tm valor na melhoria do servio qualidade ou credibilidade. Alm disso, se
os objectivos so fixados a um nvel suficientemente elevado, o SLA corporativo
pode ser usado como o padro que todos os novos servios devem alcanar.
Um ponto para garantir que no final do processo de elaborao e negociao,
o SLA realmente assinado pelos gerentes apropriados para o cliente e
Provedor de servios 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 signatrios esto dentro de suas respectivas
organizaes, a mais forte mensagem de compromisso. Uma vez que um SLA
acordado, ampla publicidade precisa ser usado para garantir que os clientes,
usurios e equipe de TI so igualmente conhecimento da sua existncia e dos
objectivos-chave.
Devem ser tomadas medidas para anunciar a existncia 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 exibio em reas de suporte, de modo que os
funcionrios esto sempre cientes dos objectivos a que eles esto trabalhando.
Se as ferramentas de apoio permitem, essas metas devem ser registrados
dentro das ferramentas, como dentro de um Catlogo de Servios ou CMS, de

ITIL V3 - Service Design - Pgina:

141 de 477

modo que o seu contedo pode ser amplamente divulgado a todos os


funcionrios. Eles tambm devem ser includos como limiars, e automaticamente
alertado contra quando um alvo ameaado ou violado, na verdade. SLAs,
OLAs e as metas que eles contm tambm deve ser divulgado entre os usurio
comunidade, de modo que os usurios esto cientes do que eles podem esperar
dos servios que utilizam, e saber em que ponto de comear a expressar
insatisfao.
importante que a equipe de Service Desk esto comprometidos com a SLM
processo, E tornar-se embaixadores pr-ativas para SLAs, abraando o
necessrio cultura de servio, Pois eles so o primeiro ponto de contato para
incidentes de clientes, reclamaes e consultas. Se a equipe de Service Desk
no esto plenamente conscientes de SLAs no lugar, e no agir de acordo com
seu contedo, os clientes muito rapidamente perder a f em SLAs.
4.2.9.1 Fatores Crticos de Sucesso

O principal Fator Crtico de Sucessos para o processo de Gerenciamento de


Nvel de Servio so:

Gerenciar a qualidade geral do De servios de TIs exigido


Entregar o servio como previamente acordado a preos acessveis
custars
Gerenciar a interface com o negcio e usurios.

Os riscos associados com respeito proviso de um preciso Catlogo de


Servios so os seguintes:

A falta de entrada precisos, envolvimento e comprometimento com o


negcio e clientes
As ferramentas e recursos obrigados a concordar, o documento, monitor
relatrio, e os acordos de reviso e nvel de servios
O processo torna-se um processo burocrtico e administrativo, em vez de
um processo ativo e pr-ativa entregando benefcio mensurvel para o
negcio
O acesso e apoio do CMS adequado e up-to-date e SKMS
Ignorando o uso dos processos de SLM
Medidas de negcios e de clientes so muito difceis de medir e melhorar,
por isso no so registradas
Negcio inadequado e contatos de clientes e relaos so desenvolvidos
Altas expectativas dos clientes e baixa percepo
A comunicao deficiente e inadequado obtida com o negcio e
clientes.

ITIL V3 - Service Design - Pgina:

142 de 477

4,3 Gerenciamento da Capacidade


Gerenciamento da Capacidade um processo que se estende por todo o ciclo
de vida de servio. Um fator-chave de sucesso na gesto de capacidade
garantir que considerado durante o projeto fase. por esta razo que o
processo de gesto de capacidade includa na presente publicao.
Gerenciamento da Capacidade apoiado inicialmente em Estratgia de Servio
onde as decises e anlise de requisitos de negcio e resultados dos clientes
influenciar o desenvolvimento de padres de atividade de negcio (PBA), nveis
de servio (LOS) e pacote de nvel de servios (PLSs). Isto fornece os
indicadores de capacidade de previso e permanente necessrios para alinhar a
capacidade de demanda.

Finalidade 4.3.1 meta / / objetivo


"O objetivo do processo de Gerenciamento da Capacidade garantir que custo
justificvel de capacidade de TI em todas as reas de TI sempre existe e
adaptado s necessidades atuais e futuras acordadas do negcio, em tempo
hbil".

O objetivo do Gerenciamento da Capacidade de fornecer um ponto de foco e


de gesto para toda a capacidade e problemas relacionados ao desempenho,
relativos a ambos os servios e recursos.
O objetivos de Gerenciamento da Capacidade so:

Produzir e manter uma adequada e up-to-date Plano de capacidade, Que


reflete as necessidades atuais e futuras do negcio
Prestar assessoria e orientao para todas as outras reas de negcio e
de TI em todas as capacidades e problemas relacionados ao
desempenho
Garantir que o servio atuao realizaes atender ou exceder todas as
suas metas de desempenho acordadas, atravs da gesto do
desempenho e da capacidade de ambos os servios e recursos
Auxiliar no diagnstico e resoluo de desempenho e capacidade de
incidentes relacionados e problemas
Avaliar a impacto de todas as alteraes no plano de capacidade, e do
desempenho e da capacidade de todos os servios e recursos
Assegurar que as medidas pr-ativas para melhorar o desempenho dos
servios so implementados onde quer que seja de custo justificvel 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. Funes de tecnologia de
gesto, tais como suporte de rede, suporte do servidor ou Gesto de Operao

ITIL V3 - Service Design - Pgina:

143 de 477

pode realizar a maior parte do dia-a-dia operacional funes, mas ir fornecer


informaes 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 tambm deve considerar o espao planejamento
e sistemas ambientais capacidade bem como certos aspectos de recursos
humanos, mas apenas onde a falta de recursos humanos pode resultar em uma
violao do SLA ou OLA alvos, um atraso no desempenho final-de-final ou
servio tempo de resposta, Ou uma incapacidade para cumprir os compromissos
e planos futuros (por exemplo, dados durante a noite apoios no concludo a
tempo, porque no estavam presentes operadores de carregar fitas).
Em geral, a gesto de recursos humanos uma responsabilidade de gesto da
linha, embora o pessoal de um Service Desk deve usar idntico Gerenciamento
da Capacidade tcnicas. O agendamento de recursos humanos, os nveis de
pessoal, os nveis de habilidade e capacidade nveis devem, por conseguinte,
ser includos dentro do escopo de Gerenciamento da Capacidade. A fora motriz
para Gerenciamento da Capacidade devem ser os requisitos de negcio da
organizao e planejar os recursos necessrios para fornecer nvel de servios,
de acordo com os SLAs e Olas. Gerenciamento da Capacidade precisa entender
de TI total e ambientes de negcios, incluindo:

O negcio atual operao e suas necessidades, atravs dos padres de


actividade
Os futuros planos de negcio e requisitos atravs da Portflio de Servios
As metas de servio e da corrente Operao de Servio de TI embora
SLAs e Procedimentos Operacionais Padro
Todas as reas da tecnologia da informao e de sua capacidade e
desempenho, incluindo infra-estrutura, dados, ambiente e aplicaos.

Entender tudo isso vai permitir Gerenciamento da Capacidade para garantir que
toda a capacidade atual e futura e atuao aspectos servios so fornecidos de
forma rentvel.
Gerenciamento da Capacidade tambm sobre a compreenso do potencial
para o fornecimento de novos servios. Nova tecnologia precisa ser entendida e,
se for o caso, usado para inovar e realizar os servios requeridos pelo cliente.
Gerenciamento da Capacidade precisa reconhecer que a taxa de mudana
tecnolgica vai provavelmente aumentar e que a nova tecnologia deve ser
aproveitada para assegurar que os servios de TI continuar a satisfazer as
expectativas de negcios em mudana. Um link direto para a Estratgia de
Servio e Portflio de Servios necessria para assegurar que as tecnologias
emergentes so considerados no planejamento futuro servio.
O Gerenciamento da Capacidade processo deve incluir:

ITIL V3 - Service Design - Pgina:

144 de 477

Monitoramento padres de atividade de negcio e de nvel de servio,


atravs de planos de utilizao, desempenho e rendimento de servios de
TI e infra-estrutura de apoio, ambientais, de dados e aplicaes
componentes e a produo de relatrios de regular e ad hoc em servio e
a capacidade do componente e desempenho
Empresa afinao atividades para tornar mais eficiente o uso de recursos
de TI existentes
Entender as demandas acordadas atuais e futuros que esto sendo feitas
pelo cliente para recursos de TI, e produzir previses para necessidades
futuras
Influenciar Gerenciamento da Demanda, Talvez em conjunto com a
gesto financeira
Produzir um plano de capacidade que permite a provedor de servios
para continuar a prestar servios da qualidade definida em SLAs e que
abrange um perodo de tempo suficiente para atender o planejamento
futuro nvel de servios exigido, tal como definido na Portflio de Servios
e SLRs
Assistncia com a identificao e resoluo de quaisquer incidentes e
problemas associados com o servio ou componente atuao
A melhoria pr-ativa de servio ou o desempenho dos componentes onde
quer que seja justificvel custo e atende s necessidades do negcio.

Gerenciando o capacidade da grande distribuio Infra-estrutura de TIs uma


tarefa complexa e exigente, especialmente quando a capacidade de TI eo
investimento financeiro necessrio cada vez maior. Portanto, faz ainda mais
sentido para planejar o crescimento. Enquanto o custar da atualizao de um
componente individual em um ambiente distribudo geralmente menor do que a
atualizao para um componente em um ambiente de mainframe, muitas vezes
h muitos componentes mais no ambiente distribudo que precisam ser
atualizados. Tambm no 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 Portflio de Servios e contratos processo para assegurar que as
melhores ofertas com fornecedors so negociados.
Gerenciamento da Capacidade fornece as informaes necessrias sobre atual
e planejada recurso utilizao de componentes individuais para permitir s
organizaes decidir, com confiana:

Quais componentes para upgrade (ou seja, mais memria, dispositivos de


armazenamento mais rpido, processadores mais rpidos, maior largura
de banda)
Quando a atualizao - idealmente, esta no cedo demais, resultando
em excesso de capacidade caro, nem demasiado tarde, deixando de
aproveitar os avanos em novas tecnologias, resultando em gargalos,

ITIL V3 - Service Design - Pgina:

145 de 477

desempenho inconsistente e, em ltima anlise, insatisfao dos clientes


e perda de oportunidades de negcios
Quanto a atualizao vai custar - a previso e elementos de planejamento
de Gerenciamento da Capacidade alimentar em ciclos oramentais,
garantindo investimento previsto.

Muitos dos outros processos so menos eficazes se no houver entrada de los


do processo de Gerenciamento da Capacidade. Por exemplo:

Pode o Gesto da Mudana processo de avaliar adequadamente o efeito


de qualquer mudar na capacidade disponvel?
Quando um novo servio implementado, o processo pode ser SLM
certeza de que as SLRs do novo servio so realizveis, e que os SLAs
de servios existentes no sero afetados?
Pode o Gerenciamento de Problemas processo de diagnosticar
corretamente a causa de incidentes causados pela baixa atuao?
Pode o Continuidade do Servio de TI processo determinar com preciso
as necessidades de capacidade dos principais processos de negcios?

Gerenciamento da Capacidade um dos processos de previso que, quando


bem conduzida, pode prever eventos empresariais e impactos, muitas vezes
antes que eles aconteam. Gerenciamento da Capacidade bom garante que no
h surpresas em relao ao servio e componente projeto e desempenho.
Gerenciamento da Capacidade tem uma estreita, de mo dupla relao com a
Estratgia de Servio e planejamento processos dentro de uma organizao. Em
uma base regular, a longo prazo estratgia de uma organizao encapsulado
em uma atualizao dos planos de negcios. O Estratgia de Servio refletir os
planos de negcios e estratgia, Que so desenvolvidos a partir de
entendimento da organizao dos fatores externos, como o mercado
competitivo, perspectivas econmicas e legislao, e sua interna capacidade em
termos de mo de obra capacidade de entrega, etc Muitas vezes, um prazo mais
curto ttico planoOu plano de mudana de negcios desenvolvido para
implementar as mudanas necessrias no curto e mdio prazo para o progresso
do plano de negcios global e Estratgia de Servio. Gerenciamento da
Capacidade precisa entender os planos de curto, mdio e longo prazo da
negcio ao fornecer a informao sobre as ltimas idias, tendncias e
tecnologias sendo desenvolvidas pelo fornecedors de hardware de computao
e software.
O negcio da organizao planeja dirigir o Estratgia de Servio de TI
especficas, cujo contedo Gerenciamento da Capacidade precisa estar
familiarizado com, e para o qual precisa de Gerenciamento da Capacidade de
ter tido significativa e permanente nvel input.The direito de capacidade no
momento certo fundamental. Planos de estratgia de servio ser til para o

ITIL V3 - Service Design - Pgina:

146 de 477

planejamento de capacidade, identificando o tempo para aquisio e


implementao de novas tecnologias, hardware e software.

4.3.3 Valor para o negcio


Gerenciamento da Capacidade responsvel por garantir que os recursos de TI
so planejadas e programadas para fornecer um nvel de servio consistente
que corresponde s necessidades atuais e futuras do negcio, 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 necessrios
para apoiar o plano de negcios, juntamente com uma justificao custo do que
as despesas.

4.3.4 Polticas / princpios / conceitos bsicos


Gesto da Capacidade garante que o capacidade e o desempenho da De
servios de TIs sistemas e corresponda s exigncias acordadas evoluo do
negcio da forma mais eficaz e oportuna. Gerenciamento da Capacidade
essencialmente um ato de equilbrio:

Balanceamento condenao recursos necessrios: a necessidade de


garantir que a capacidade de processamento que comprado de custo
justificvel em termos de necessidade de negcio, ea necessidade de se
fazer o uso mais eficiente desses recursos.
Equilbrio entre a oferta em relao demanda: A necessidade de
garantir que a oferta disponvel de TI poder de processamento
corresponda s exigncias feitas sobre o assunto pela empresa, agora e
no futuro. Tambm pode ser necessrio para controlar ou influenciar a
procura de um determinado recurso.

Processos de capacidade de gesto e de planejamento devem estar envolvidos


em todas as etapas do servio Ciclo de Vida de Estratgia e Projeto, Atravs
Transio e Operao de Melhoria. A partir de um estratgico perspectiva, o
Portflio de Servios contm os recursos de TI e capacidades. O advento da
Arquitetura Orientada a Servios, virtualizao eo uso de rede de valors em
servio de TI prviso so fatores importantes para a gesto da capacidade. A
capacidade adequada e desempenho devem ser projetados para servios e
componentes, desde as fases iniciais do projeto. Isto assegurar no apenas
que o atuao de qualquer servio novo ou alterado cumpra suas metas
esperados, mas tambm que todos os servios existentes continuam a cumprir
todos os seus objectivos. Esta a base da pr servio estvelviso.
O Gerenciamento da Capacidade geral processo est continuamente
procurando custo-benefcio para combinar com TI recursos e capacidade para
as necessidades em constante mudana e os requisitos do negcio. Isto exige

ITIL V3 - Service Design - Pgina:

147 de 477

que o afinao e otimizao dos recursos existentes ea eficcia estimativa e


planeamento dos recursos futuros, como ilustrado na Figura 4.8.

Figura 4.8 O processo de Gerenciamento da Capacidade

Gesto da Capacidade uma tcnica extremamente processo complexo e


exigente e, a fim de alcanar resultados, ela exige trs sub-processos de apoio.
Uma das principais atividades de Gerenciamento da Capacidade produzir um
plano que documenta os nveis atuais de utilizao de recursos e desempenho
do servio e, aps anlise do Estratgia de Servio e planos, prev os requisitos
futuros para novos recursos de TI para suportar os servios de TI que sustentam
as atividades empresariais. O plano deve indicar claramente quaisquer
suposies feitas. Ele tambm deve incluir todas as recomendaes
quantificados em termos de recursos necessrios, custos, benefcios, impacto,
etc
A produo e manuteno 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 negcio ou oramento
ciclo de vida, e concluda antes do incio das negociaes sobre os oramentos
futuros. A re-edio trimestral do plano actualizado pode ser necessrio levar em
conta mudanas em planos de servio, para informar sobre a preciso das
previses e fazer recomendaes ou refinar. Isso exige esforo extra, mas, se

ITIL V3 - Service Design - Pgina:

148 de 477

ele atualizado regularmente, o Plano de Capacidade mais provvel que seja


preciso e para refletir a necessidade de negcio em mudana.
Os contedos tpicos de um plano de capacidade so descritos no Apndice J.
4.3.4.1 Gerenciamento da Capacidade de Negcios

Este sub-processo traduz as necessidades de negcios e planos em requisitos


de servio e infraestrutura de TI, garantindo que os requisitos de negcios
futuros para os servios de TI so quantificados, concebido, planejado e
implementado em tempo hbil. Isto pode ser conseguido utilizando os dados
existentes sobre a utilizao dos recursos de corrente pelas vrias servios e
recursos para a tendncia, a previso do modelo, ou prever necessidades
futuras. Estes requisitos futuros provenientes do Estratgia de Servio e Portflio
de Servios detalhando novos processos e exigncias de servio, mudanas,
melhorias, e tambm o crescimento nos servios existentes.
4.3.4.2 Gerenciamento da Capacidade Servio

O foco deste sub-processo a gesto, controlar e previso do desempenho fima-fim e capacidade do vivo, operacional De servios de TIs de uso e carga de
trabalhos. Ele garante que o desempenho de todos os servios, conforme
detalhado nas metas de servios dentro de SLAs e SLRs, monitorado e
medido, e que os dados coletados so registrados, analisados e relatados. Onde
quer que as medidas necessrias, pr-ativa e reativa deve ser iniciada, para
garantir que o atuao de todos os servios atenda s suas metas de negcios
acordados. Isto realizado por uma equipe com conhecimento de todas as
reas de tecnologia utilizada na entrega de fim-a-fim do servio, e muitas vezes
envolve o conselho busca dos especialistas envolvidos na Gesto da
Capacidade de componentes. Sempre que possvel, automatizado limiars deve
ser usado para gerenciar todos os servios operacionais, para garantir que as
situaes em que as metas de servio so violados ou ameaados so
rapidamente identificados e custo-efetivas aes para reduzir ou evitar o seu
potencial impacto implementadas.
4.3.4.3 Gerenciamento da Capacidade Componente

O foco neste sub-processo a gesto, controle e previso do desempenho,


utilizao e capacidade da tecnologia de TI indivduo componentes. Ele garante
que todos os componentes dentro da infra-estrutura de TI que tm recurso finito
so monitorados e medidos, e que os dados coletados so registrados,
analisados e relatados. Mais uma vez, sempre que possvel, os limiares
automatizados devem ser implementadas para gerenciar todos os componentes,
para garantir que as situaes em que as metas de servio so violados ou
ameaados pelo uso de componentes ou de desempenho so rapidamente
identificados, e custo-efetivas aes para reduzir ou evitar o seu impacto
potencial so implementadas.
ITIL V3 - Service Design - Pgina:

149 de 477

H muitas atividades semelhantes que so executadas por cada um dos subprocessos acima, mas cada sub-processo tem um foco muito diferente.
Gerenciamento da Capacidade de negcios focado nas necessidades de
negcios atuais e futuras, enquanto Gerenciamento da Capacidade de servio
concentra-se na entrega dos servios existentes que suportam o negcioE
Gesto da Capacidade de componentes focado no Infra-estrutura de TI que
sustenta o servio proviso. O papel que cada um destes sub-processos
desempenha no global processo e o uso de ferramentas de gesto 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 organizao"Arquitetura de gerenciamento de s e
integrar com outras ferramentas utilizadas para a gesto de sistemas de TI e
automatizar os processos de TI. O monitoramento e atividades de controle
dentro Operao de Servio ir fornecer uma boa base para as ferramentas de
apoio e analisar informaes para Gerenciamento da Capacidade.

ITIL V3 - Service Design - Pgina:

150 de 477

4.3.5 as atividades de processo, mtodos e tcnicas


Algumas atividades do processo de Gerenciamento da Capacidade so reativas,
enquanto outros so pr-ativa. As atividades pr-ativas de Gerenciamento da
Capacidade deve incluir:

Antecipar problemas de desempenho, tomando as aes necessrias


antes que eles ocorram
Tendncias produtoras do atual componente utilizao e estimar as
necessidades futuras, usando as tendncias e limiars para atualizaes
de planejamento e melhorias
Modelagem e tendncias das mudanas previstas nos servios de TI, e
identificar as mudanas que precisam ser feitas para servios e
componentes da infra-estrutura de TI e aplicaos para assegurar que
apropriado recurso est disponvel
Garantir que as atualizaes esto orados, planejados e implementados
antes de SLAs e metas de servio sejam violados ou atuao problemas
ocorrem
Buscando ativamente para melhorar o desempenho do servio onde quer
que seja custo-justificvel
Afinao e otimizar o desempenho dos servios e componentes.

As atividades reativas de Gerenciamento da Capacidade deve incluir:

Monitoramento, medio, relatrio e analisar o desempenho atual de


ambos os servios e componentes
Respondendo a todos "capacidade relacionadalimiar'Eventos e aes
corretivas instigante
Reagindo a e ajudando com problemas de desempenho especficos. Por
exemplo, o Service Desk pode referir-se incidentes de mau desempenho
para Gesto de Tecnologia, que vai empregar Gerenciamento da
Capacidade tcnicas para resolv-los.

A mais bem sucedida das atividades proativas e preditivas de gesto da


capacidade, menos necessidade haver para as atividades reativas de
Gerenciamento da Capacidade.
4.3.5.1 Gerenciamento da Capacidade de Negcios

O principal objetivo do Gerenciamento da Capacidade de negcios sub-processo


assegurar que os futuros requisitos de negcios (cliente resultados) para os
servios de TI so consideradas e compreendidas, e que suficiente TI
capacidade para suportar todos os servios novos ou alterados planejado e
implementado em um prazo adequado. Figura 4.10 ilustra que o BCM
influenciada pelos padres de atividade de negcio e como os servios so
utilizados.

ITIL V3 - Service Design - Pgina:

151 de 477

Capacidade figura 4.10 deve suportar os requisitos de negcios

O Gerenciamento da Capacidade processo deve ser sensvel a mudanas nos


requisitos para a demanda de capacidade. Novos servios ou servios alterados
sero necessrias para sustentar o negcio em mudana. Servios existentes
exigir modificaes para fornecer funcionalidade extra. Servios de idade vai se
tornar obsoleto, liberando capacidade de reposio. Como resultado, a
capacidade para satisfazer o clienteSLRs s 'e SLAs sero afetados. da
responsabilidade do Gerenciamento da Capacidade de prever a demanda por
capacidade para tais mudanas e gerenciar a demanda.
Estas novas exigncias podem vir a ateno de Gesto da Capacidade de
muitas fontes diferentes e por muitas razes diferentes, mas as principais fontes
de abastecimento deve ser o Padro de Atividade de Negcios de
Gerenciamento da Demanda e a Pacote de Nvel de Servios produzidas pela
Portflio de Servios. Estes indicam uma janela de preditores futuros de
capacidade. Tais exemplos poderiam ser uma recomendao para atualizar para
tirar proveito da nova tecnologia, ou a aplicao de um afinao atividade para
resolver um atuao problema. Figura 4.11 mostra o ciclo da gesto da procura.

ITIL V3 - Service Design - Pgina:

152 de 477

Figura Gerenciamento da Capacidade 4,11 toma nota do padro de demanda

Gesto de capacidade tem de ser includo em todos estratgico,planejamento e


as atividades do projeto, que est sendo envolvido to cedo quanto possvel
dentro de cada processo, Tais como:

Assistncia e apoio a desenvolvimento de Estratgia de Servio


Envolvimento na reviso e melhoria de estratgias de TI e polticas
Envolvimento na reviso e melhoria de arquiteturas de tecnologia.

Gesto de capacidade no deve ser uma de ltima hora 'carrapato na caixa


pouco antes da aceitao do cliente e operacional aceitao.
Se o envolvimento precoce pode ser alcanado a partir de Gesto de
Capacidade dentro desses processos, o planejamento e projeto de capacidade
de TI pode ser estreitamente alinhados com os requisitos de negcio e pode
garantir que servio metas podem ser alcanadas e mantidas.
Auxiliar em concordar Requisitos de Nvel de Servio
Gerenciamento da Capacidade deve ajudar na compreenso da SLM clientes '
capacidade e requisitos de desempenho, em termos de servio requerido /
sistema tempo de respostas, esperado rendimento, Os padres de uso e volume
de usurios. Gerenciamento da Capacidade deve ajudar no processo de
negociao, oferecendo solues possveis para um nmero de cenrios. Por
exemplo, se o volume de usurios menor do que 2,000, ento os tempos de
resposta podem ser garantidos para ser inferior a dois segundos. Se mais de
2.000 usurios se conectam ao mesmo tempo, ento a largura de banda extra
necessrio para garantir o tempo de resposta requerido, ou um tempo de
ITIL V3 - Service Design - Pgina:

153 de 477

resposta mais lento ter que ser aceite. Modelagem, tendncias ou aplicao
dimensionamento tcnicas so frequentemente utilizados aqui para garantir que
as previses refletem exatamente a situao real.
Adquirir o projeto, ou alterar a configurao de servios
Gerenciamento da Capacidade devem ser envolvidos na concepo de novos
servios ou mudana e fazer recomendaes para a aquisio de hardware e
software, onde o desempenho e / ou capacidade so fatores. Em alguns casos,
Gerenciamento da Capacidade instiga a implementao do novo exigncia
atravs Gesto da Mudana, Onde est tambm envolvida como um membro do
Conselho Change Advisory. No interesse de balanceamento custar e
capacidade, o Gerenciamento da Capacidade processo obtm os custos de
solues alternativas propostas e recomenda a mais adequada soluo de custo
eficaz.
Verifique SLA
O SLA deve incluir detalhes sobre o servio antecipado rendimentos e os
requisitos de desempenho. Gerenciamento da Capacidade informa SLM em
metas realizveis que podem ser monitorados e em que a Design de Servios
tem sido baseada. Confiana de que o Design de Servios ir atender as SLRs e
fornecer a capacidade de crescimento futuro pode ser adquirida por meio
modelagem, Dimensionamento de tendncias ou tcnicas.
Negociao SLA apoio
Os resultados das tcnicas preditivas fornecer o verificao de capacidades de
desempenho de servio. Pode haver uma necessidade de SLM renegociar SLAs
com base nestes resultados. Gerenciamento da Capacidade fornece suporte
para SLM deve renegociaes ser necessrio, recomendando solues
potenciais e informaes de custo associado. Uma vez assegurado que os
requisitos so realizveis, que de responsabilidade do SLM para acordar a
nvel de servios e assinar o SLA.
Controle e implementao
Todos mudars para servio e recurso capacidade deve seguir todos os
processos de TI, tais como Gesto da Mudana, de Lanamento de
Configurao, e do Projeto para garantir que grau o direito de controlar e
coordenao est no lugar em todas as alteraes e que qualquer novo ou
alterao componentes so registrados e monitorados por meio de sua ciclo de
vida.
4.3.5.2 Gerenciamento da Capacidade Servio

ITIL V3 - Service Design - Pgina:

154 de 477

O principal objetivo do Gerenciamento da Capacidade de servio sub-processo


identificar e compreender o De servios de TIs, o seu uso de recursos, os
padres de trabalho, os picos e as depresses, e para assegurar que o servios
cumprir as metas de SLA, ou seja, para garantir que os servios de TI executem
conforme necessrio. Neste sub-processo, o foco na gesto de servios
atuao, Como determinado pelas metas contidas no SLAs acordados ou SLRs.
O Servio de Gerenciamento da Capacidade sub-processo garante que os
servios atendam s metas de servio acordados capacidade. O servio
monitorado fornece dados que podem identificar as tendncias a partir do qual
normais nvel de servios pode ser estabelecido. Por regular monitoramento e
comparao com esses nveis, condies de exceo pode ser definido,
identificados e relatados. Portanto Gerenciamento da Capacidade informa SLM
de quaisquer violaes de servios ou quase.
Haver ocasies em que incidentes e problemas so chamados de
Gerenciamento da Capacidade de outros processoes, ou identifica-se que um
servio poderia deixar de cumprir suas metas de SLA. Em algumas dessas
ocasies, a causa do potencial falha no pode ser resolvido por Gerenciamento
da Capacidade componente. Por exemplo, quando a falha analisada pode ser
encontrado que no h falta de capacidade, Ou nenhum componente individual
super-utilizados. No entanto, se o projeto ou codificao de um aplicao
ineficiente, ento o desempenho de rede poder ter de ser gerido, bem como de
hardware individual ou recursos de software. Gerenciamento da Capacidade de
servio tambm deve estar monitorando servio carga de trabalhos e transaos
para garantir que eles permanecem dentro dos limites acordados e limiars.
A chave para uma gesto de sucesso Servio capacidade de prever
problemas, sempre que possvel, atravs do monitoramento mudanas no
desempenho e acompanhamento da impacto de mudanas. Portanto, este um
outro sub-processo que tem de ser proativo e preditivo, mesmo preventiva, ao
invs de reativo. No entanto, h momentos em que necessrio reagir a
problemas de desempenho especficos. A partir de um conhecimento e
entendimento dos requisitos de desempenho de cada um dos servios que esto
sendo utilizados, os efeitos de mudanas no uso dos servios pode ser
estimado, e as medidas tomadas para garantir que o desempenho do servio
requerido pode ser alcanado.
4.3.5.3 Gerenciamento da Capacidade Componente

O objetivo principal do Gerenciamento da Capacidade componente (CCM)


identificar e compreender o desempenho, capacidade e utilizao de cada um
dos indivduos componentes no mbito da tecnologia utilizada para apoiar o De
servios de TIs, incluindo a infra-estrutura, ambiente, Dados e aplicaos. Isto
assegura a melhor utilizao possvel da corrente de hardware e recursos de
software, a fim de alcanar e manter o acordado nvel de servios. Todos os

ITIL V3 - Service Design - Pgina:

155 de 477

componentes de hardware e componentes de software muitos na infra-estrutura


de TI tm uma capacidade finita de que, quando se aproximou ou ultrapassado,
tem o potencial de causar problemas de desempenho.
Este sub-processo est preocupado com componentes como processadores,
memria, discos, largura de banda de rede, conexes de rede etc Ento,
informaes sobre a utilizao dos recursos tm de ser recolhidos em uma base
contnua. Monitores deve ser instalado no hardware individual e os componentes
de software e, em seguida, configurada para recolher os dados necessrios, o
que acumulado e armazenado durante um perodo de tempo. Trata-se de um
atividade geralmente levada a cabo atravs monitoramento e controlar dentro
Operao de Servio. Um feedback direto ao CCM deve ser aplicado dentro
deste sub-processo.
Como em Gerenciamento da Capacidade de servio, A chave para o sucesso
CCM a previso questes, sempre que possvel, e, portanto, tem que ser prativa e preditiva. No entanto, h ocasies em que CCM tem que reagir a
problemas especficos que so causadas por uma falta de capacidade, ou a
utilizao ineficiente do componente. A partir de um conhecimento e
compreenso do uso dos recursos por cada um dos servios que esto sendo
executados, os efeitos de mudanas no uso dos servios pode ser estimada e
hardware ou atualizaes de software pode ser orado e planejado. Como
alternativa, os servios 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 seo so necessrios 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 diferena entre os sub-processos est nos dados que esto sendo
monitorados e coletados, ea perspectiva de que analisado. Por exemplo, o
nvel de utilizao dos componentes individuais no infra-estruturas - tais como
processadores, discos e as ligaes de rede - de interesse em Gerenciamento
da Capacidade componente, Enquanto que a operao rendimento taxas e
tempo de respostas so de interesse em Gerenciamento da Capacidade de
servio. Para Gerenciamento da Capacidade de negcios, As taxas de
transao de transferncia para a necessidade do servio online a ser traduzido
em volumes de negcios - por exemplo, em termos de facturas de venda
levantada ou pedidos. O maior desafio Gerenciamento da Capacidade
entender a relao entre as demandas e exigncias do negcio e os negcios
carga de trabalho, E de ser capaz de traduzir estes em termos de impacto e
efeito destas sobre o servio e recurso carga de trabalhos e utilizaes, de modo
que adequado limiars pode ser fixada em cada nvel.

ITIL V3 - Service Design - Pgina:

156 de 477

Atividades de ajuste e otimizao


Um certo nmero de actividades tm 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 informao histrica bsica e dispara


necessrio 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 servios. Os dados devem ser analisados
utilizando, sempre que possvel, os sistemas de especialistas para comparar os
nveis de utilizao contra limiars. Os resultados da anlise devem ser includas
nos relatrios e recomendaes feitas conforme o caso. Alguma forma de
mecanismo de controle pode ento ser colocado em prtica para dar seguimento
s recomendaes. Isto pode assumir a forma de servios de compensao,
equilibrando carga de trabalhos, mudando simultaneidade nveis e adicionar ou
remover recursos. Toda a informao acumulada durante estas actividades
devem ser armazenadas no Capacidade do Sistema de Informao de Gesto
(CMIS) e, em seguida, o ciclo comea novamente, monitorando as alteraes
feitas para garantir que eles tiveram um efeito benfico e coletando mais dados
para aes futuras.

ITIL V3 - Service Design - Pgina:

157 de 477

Monitorar a utilizao
Os monitores devem ser especficos para sistemas operacionais especficos,
configuraes de hardware, aplicaos, etc importante que os monitores
podem coletar todos os dados necessrios para o processo de gesto de
capacidade, de um componente ou servio especfico. Tpicos dados
monitorizados inclui:

A utilizao do processador
Utilizao de memria
Por cento por processador transao tipo
Taxas de ES (fsica e buffer) e utilizao de dispositivo
Comprimentos de fila
Utilizao de disco
Taxas de transao
Os tempos de resposta
Lote durao
O uso de banco de dados
O uso de ndice
Taxas de acerto
Concorrente usurio nmeros
Trfego taxas de rede.

Ao considerar os dados que precisam ser includos, uma distino deve ser feita
entre os dados coletados para monitorar capacidade (E.g. rendimento) E os
dados para monitorizar atuao (E.g. tempo de respostas). Os dados de ambos
os tipos exigido pelo servio e Gerenciamento da Capacidade componente
sub-processos. Este monitoramento e recolha precisa incorporar todos os
componentes na servio, Assim, monitorar a experincia do "end-to-end 'do
cliente. Os dados devem ser recolhidas a nvel total de utilizao de recursos e
com um perfil mais detalhado para a carga que cada servio coloca em cada
componente particular. Isso precisa ser realizado em toda a tecnologia de
acolhimento, ou servidor, O local, rede servidor e cliente ou estao de trabalho.
Da mesma forma que os dados precisam ser coletados para cada servio.
Parte do monitoramento atividade deve ser de limiares e linhas de base ou os
perfis dos nveis normais de operao. Se estes so ultrapassados, os alarmes
devem ser levantadas e relatrio de exceos produzidos. Esses limiares e linha
de bases deveriam ter sido determinada a partir da anlise dos dados gravados
anteriormente, e pode ser fixado a ambos os componente e nvel de servio.
Todos os limites devem ser fixado abaixo do nvel em que o componente ou
servio sobre-utilizado, ou abaixo das metas do SLA. Quando o limiar
atingido ou ameaado, 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 perodo de fraco desempenho. O acompanhamento e gesto destes

ITIL V3 - Service Design - Pgina:

158 de 477

eventos, limites e alarmes coberto em detalhes no Operao de Servio


publicao.
Muitas vezes, mais difcil obter os dados sobre os volumes de negcios atuais,
conforme exigido pela Administrao de Empresas Capacidade sub-processo.
Estas estatsticas podem precisar de ser derivada a partir dos dados disponveis
para o servio e Gerenciamento da Capacidade componente sub-processos.
Monitoramento do tempo de resposta
Muitos tm SLAs usurio tempos de resposta como uma das metas a serem
medidos, mas igualmente muitos organizaos tm grande dificuldade em apoiar
esta exigncia. Tempos de resposta do usurio de TI e servios de rede pode
ser monitorado e medido pelo seguinte:

Incorporando cdigo especfico dentro cliente e servidor aplicaes


de software. Isto pode ser usado para fornecer tempos completo 'end-toend "servio de resposta ou de pontos intermedirios de temporizao
para quebrar a resposta global nos seus componentes constituintes. Os
nmeros obtidos com estas ferramentas do os tempos de resposta reais
como percebidos pelos usurios de um servio.
Uso de 'script' sistemas robticos com software de emulao de
terminal. Esses sistemas consistem em sistemas cliente com software de
emulao de terminal (navegador por exemplo, ou sistemas de Telnet) e
software especializado script para gerar e medir as transaes e
respostas. Esses sistemas geralmente fornecem vezes amostra "end-toend" de resposta do servio e so teis para fornecer tempos de resposta
representativas, especialmente para a fase de multi- transaos ou
interaes complexas. Estes s dar tempo de resposta de amostra, no
os tempos de resposta reais como percebidos pelos usurios reais do
servio.
Usando o software de monitoramento distribudo agente. Informaes
teis sobre servios tempo de respostas pode ser obtida atravs da
distribuio de sistemas de agente de software de monitorizao em
pontos diferentes de uma rede (por exemplo, em pases diferentes na
internet). Estes sistemas podem ser usados para gerar transaes de
uma srie de locais e dar medies peridicas de um site de internet
como percebido pelos usurios internacionais de um site na Internet. No
entanto, novamente as vezes recebemos so apenas indicaes dos
tempos de resposta e no so o real usurio tempos de resposta.
Usando especfica monitoramento passivo sistemas. Acompanhamento
de um nmero de amostra representativa de sistemas cliente. Este
mtodo baseia-se na conexo de sistemas de monitoramento de rede
especficos, muitas vezes referida como "sniffers" sendo inseridos em
locais adequados, dentro da rede. Estes podem ento monitorar, gravar e
tempo de todo o trfego que passa um determinado ponto dentro da rede.

ITIL V3 - Service Design - Pgina:

159 de 477

Uma vez registrado, o trfego pode ser analisado a dar informaes


detalhadas sobre os tempos de resposta dos servios. Mais uma vez, no
entanto, estes s podem ser usados para dar uma aproximao para os
tempos de resposta reais do utilizador, embora estes sejam
frequentemente muito perto a situao do mundo real, mas isso depende
da posio do prprio monitor dentro do Infra-estrutura de TI.
Em alguns casos, uma combinao de um nmero de sistemas podem ser
utilizados. O monitoramento dos tempos de resposta um complexo processo
mesmo se se trata de um servio em casa a funcionar numa rede privada. Se
este um servio de internet externo, o processo muito mais complexo devido
ao grande nmero de diferentes organizaes e as tecnologias envolvidas.
Uma empresa privada com um grande site implementou um servio de
monitoramento de site de um provedor externo fornecedor que proporcionaria
alarmes automticos no disponibilidade e capacidade de resposta do seu site. A
disponibilidade e velocidade dos pontos de monitorizao foram menores do que
as do stio a ser monitorizado. Portanto, os nmeros produzidos pelo servio
foram da disponibilidade e da capacidade de resposta do monitoramento servio
em si, mais do que os do website monitorado.
Ao implementar servios de monitoramento externos, garantir que o nvel de
servios e atuao compromissos do servio de monitoramento so maiores do
que os do servio (s) que est sendo monitorado.
Anlise
Os dados coletados a partir do monitoramento devem ser analisados para
identificar as tendncias do qual a utilizao normal e nvel de servios, ou
linhas de base, pode ser estabelecida. Atravs da monitorizao regular e
comparao com este linha de base, Condies de exceo na utilizao do
indivduo componentes ou servio limiars pode ser definido, e as violaes ou
quase no SLAs podem ser relatados e acionadas. Alm disso, os dados podem
ser usados para prever o futuro recurso uso, ou para acompanhar o crescimento
do negcio real contra o crescimento previsto.
A anlise dos dados pode identificar problemas, tais como:

'Gargalos' ou 'pontos quentes' na infra-estrutura


Distribuio inadequada de carga de trabalho atravs de recursos
disponveis
Indexao de dados Inapropriado
Lacunas na aplicao projeto
Aumento inesperado nas cargas de trabalho ou transao taxas
Programao ineficiente ou uso de memria.

ITIL V3 - Service Design - Pgina:

160 de 477

A utilizao de cada componente e servio precisa ser considerado sobre o


curto, mdio e longo prazo, bem como a utilizao, mnimo, mximo e mdio
para esses perodos registrados. Normalmente, o padro de curto prazo abrange
a utilizao durante um perodo de 24 horas, enquanto que a mdio prazo, pode
cobrir um perodo de uma a quatro semanas, e a longo prazo, um perodo de um
ano de durao. Ao longo do tempo, a tendncia na utilizao dos recursos
pelas vrias De servios de TIs vai se tornar aparente. A utilidade desta
informao ainda reforada atravs da gravao de todos os factores que
contribuem para a observados picos e vales na utilizao - por exemplo, se uma
alterao de processo de negcio ou pessoal coincide com quaisquer desvios a
utilizao normal.
importante compreender a utilizao, em cada um destes perodos, de modo
que as alteraes na utilizao de qualquer servio pode estar relacionada com
alteraes previsveis no nvel de utilizao do indivduo componentes. A
capacidade de identificar o hardware especfico ou componentes de software em
que um servio de TI particular depende melhorou muito por um preciso, up-todate e CMS abrangente.
Quando da utilizao de um determinado recurso considerado, importante
compreender ambos o nvel total de utilizao e para a utilizao dos servios
individuais do recurso.
Se um processador que de 75% carregado durante a hora de ponta est a ser
utilizado por dois servios diferentes, A e B, importante saber quanto do total
de 75% est a ser utilizado por cada servio. Assumindo que o sistema
despesas gerais em que o processador de 5%, a carga remanescente de 70%
pode ser dividida entre os dois servios. Se um mudar em um servio ou Servio
B estimada a dobrar a sua carga no processador, o processador teria ser
sobrecarregado.
No entanto, se o servio usa 60% A e B Service usa 10% do processador, em
seguida, o processador seria sobrecarregados se um servio duplicou o seu
carregamento no processador. Mas, se o servio B duplicou o seu carregamento
no processador, ento o processador no seria, necessariamente, ser
sobrecarregado.
Afinao
A anlise dos dados monitorados pode identificar reas da configurao que
podem ser ajustadas para melhorar a utilizao dos recursos do sistema de
servio, e o componente ou a melhorar o desempenho do servio particular.
Afinao as tcnicas que so de assistncia incluem:

ITIL V3 - Service Design - Pgina:

161 de 477

Balanceamento carga de trabalhos de trfego e - as transaes podem


chegar ao host ou servidor a uma porta de entrada particular,
dependendo do local onde o transao foi iniciado; equilibrar a razo de
pontos de iniciao para gateways pode fornecer afinao benefcios
Equilbrio de trfego disco - armazenamento de dados em disco de forma
eficiente e estratgica, por exemplo, diviso de dados em todo fusos
muitos podem reduzir a conteno de dados
Definio de um bloqueio aceite estratgia que especifica quando os
bloqueios so necessrios e no nvel apropriado, por exemplo, banco de
dados, pgina, arquivo de registro, e linha - atrasando o bloqueio at que
uma atualizao necessria pode proporcionar benefcios
A utilizao eficiente da memria - pode incluir olhando para utilizar
memria mais ou menos, dependendo das circunstncias.

Antes de implementar qualquer uma das recomendaes decorrentes da


afinao tcnicas, pode ser conveniente considerar testar a validade da
recomendao. Por exemplo, "Gesto da Demanda pode ser usado para evitar a
necessidade de realizar qualquer ajuste? 'Ou' Pode a mudana proposta ser
modelado para mostrar a sua eficcia antes de ser implementado?
Implementao
O objetivo desse atividade introduzir o viver Servios de explorao de todas
as alteraes que foram identificadas pela anlise, acompanhamento e afinao
actividades. A execuo de quaisquer alteraes decorrentes dessas atividades
deve ser feita atravs de um rigoroso, formal Gesto da Mudana processo. O
impacto de sistema de mudanas de ajuste pode ter implicaes importantes
sobre a clientes do servio. O impacto e risco associada com estes tipos de
mudanas so provveis de ser maior do que a de outro tipo diferente de
modificaes.
importante que o controlo adicional tem lugar, de modo que os efeitos da
mudana pode ser avaliado. Pode ser necessrio efectuar outras alteraes ou
regredir algumas das alteraes originais.
Explorao de novas tecnologias
Isso envolve a compreenso de novas tcnicas e novas tecnologias e como elas
podem ser usadas para apoiar o negcio e inovar melhorias. Pode ser
apropriado para introduzir uma nova tecnologia para melhorar a proviso e
suporte do De servios de TIs em que a organizao dependente. Esta
informao pode ser obtida atravs do estudo de literatura profissional (artigos
de revistas e imprensa) e pela participao:

Seminrios de promoo por hardware e fornecedores de software

ITIL V3 - Service Design - Pgina:

162 de 477

Reunies de grupos de usurios de fornecedors de hardware e software


de potencial
Usurio reunies de grupo para outros profissionais de TI envolvidos na
Gerenciamento da Capacidade.

Cada uma delas fornece fontes de informao relacionada com as tcnicas


possveis, hardware, tecnologia e software, o que pode ser vantajoso para a TI a
implementar para obter benefcios comerciais. No entanto, em todos os
momentos Gerenciamento da Capacidade deve reconhecer que a introduo e
utilizao desta nova tecnologia deve ser custo-justificado e entregar benefcio
real para o negcio. No apenas a nova tecnologia em si que importante,
mas Gerenciamento da Capacidade tambm deve ter conscincia das
vantagens de ser obtidos a partir do uso de novas tecnologias, usando tcnicas
como a "grid computing", "virtualizao" e "computao on-demand '.
Projetando resilincia
Gerenciamento da Capacidade auxilia na identificao e melhoria da resilincia
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 tcnicas como
Componente Anlise de Impacto falha (CFIA, como descrito na seo 4.4 na
Gesto de disponibilidade) para identificar como suscetveis a corrente
configurao o falha ou sobrecarga de indivduo componentes e fazer
recomendaes sobre quaisquer solues custo-eficazes.
Gesto da Capacidade deve ser capaz de identificar o impacto na disposio
recursos de falhas particulares, e do potencial para a execuo dos servios
mais importantes sobre os recursos restantes. Assim, o proviso de reposio
capacidade pode atuar como resilincia ou fail-over em situaes de falha.
Os requisitos para a resistncia no Infra-estrutura de TI deve ser sempre
considerada no momento do servio ou sistema projeto. No entanto, para muitos
servios, a resilincia do servio apenas considerado se permanecer no vivo
operacional usar. Incorporando resilincia em Design de Servios muito mais
eficaz e eficiente do que tentar adicion-lo em uma data posterior, uma vez que
um servio tornou-se operacional.
4.3.5.5 Limiar gesto e controle

Os limites tcnicos e restries sobre os servios e componentes individuais


podem ser usados pelas atividades de monitoramento para definir o limite no
qual os avisos e alarmes so levantadas e relatrios de exceo so produzidos.
No entanto, o cuidado deve ser exercido quando definindo limites, porque muitos
limiars so dependentes do trabalho a ser executado no especial componente.

ITIL V3 - Service Design - Pgina:

163 de 477

A gesto e controlar de servio e limiares de componentes fundamental para a


prestao efectiva de servios para atender sua concordou nvel de servios. Ele
garante que todos os limites de servio e componente so mantidos em nveis
adequados e esto continuamente, automaticamente monitoradas, e alertas e
avisos gerados quando violaes ocorrem. Sempre limites monitorados so
violados ou ameaados, em seguida, os alarmes so levantadas e desvios,
avisos e relatrio de exceos so produzidos. Anlise da situao deve, ento,
ser preenchido e medidas correctivas tomadas sempre que se justificar,
garantindo que a situao no se repetir. Os mesmos itens de dados podem ser
usados para identificar quando os SLAs sejam violados ou susceptvel de ser
violado ou quando componente atuao degrada ou seja susceptvel de ser
degradada. Definindo limites abaixo ou acima das metas reais, a ao pode ser
tomada e uma violao do SLA metas evitado. Limiar monitoramento no s
deve alarmar em exceder um limite, mas tambm deve monitorar a taxa de
mudar e prever quando o limite ser atingido. Por exemplo, um monitor de
espao 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 prximos 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 gesto destes eventos e alarmes coberto em detalhes no
Operao de Serviopublicao s.
Pode haver ocasies em que a optimizao dos componentes de infra-estrutura
e os recursos so necessrios para manter ou melhorar o desempenho ou
rendimento. Isso muitas vezes pode ser feito atravs de Workload Management,
que um termo genrico para cobrir tais aes como:

Reprogramao de um determinado servio ou carga de trabalho para


executar em um horrio diferente do dia ou dia da semana, etc
(geralmente longe de horrios de pico para fora do pico janelas) - que,
muitas vezes, significa ter que fazer ajustes para trabalho de
agendamento de software
Mover um servio ou carga de trabalho de um local ou conjunto de CIs
para outro - muitas vezes para equilibrar a utilizao ou o trfico
Tcnico 'virtualizao': configurar e usar tcnicas de virtualizao e
sistemas para permitir a circulao de processamento em torno da infraestrutura para dar melhor atuao/ Resistncia de uma forma dinmica
Limitar ou mover demanda por componentes ou recursos atravs de
tcnicas de gesto da procura, em conjunto com a gesto financeira (ver
seco 4.3.5.6).

S ser possvel 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 utilizao de recursos de cada carga de trabalho lugares na infraestrutura de TI. Monitoramento diligente e anlise de cargas de trabalho,

ITIL V3 - Service Design - Pgina:

164 de 477

juntamente com um CMIS abrangentes, portanto, so necessrias em um curso


operacional base.
4.3.5.6 Gerenciamento da Demanda

O principal objetivo de Gerenciamento da Demanda influenciar usurio e


cliente demanda por servios de TI e gerenciar o impacto recursos de TI.
Este atividade pode ser realizada como um curto prazo exigncia porque no
existem suficientes actual capacidade para apoiar o trabalho a ser executado,
ou, como uma poltica deliberada de gesto de TI, para limitar a capacidade
necessria no longo prazo.
A curto prazo de Gesto da procura pode ocorrer quando h uma parcial falha
de um recurso crtico no Infra-estrutura de TI. Por exemplo, se houver uma falha
de um processador dentro de um multi-processador servidor, Pode no ser
possvel executar a gama de servios. No entanto, um nmero limitado de
servios poderia ser executado. Gerenciamento da Capacidade deve estar
ciente da prioridade do negcio de cada um dos servios, conhecer as
necessidades de recursos de cada servio (Neste caso, a quantidade de energia
do processador necessrio para executar o servio) e, em seguida, ser capaz de
identificar quais os servios que podem ser executados enquanto h uma
quantidade limitada de energia do processador disponvel.
Longo prazo Gerenciamento de Demanda pode ser necessria quando difcil
justificar um custo-atualizao caro. Por exemplo, muitos processadores so
muito utilizado por apenas algumas horas por dia, tipicamente 10,00-12,00 e
14,00-16,00. Dentro destes perodos, o processador pode ser sobrecarregado
por apenas uma ou duas horas. Para as horas entre 18.00-08.00, estes
processadores so s muito levemente carregado e os componentes so
subutilizados. possvel justificar o custar de uma atualizao para fornecer
capacidade adicional para apenas algumas horas em 24 horas? Ou possvel
influenciar a demanda e espalhar a exigncia de recurso atravs de 24 horas,
deste modo retardando ou evitando totalmente a necessidade de um
melhoramento caro?
Gerenciamento da Demanda precisa entender que os servios esto utilizando o
recurso e em que nvel, eo cronograma de quando eles devem ser executados.
Em seguida, uma deciso pode ser tomada em saber se ser possvel
influenciar o uso de recursos e, em caso afirmativo, qual a opo apropriada.
A influncia sobre os servios que esto em execuo poderia ser exercida por:

Restries fsicas: Por exemplo, pode ser possvel parar alguns servios
de estar disponvel em certos momentos, ou para limitar o nmero de
clientes que podem usar um servio em particular - por exemplo, atravs

ITIL V3 - Service Design - Pgina:

165 de 477

da limitao do nmero de concorrente usurios, a restrio poderia ser


implementado em um recurso especfico ou componente - Por exemplo,
atravs da limitao do nmero de ligaes fsicas a um router ou
comutador da rede
Restries financeiras: If carregamento para De servios de TIs est no
lugar, taxas reduzidas podem ser oferecidos para a execuo 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 tendncias

Um objetivo primordial de Gerenciamento da Capacidade de prever o


comportamento de servios de TI em um determinado volume e variedade do
trabalho. Modelagem um atividade que pode ser utilizado para efeito benfico
em qualquer dos sub-processos de gesto de capacidade.
Os diferentes tipos de modelagem ampla, de fazer estimativas baseadas em
experincia e informao actual utilizao de recursos, a piloto estudos,
prottipos e em grande escala referncias. O primeiro uma abordagem barata
e razovel para o dia-a-dia pequenas decises, enquanto o ltimo caro, mas
pode ser aconselhvel quando a implementao de um novo grande projeto ou
servio. Com todos os tipos de modelao, nveis semelhantes de preciso pode
ser obtida, mas todos so totalmente dependente da percia da pessoa que a
construo modelo e as informaes usadas para cri-lo.
Baselining
A primeira etapa de modelagem a criao de um linha de base modelo que
reflete com preciso o desempenho que est sendo alcanado. Quando este
modelo base foi criada, modelagem preditiva pode ser feito, ou seja, pedir ao 'E
se?' Questes 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 preciso do resultado das falhas potenciais e mudanas podem ser
confiveis.
Gerenciamento da Capacidade eficaz, juntamente com tcnicas de modelagem,
permite Gerenciamento da Capacidade para responder 'E se?' Perguntas. E se
o rendimento A dobra de servio? E se o Servio B movido do servidor atual
para um novo servidor - O que ir ser o efeito sobre o tempo de respostas dos
dois servios?
Anlise de tendncias
Anlise de tendncias pode ser feito sobre a utilizao dos recursos e servio
atuao informao que foi recolhida pelo Gerenciamento da Capacidade
processo. Os dados podem ser analisados numa folha de clculo, e as

ITIL V3 - Service Design - Pgina:

166 de 477

instalaes de grficos e tendncias e previso utilizadas para mostrar a


utilizao de um determinado recurso, durante um perodo de tempo anterior, e
como pode ser esperado para mudar no futuro.
Normalmente, a anlise de tendncia s fornece estimativas de informaes
futuras utilizao de recursos. Anlise de tendncia menos eficaz na produo
de uma estimativa precisa dos tempos de resposta, caso em que um ou outro ou
analtico modelagem, simulao devem ser utilizadas. Anlise de tendncia
mais eficaz quando h um linear relao entre um pequeno nmero de variveis,
e menos eficaz quando h no-lineares relaes entre as variveis, ou quando
h muitas variveis.
Modelagem analtica
Modelos analticos so representaes do comportamento de sistemas de
computador usando tcnicas matemticas, por exemplo, multi-classe teoria das
filas rede. Tipicamente, um modelo construdo usando um pacote de software
em um PC, especificando dentro do pacote do componentes e da estrutura da
configurao que tem de ser modelado, e a utilizao dos componentes, por
exemplo, processador, memria e discos, pelos diversos carga de trabalhos ou
aplicaos. 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 so suficientemente prximas para os tempos de
resposta gravados na vida real, o modelo pode ser visto como uma
representao precisa do sistema de computador.
A tcnica de modelagem analtica requer menos tempo e esforo do que
modelagem, simulao, Mas geralmente d resultados menos precisos. Alm
disso, o modelo deve ser mantido up-to-date. No entanto, se os resultados esto
dentro de 5% de preciso para a utilizao, e de 15-20% para os tempos de
resposta da aplicao em linha, os resultados so geralmente satisfatrios.
Modelagem, simulao
Envolve a simulao modelagem de eventos discretos, por exemplo, transao
taxas de chegada, contra determinada configurao de hardware. Este tipo de
modelagem podem ser muito precisos no dimensionamento novo aplicaos ou
prever os efeitos de mudars em aplicaes existentes, mas tambm pode ser
muito demorado e, por conseguinte, dispendioso.
Ao simular taxas de chegada de transao, tem um nmero de funcionrios
entre uma srie de transaes a partir de scripts preparados, ou usar o software
para as mesmas transaes de entrada de script com uma taxa de chegada
aleatria. Qualquer uma destas abordagens, leva tempo e esforo para preparar
e executar. No entanto, pode ser custo-justificado para organizaos com

ITIL V3 - Service Design - Pgina:

167 de 477

grande servios e os sistemas em que a grandes custar e as implicaes de


desempenho associados assumem grande importncia.
4.3.5.8 Aplicao dimensionamento

Aplicao dimensionamento tem vida til limitada. Ele iniciado no projeto fase
de um novo servio, ou quando h uma mudana significativa para um servio
existente, e completa-se quando o aplicao aceito no ao vivo operacional
ambiente. Dimensionamento de atividades deve incluir todas as reas de
tecnologia relacionados com as aplicaes, e no apenas os prprios
aplicativos. Isto deve incluir a infra-estrutura, meio ambiente e de dados, e,
muitas vezes, usar a modelagem e tendncias tcnicas.
O primrio objetivo aplicao de cola o de estimar a recurso requisitos para
apoiar uma proposta de alterao a um servio existente ou a implementao de
um novo servio, para garantir que ele cumpre a sua necessria nvel de
servios. Para alcanar este objectivo, a aplicao de dimensionamento tem de
ser uma parte integrante do Servio Ciclo de Vida.
Durante os requisitos iniciais e de design, os nveis de servio exigidos devem
ser especificados em uma SLR. Isto permite que o Design de Servios e
desenvolvimento de empregar as tecnologias pertinentes e dos produtos para
alcanar um design que satisfaz os nveis desejados de servio. muito mais
fcil e menos dispendioso para atingir os nveis de servio exigidos se Design de
Servios considera os nveis de servio exigidos no incio do Ciclo de Vida do
Servio, em vez de em algum momento mais tarde.
Outras consideraes so a aplicao de colagem resilincia aspectos que
podem ser necessrias para a construo, na concepo de novos servios.
Gerenciamento da Capacidade capaz de fornecer aconselhamento e
orientao para o Gerenciamento de Disponibilidade processo sobre os recursos
necessrios para proporcionar o nvel necessrio de atuao e resilincia.
O dimensionamento do aplicao deve ser refinada como a concepo e
desenvolvimento processo progride. O uso de modelao podem ser usados
dentro do aplicao dimensionamento processo.
As SLRs dos desenvolvimentos de aplicaes planejadas no deve ser
considerado isoladamente. Os recursos a serem utilizados pela aplicao so
susceptveis de ser compartilhada com outros servios, potencial e ameaas a
metas de SLA existentes devem ser reconhecidos e gerenciado.
Ao comprar pacotes de software de fornecedores externos, to importante
para entender as necessidades de recursos necessrios para apoiar o servio.
Muitas vezes pode ser difcil de se obter essa informao a partir do fornecedors
e pode variar, dependendo rendimento. Por conseguinte, benfico para

ITIL V3 - Service Design - Pgina:

168 de 477

identificar semelhante clientes do produto e ganhar uma compreenso das


implicaes de recursos a partir deles. Pode ser pertinentes ao benchmark,
avaliar ou o julgamento do produto antes da compra.
A qualidade deve ser construdo dentro
Alguns aspectos do servio qualidade pode ser melhorada aps a aplicao
(hardware adicional pode ser adicionado para melhorar o desempenho, por
exemplo). Outros - em particular aqueles relacionados, tais como confiana e
manuteno software de aplicaes - dependem da qualidade a ser 'construdo
em', uma vez que a tentativa de adicion-lo numa fase posterior , no redesenho
efeito, e remodelao, normalmente, a um custo muito mais elevado do que o
original desenvolvimento. Mesmo no exemplo de hardware citado acima,
provvel que o custo para adicionar mais adicional capacidade aps a
implementao do servio, e no como parte do original projeto.

4.3.6 Triggers, entradas, sadas e interfaces


H muitos gatilhos que iniciaro as atividades de gerenciamento de capacidade.
Estes incluem:

Violaes de servios, capacidade ou atuao eventos e alertars,


incluindo limiar eventos
Relatrio de exceos
Re peridicaviso da capacidade atual e desempenho e rever de
previses, relatrios e planos
Servios novos e modificados que requerem capacidade adicional
Tendncia peridica e modelagem
Reviso e reviso de negcios e de TI planos e estratgias
Reviso e reviso de projetos e estratgias
Reviso e reviso de SLAs, Olas, contratos ou quaisquer outros acordos.

H um nmero de fontes de informao que so relevantes para a Gesto da


Capacidade processo. Alguns destes so os seguintes.
4.3.6.1 Entradas

Informaes de negcios: De negcio da organizao estratgia, Os


planos e os planos financeiros e informaes sobre suas necessidades
atuais e futuras.
Informaes de servio e de TI: De Estratgia de Servio, A estratgia
de TI e planos e atual oramentos, abrangendo todas as reas de
tecnologia e planos de tecnologia, incluindo a infra-estrutura, ambiente,
Dados e aplicaos, e da maneira em que eles se relacionam com a
estratgia de negcios e planos.

ITIL V3 - Service Design - Pgina:

169 de 477

Componente desempenho e capacidade informao: De tecnologia


existentes e novos, de fabricantes e fornecedors.
Servio atuao questes: O incidente e Gerenciamento de Problemas
processos, com incidentes e problemas relacionados ao mau
desempenho.
Informaes sobre o servio: A partir do processo de SLM, com
detalhes dos servios da Portflio de Servios e a Catlogo de Servios e
meta de nvel de servios dentro de SLAs e SLRs, e, possivelmente, a
partir da monitoramento de SLAs, servio de opinies e violaes dos
SLAs.
Informaes financeiras: De Gesto Financeira, a custar de servio
profissionalviso, O custo de recursos, componentes e upgrades, o
benefcio resultante de negcios e os planos financeiros e oramentos,
bem como os custos associados ao servio e componente falha. Alguns
dos custos de componentes e atualizaes para os componentes que
sero obtidos a partir de aquisio, fornecedors e os fabricantes.
Alterar as informaes: De a Gesto da Mudana processo, com um
Alterar agendamento e uma necessidade de avaliar todas as mudanas
para a sua impacto sobre a capacidade da tecnologia.
As informaes de desempenho: A partir do Sistema de Informao de
Gesto de Capacidade (CMIS) sobre o desempenho atual de ambos os
servios existentes e Infra-estrutura de TI componentes.
CMS: Contendo informaes sobre a relaos entre o negcio, Os
servios, o servios de apoios e a tecnologia.
Workload informao: De a Operaes de TI equipe, com horrios de
todo o trabalho que precisa ser executado, e informaes sobre as
dependncias entre os diferentes servios e informaes, e as
interdependncias dentro de um servio.

4.3.6.2 Sadas

As sadas dos Gerenciamento da Capacidade so utilizados em todas as outras


partes do processo, Por muitos outros processos e por outras partes do
organizao. Muitas vezes, essa informao fornecida como relatrios
eletrnicos ou displays em reas comuns, ou como pginas de intranet
servidors, para garantir a informao o mais up-to-date sempre utilizado. A
informao fornecida como se segue:

O Capacidade do Sistema de Informao de Gesto (CMIS): Contm as


informaes necessrias 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 servio usada em Gerenciamento da Capacidade de negcios para
determinar os componentes de infra-estrutura o que ou upgrades
componentes so necessrias, e quando.
O Plano de capacidade: Usado por todas as reas do negcio e gesto
de TI. e acionado pela Provedor de servios de TI ea alta administrao

ITIL V3 - Service Design - Pgina:

170 de 477

da organizao para planejar a capacidade da infra-estrutura de TI. Ele


tambm fornece planejamento de entrada para muitas outras reas de TI
e negcios. Ele contm informaes sobre o uso atual de servio e
componentes, e os planos para o desenvolvimento da capacidade de TI
para atender s necessidades do crescimento de ambos os servios
existentes e os novos servios acordados. O Plano de capacidade deve
ser usada ativamente como base para a tomada de deciso. Muitas
vezes, os planos de capacidade so criadas e nunca referido ou usado.
Informaes de servio e relatrios de desempenho: Usado por
muitos outros processos. Por exemplo, a Gerenciamento da Capacidade
processo de ajuda Gerenciamento de Nvel de Servio com a elaborao
de relatrios e anlise de servio atuao eo desenvolvimento de SLRs
novos ou mudanas SLAs existentes. Ele tambm auxilia o processo de
gesto financeira, identificando quando o dinheiro precisa ser orado para
atualizaes de infraestrutura de TI, ou a compra de novos componentes.
Workload anlise e relatrios: Usado por operaes de TI para avaliar e
implementar mudanas em conjunto com a Gesto da Capacidade de
agendar ou reagendar quando os servios ou cargas de trabalho so
executados, para garantir que o uso mais eficaz e eficiente feito dos
recursos disponveis.
Ad hoc relatrios de capacidade e desempenho: Usado por todas as
reas de Gerenciamento da Capacidade, TI e do negcio para analisar e
resolver questes de servio e desempenho.
Previses e relatrios de previso: Usado por todas as reas para
analisar, prever e prever negcio e de TI cenrios e suas possveis
solues.
Soleiras, alertas e eventos.

4.3.7 Indicadores Chave de Desempenho


Alguns dos KPIs e mtricos que podem ser usados para avaliar a eficincia e
eficcia das atividades de gerenciamento de capacidade deve incluir:

Precisas previses de negcios:


Produo de carga de trabalho previses sobre o tempo
Preciso percentual de previses de tendncias de negcios
Adoo oportuna de planos de negcios para o Plano de
Capacidade
Reduo do nmero de variaos dos planos de negcios e planos
de capacidade.
Conhecimento das tecnologias atuais e futuras:
Aumento da capacidade de monitorar o desempenho e rendimento
de todos os servios e componentes
Justificao oportuna e implementao de novas tecnologias, de
acordo com os requisitos de negcios (tempo, custar e
funcionalidade)

ITIL V3 - Service Design - Pgina:

171 de 477

Reduo no uso de tecnologia de idade, fazendo com que, devido


violado SLAs problemas com suporte ou desempenho.
Capacidade de demonstrar custo-eficcia:
Reduo no ltimo minuto de compra para resolver problemas de
desempenho urgentes
Reduo do excesso de capacidade de TI
Previses precisas de despesas previstas
Reduo da interrupo de negcios causada pela falta de
adequada de TI capacidade
Reduo relativa do custo de produo da Plano de capacidade.
Capacidade de planejar e implementar a capacidade de TI apropriada
para atender s necessidades de negcios:
Percentagem de reduo do nmero de incidentes devido m
atuao
Reduo percentual em negcios perdidos devido capacidade
inadequada
Todos os novos servios implementados combinar Nvel Requisitos
de Servio (SLRs)
Maior porcentagem de recomendaes feitas pelo Gerenciamento
da Capacidade so ativados
Reduo do nmero de violaes de SLA devido a qualquer
servio de m qualidade atuao ou o desempenho dos
componentes pobres.

4.3.8 Gesto da Informao


O objetivo do CMIS fornecer a capacidade e informaes relevantes
desempenho para produzir relatrios e apoiar a Gesto da Capacidade
processo. Esses relatrios fornecem informaes valiosas para muitos de TI e
Servio de Gesto de processos. Estes relatrios devem incluir o seguinte.
Componente relatrios baseados
Para cada componente deve haver uma equipe de tcnicos responsveis pela
sua controlar e gesto. Os relatrios devem ser produzidos para ilustrar como os
componentes esto realizando e quanto de sua capacidade mxima est sendo
usado.
Servio de relatrios baseados
Relatrios e informaes tambm devem ser produzidos para ilustrar como o
servio e suas componentes esto realizando com relao s suas metas de
servios gerais e restries. Esses relatrios serviro de base de SLM e os
relatrios de atendimento ao cliente.
Relatrios de exceo

ITIL V3 - Service Design - Pgina:

172 de 477

Relatrios que mostram gesto e pessoal tcnico, quando a capacidade eo


desempenho de um determinado componente ou servio se torna inaceitvel
tambm so uma exigido a partir da anlise de dados de capacidade. possvel
definir limites para qualquer componente ou servio de medio dentro da CMIS.
Um exemplo limiar Pode ser que a porcentagem de utilizao do processador
para um determinado servidor violou a 70% durante trs horas consecutivas, ou
que o nmero concomitante de sesso usurios excede o limite acordado.
Em particular, relatrio de exceos so de interesse para o processo de SLM
em determinar se os alvos em SLAs foram violados. Tambm o incidente e
Gerenciamento de Problemas processos podem ser capazes de usar os
relatrios de excepo na resoluo de incidentes e problemas.
Relatrios preditivos e previso
Para garantir a Provedor de servios de TI continua a proporcionar o necessrio
nvel de servios, o Gerenciamento da Capacidade processo deve prever o
futuro carga de trabalhos e crescimento. Para fazer este futuro, componente e
servio capacidade e desempenho deve ser previsto. Isto pode ser feito de uma
variedade de maneiras, dependendo das tcnicas e da tecnologia utilizada.
Mudars para cargas de trabalho por parte do desenvolvimento e implementao
de novas funcionalidades e servios devem ser consideradas juntamente com o
crescimento da funcionalidade atual e servios impulsionada pelo crescimento
do negcio. Um exemplo simples de uma previso de capacidade uma
correlao entre uma empresa motorista e utilizao de um componente, por
exemplo, utilizao do processador com o nmero de cliente contas. Estes
dados podem ser correlacionados para encontrar o efeito que o aumento do
nmero de contas de cliente ir ter sobre a utilizao do processador. Se as
previses sobre os requisitos de capacidade futura identificar um requisito para o
aumento recurso, Esta exigncia precisa de ser entrada para o Plano de
capacidade e includos dentro do IT oramento ciclo.
Muitas vezes, os relatrios de capacidade so consolidadas em conjunto e
armazenado em um site de intranet para que qualquer pessoa pode acessar e
se referem a eles.
4.3.8.1 Capacidade do Sistema de Informao de Gesto

Muitas vezes, a capacidade de dados armazenado na tecnologia de


ferramentas especficas e bases de dados, e o valor total dos dados, a
informao e a sua anlise no obtido. O valor real de dados s podem ser
obtidos quando os dados so combinados num nico conjunto de integrado,
repositrios de informao ou um conjunto de bases de dados.
O Capacidade do Sistema de Informao de Gesto (CMIS) a pedra angular
de uma bem sucedida Gerenciamento da Capacidade processo. A informao

ITIL V3 - Service Design - Pgina:

173 de 477

contida dentro do CMIS armazenada e analisada por todos os sub-processos


de gesto de capacidade, porque um repositrio que contm um nmero de
diferentes tipos de dados, incluindo negcios, servio de recursos, ou a
utilizao de dados financeiros, a partir de todas as reas da tecnologia .
No entanto, o CMIS improvvel que seja uma base de dados nica, e,
provavelmente, existe em vrias localizaes fsicas. Dados de todas as reas
de tecnologia, e todos os componentes que compem o De servios de TIs, em
seguida, podem ser combinados para anlise e proviso de relatrios tcnicos e
de gesto. S quando toda a informao est integrado pode relatrios "end-toend 'servio ser produzido. O integridade e exatido dos dados dentro do CMIS
precisa ser cuidadosamente gerido. Se o CMIS no parte de um CMS global
ou SKMS, ento as ligaes entre esses sistemas precisam ser implementadas
para garantir a consistncia e preciso das informaes registradas dentro
deles.
A informao no CMIS usado para formar a base de relatrios de desempenho
e capacidade de gesto e pontos de vista que devem ser entregues a clientes,
gesto de TI e pessoal tcnico. Alm disso, os dados so utilizados para gerar
previses 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 acesso 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 informaes sobre as necessidades atuais e futuras do
negcio. Os futuros planos de negcios da organizao precisam ser
considerados e os efeitos sobre os servios de TI entendido. Os dados de
negcios usado para prever e validar como as mudanas em drivers de
negcio afetam a capacidade eo desempenho do Infra-estrutura de TI. Os dados
de negcios devem incluir transaes comerciais ou medies, tais como o
nmero de contas, o nmero de faturas geradas, o nmero de linhas de
produtos.
Dados de servio
Para alcanar uma abordagem de servio orientada para Gerenciamento da
Capacidade, servio dados devem ser armazenados dentro dos CMIS. Dados de
servios tpicos so transao tempo de respostas, transao taxas, carga de
trabalho volumes, etc Em geral, os SLAs e SLRs fornecer as metas de servio
para o qual o Gerenciamento da Capacidade processo precisa para gravar e
monitorar os dados. Para garantir que os alvos na SLAs so alcanados, os
limiares de SLM deve ser includo, de modo que a monitorao atividade pode

ITIL V3 - Service Design - Pgina:

174 de 477

medir contra esses servios limiars e aumentar avisos de exceo e relatrios


antes de metas de servio so violados.
Utilizao de dados de componentes
O CMIS tambm precisa de gravar os dados de recursos consistindo de limite de
utilizao, e a informao sobre todos os limites da tecnologia componentes
apoiar os servios. A maioria dos componentes de TI tm limitaes sobre o
nvel ao qual eles devem ser utilizados. Alm desse nvel de utilizao, o recurso
ser mais utilizado eo atuao dos servios que utilizam o recurso ser
prejudicada. Por exemplo, o nvel mximo de utilizao recomendada em um
processador pode ser de 80%, ou a utilizao de um segmento de LAN Ethernet
compartilhada no deve exceder 40%.
Alm disso, os componentes tm vrias limitaes fsicas alm do qual uma
maior conectividade ou utilizao impossvel. Por exemplo, o nmero mximo
de ligaes atravs de um aplicao ou uma porta de sada de 100, ou de um
determinado tipo de disco tem um fsico capacidade de 15GB. Os CMIS deve
conter, para cada componente e o mximo desempenho e limites de
capacidade, taxas de utilizao atuais e do passado e do componente associado
limiars. Com o tempo, isso pode exigir grandes quantidades de dados a ser
acumulado, ento necessrio que haja boas tcnicas de anlise, agregar e
arquivamento de dados.
Os dados financeiros
O processo de Gerenciamento da Capacidade requer dados financeiros. Para
avaliar as opes de atualizao alternativos, ao propor vrios cenrios no Plano
de capacidade, O financeira custar das atualizaes para os componentes da
infra-estrutura de TI, juntamente com a informao sobre o hardware de TI atual
oramento, Deve ser conhecida e includa nas consideraes. A maioria destes
dados podem estar disponveis a partir do Gerenciamento Financeiro para TI
processo de servios, mas de Gesto de Capacidade precisa considerar essas
informaes ao gerenciar os requisitos de negcios futuros.

4.3.9 Desafios, Fatores Crticos de Sucesso e riscos


Um dos grandes desafios Gerenciamento da Capacidade persuadir o negcio
para fornecer informaes sobre seus planos de negcios estratgicos, para
permitir a Provedor de servios de TI organizao para fornecer eficaz Gesto
de Continuidade de Negcios (BCM). Isto particularmente verdadeiro em
situaes terceirizados onde pode haver razes comerciais ou confidenciais
porque esses dados no podem ser compartilhados. Mesmo que os dados sobre
o estratgico de negcios est disponvel, pode haver problemas com relao
qualidade e preciso dos dados contidos os planos de negcios em relao a
BCM.

ITIL V3 - Service Design - Pgina:

175 de 477

Um outro desafio a combinao de todos os dados CCM para um conjunto


integrado de informao que pode ser analisada de uma forma consistente para
fornecer detalhes do uso de todos os componentes dos servios. Isto
particularmente desafiador quando as informaes das diferentes tecnologias
fornecida por diferentes ferramentas em diferentes formatos. Muitas vezes, o
qualidade de informaes sobre o desempenho do componente da tecnologia
varivel, tanto na qualidade e a sua preciso.
As quantidades de informaes produzidas por BCM e, especialmente, SCM e
CCM, so enormes ea anlise dessas informaes difcil de conseguir. As
pessoas e os processos precisam se concentrar na chave recursos e a sua
utilizao, embora no ignorando outras reas. A fim de fazer isso, apropriada
limiars deve ser usado, e confiana 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 so os
seguintes:

Precisas previses de negcios


Conhecimento das tecnologias atuais e futuras
Capacidade de demonstrar custo-eficcia
Capacidade de planejar e implementar a TI apropriada capacidade para
combinar com necessidade de negcio.

Alguns dos principais riscos associados gesto de capacidade incluem:

A falta de compromisso do negcio para o Gerenciamento da Capacidade


processo
A falta de informao adequada do negcio sobre os planos e estratgias
futuras
A falta de compromisso da alta administrao ou a falta de recursos e / ou
oramento para o processo de Gerenciamento da Capacidade
SCM e CCM realizado em isolamento porque BCM difcil, ou h uma
falta de informao de negcio adequadas e precisas
Os processos se tornam demasiado burocrtico ou manualmente
intensivo
Os processos se concentrar demais na tecnologia (CCM) e no o
suficiente sobre os servios (SCM) e de negcios (BCM)
Os relatrios e informaes fornecidas so muito volumosos ou muito
tcnico e no do as informaes necessrias ou apropriadas para o
clientes e os negcios.

ITIL V3 - Service Design - Pgina:

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 nvel de servio disponibilidade entregues em todos os servios
correspondente a ou excede as necessidades atuais e futuras acordadas do
negcio, de uma maneira custo-efetiva.
O objetivo do Gerenciamento da Disponibilidade fornecer um ponto de foco e
de gesto para todas as questes relacionadas com a disponibilidade, relativo a
ambos os servios e recursos, garantindo que as metas de disponibilidade em
todas as reas so medidos e alcanados.
O objetivos de Gerenciamento de Disponibilidade so:

Produzir e manter uma adequada e up-to-date Plano de disponibilidade


que reflete as necessidades atuais e futuras do negcio
Prestar assessoria e orientao para todas as outras reas de negcio e
de TI em todas as questes relacionadas com a disponibilidade
Garantir que o servio disponibilidade realizaes atender ou exceder
todas as suas metas acordadas, por servios de gesto e recursos
relacionada com a disponibilidade atuao
Auxiliar no diagnstico e resoluo de disponibilidade e incidentes
relacionados problemas
Avaliar a impacto de todos mudars sobre o Plano de disponibilidade e
desempenho e capacidade de todos servios e os recursos
Assegurar que as medidas pr-ativas para melhorar a disponibilidade de
servios so implementados onde quer que seja de custo justificvel para
faz-lo.

Gerenciamento de Disponibilidade deve garantir o nvel acordado de


disponibilidade fornecida. A medio e monitoramento de TI a disponibilidade
uma chave atividade para assegurar os nveis de disponibilidade esto sendo
atendidas de forma consistente. Gerenciamento de Disponibilidade deve
procurar continuamente otimizar e proativa melhorar a disponibilidade do Infraestrutura de TI, Dos servios e do sustentadas organizao, A fim de
proporcionar melhorias econmicas de disponibilidade que pode trazer
benefcios de negcios e de clientes.

4.4.2 mbito
O escopo do Gerenciamento de Disponibilidade processo abrange o projeto,
Implementao, avaliao, gesto e melhoria de De servios de TI e
componente disponibilidade. Gerenciamento de Disponibilidade precisa entender

ITIL V3 - Service Design - Pgina:

177 de 477

o servio e requisitos de disponibilidade de componentes a partir do perspectiva


de negcios em termos de:

Atual processo de negcioes, o operao e requisitos


Futuros planos de negcio e requisitos
Metas de servio e da corrente de TI Operao de Servio e entrega
Infraestrutura de TI, dados, aplicaos e ambiente e o seu desempenho
Impactos nos negcios e prioridades em relao aos servios e seu uso.

Entender tudo isso vai permitir gerenciamento de disponibilidade para garantir


que todos os servios e componentes so projetados e entregues a cumprir as
suas metas em termos de necessidades de negcio acordados. O processo de
Gerenciamento de Disponibilidade:

Deve ser aplicada a todos os operacional servios e tecnologia,


nomeadamente as referidas no SLAs. Tambm pode ser aplicada a estes
servios de TI considerados essenciais de negcios, independentemente
de existir SLAs formais
Deve ser aplicado a todos os servios de TI para servios novos e
existentes, onde Nvel Requisitos de Servio (SLRs) ou Contratos de
Nvel de Servio (SLAs) foram estabelecidas
Deve ser aplicada a todos os servios de apoios e os parceiros e
fornecedors (internos e externos) que formam a organizao de suporte
de TI como um precursor para a criao de acordos formais
Considera todos os aspectos dos servios de TI e componentes e
organizaes de apoio que podem impactar disponibilidade, Incluindo a
formao, as habilidades de processo, eficcia,procedimentos e
ferramentas.

O processo de gerenciamento de disponibilidade no inclui Gesto de


Continuidade de Negcios ea retomada dos negcios aps o processamento de
um grande desastre. O suporte de BCM est includo dentro da TI Gesto da
Continuidade do Servio (ITSCM). No entanto, Gerenciamento de
Disponibilidade fornece insumos essenciais para ITSCM, e os dois processos
tm fim relao, Em particular no avaliao e gesto dos riscos e na
implementao de reduo de riscos e resilincia medidas.
O processo de gerenciamento de disponibilidade deve incluir:

Monitoramento de todos os aspectos de disponibilidade, confiana e


manuteno de TI servios e o apoio componentes, com eventos
apropriados, alarmes e escalada, Com scripts automatizados para
recuperao
Manuteno de um conjunto de mtodos, tcnicas e clculos para todas
as medies de disponibilidade, mtricos e relatrios
Assistncia com avaliao de risco e atividades de gerenciamento

ITIL V3 - Service Design - Pgina:

178 de 477

Coleta de medies, anlise e produo de relatrios regulares e ad hoc


sobre o servio e componente disponibilidade
Entender as demandas acordadas atuais e futuras da negcio de servios
de TI e sua disponibilidade
Influenciar o design de servios e componentes para alinhar com as
necessidades do negcio
Produzir um Plano de disponibilidade que permite que o provedor de
servios continuar a fornecer e melhorar os servios de acordo com
metas de disponibilidade definidos no Acordo de Nvel de Servios
(SLAs), e para planejar e prever os nveis de disponibilidade exigidos
futuras, conforme definido no Exigncia de Nvel de Servios (SLRs)
Manter uma agenda de testes para todos os resistentes e fail-over
componentes e mecanismos
Assistncia com a identificao e resoluo de quaisquer incidentes e
problemas associados com o servio ou indisponibilidade componente
Melhoria proativa de servio ou disponibilidade de componentes onde
quer que seja justificvel custo e atende s necessidades do negcio.

4.4.3 Valor para o negcio


O Gerenciamento de Disponibilidade processo garante que a disponibilidade de
sistemas e servios corresponde s crescentes necessidades acordadas do
negcio. O papel de TI dentro da empresa agora fundamental. O
disponibilidade e confiabilidade de De servios de TIs pode influenciar
diretamente a satisfao do cliente ea reputao do negcio. por isso que de
gerenciamento de disponibilidade essencial para garantir a TI entrega os
nveis adequados de disponibilidade de servio exigidos pela empresa para
satisfazer a sua objetivo de negcios e entregar o qualidade de servio exigido
por sua clientes. No mercado competitivo de hoje, a satisfao do cliente com o
servio (s), desde primordial. A lealdade do cliente no pode ser invocado, e
insatisfao com a disponibilidade e confiana de servio de TI pode ser um
fator chave na clientes que tomam o seu negcio 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 servio, a partir de Estratgia e Design, atravs de Transio e
Operao de Melhoria. A disponibilidade adequada e resilincia deve ser
projetado em servios e componentes, desde as fases iniciais do projeto. Isso ir
garantir no s que a disponibilidade de qualquer servio novo ou alterado
cumpra suas metas esperados, mas tambm que todos os servios e
componentes existentes continuam a cumprir todas as suas metas. Esta a
base da estabilidade servio prviso.

ITIL V3 - Service Design - Pgina:

179 de 477

4.4.4 Polticas / princpios / conceitos bsicos


O Gerenciamento de Disponibilidade processo est continuamente tentando
garantir que todos os servios operacionais cumprir as suas metas de
disponibilidade acordados, e que os servios novos ou alterados so concebidos
de modo a cumprir os seus objectivos pretendidos, sem comprometer a atuao
dos servios 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 servio. Isto para assegurar que todos os
alvos de servio acordados so medidos e alcanados. Onde quer que desvios
ou violaes so detectados, so investigadas e as medidas correctivas
instigado. A maioria destas atividades so conduzidas no estgio de Operaes

ITIL V3 - Service Design - Pgina:

180 de 477

do ciclo de vida e esto ligados ao monitoramento e controlar atividades de


eventos e Gerenciamento de Incidentes processos. (Veja o Operao de Servio
publicao.)
As atividades preventivas consistem em produzir recomendaes, planos e
documentos sobre o projeto diretrizs e os critrios para servios novos e
modificados, bem como a melhoria contnua do servio e reduo de risco nos
servios existentes onde quer que pode ser custo-justificado. Estes so os
principais aspectos a serem considerados dentro Design de Servios
actividades.
Um processo eficaz de gerenciamento de disponibilidade, que consiste tanto as
atividades reativas e proativas, pode "fazer uma grande diferena 'e ser
reconhecido como tal pelo negcio, Se a desenvolvimento de gerenciamento de
disponibilidade de TI dentro de uma organizao tem uma forte nfase nas
necessidades da empresa e clientes. Para reforar essa nfase, existem vrios
princpios orientadores que devem sustentar o processo de gerenciamento de
disponibilidade e seu foco:

A disponibilidade do servio est no centro de satisfao do cliente eo


sucesso do negcio: h uma correlao direta na maioria das
organizaes entre o servio disponibilidade eo cliente e usurio
satisfao, onde o desempenho servio de m qualidade definida como
sendo indisponveis.
Reconhecendo que, quando os servios no conseguem, ainda
possvel alcanar clientes de negcios, ea satisfao e reconhecimento: a
forma como um provedor de servios reage de falha situao tem uma
grande influncia no cliente e usurio percepo e expectativa.
Melhorar a disponibilidade s pode comear aps a compreenso de
como o De servios de TIs apoiar o operao do negcio.
Disponibilidade do servio to bom quanto o elo mais fraco da cadeia:
ela pode ser aumentada pela eliminao de pontos nicos de falha
(SPoFs) ou um pouco confiveis ou fraco componente.
Disponibilidade no apenas um processo reativo. O mais pr-ativa do
processo, A disponibilidade servio melhor ser. Disponibilidade no deve
reagir puramente para servio e falha de componentes. Os mais eventos
e falhas esto previstas, antecipou-se e impediu, quanto maior o nvel de
disponibilidade do servio.
mais barato para projetar o nvel certo de disponibilidade do servio em
um servio desde o incio, em vez de tentar "parafuso-lo em
'posteriormente. Adicionando resilincia para um servio ou componente
invariavelmente mais caro do que projetando-o de desde o incio. Alm
disso, uma vez que um servio tem um nome ruim para insegurana,
torna-se muito difcil mudar a imagem. Resilincia tambm um
elemento-chave do GCSTI, e isso deve ser considerado ao mesmo
tempo.

ITIL V3 - Service Design - Pgina:

181 de 477

O escopo de Gerenciamento de Disponibilidade abrange o projeto, Medio,


implementao e gerenciamento de servio de TI e disponibilidade de infraestrutura. Isto reflecte-se na descrio do processo mostrado na Figura 4.13 e
descrito nos pargrafos seguintes.
O processo de Gerenciamento de Disponibilidade tem dois elementos-chave:

Atividades reativas: O aspecto reativo de Gerenciamento de


Disponibilidade envolve o monitoramento, medio, anlise e gesto de
todos os eventos, incidentes e problemas envolvendo indisponibilidade.
Essas atividades so, principalmente, envolvidos na operacional papis.
Atividades proativas: As atividades pr-ativas de gerenciamento de
disponibilidade envolvem a dinmica de planejamento, design e melhoria
da disponibilidade. Essas atividades so, principalmente, envolvidos em
papis de design e planejamento.

Gerenciamento de disponibilidade concludo em dois nveis inter-relacionados:

Disponibilidade do servio: Envolve todos os aspectos da


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

Gerenciamento de Disponibilidade baseia-se na monitoramento, Medio,


anlise e elaborao de relatrios dos seguintes aspectos:
Disponibilidade: A capacidade de um servio de componente ou de CI para
desempenhar a sua concordou funo quando necessrio. Muitas vezes,
medido e relatado como um percentual:
(Tempo de servio acordado (AST) - downtime)
Disponibilidade (%) = --------------------------------------------- ---------- X 100%
Tempo de servio acordado (AST)
Nota: O tempo de inatividade s devem ser includos no clculo acima, quando
ocorre no interior da Tempo de servio acordado (AST). No entanto, o tempo de
inatividade total deve tambm ser registrados e relatados.
Confiana: Uma medida de quanto tempo uma servio, Componente ou CI pode
desempenhar sua funo acordada sem interrupo. O confiana do servio
pode ser melhorada atravs do aumento da fiabilidade de componentes
individuais ou pelo aumento da resilincia do servio a falha de um componente

ITIL V3 - Service Design - Pgina:

182 de 477

individual (ou seja, o aumento do componente redundncia, E.g. usando


tcnicas de balanceamento de carga). Muitas vezes, medido e relatado como
Tempo mdio entre Incidentes de Servio (TMEIS) ou Tempo mdio entre falhas
(MTBF):
Tempo disponvel em horas
Confiabilidade (TMEIS em horas) = ------------------------------------------- -------Nmero de quebras
Tempo disponvel em horas - o tempo de inatividade total em horas
Confiabilidade (MTBF em horas) = ------------------------------------------- -------------------------Nmero de quebras
Manutenibilidade: Uma medida de quo rapidamente e efetivamente um servio
de componente, ou CI pode ser restaurard ao normal de trabalho depois de um
falha. Ela medida e relatada como Tempo mdio para restaurar o servio
(MTR) e deve ser calculado atravs da seguinte frmula:
Paralisao total em horas
Manutenibilidade (MTRS em horas) = --------------------------------------Nmero de quebras de servio
MTRS deve ser usado para evitar a ambiguidade do termo da indstria mais
comum Mean Time To Repair (MTTR), que em algumas definies inclui
somente reparar tempo, mas em outros inclui recuperao tempo. O tempo de
inatividade em MTRS abrange todos os fatores contribuintes que fazem o
servio, componente ou CI indisponveis:

Tempo para gravar


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

Exemplo: Uma situao em que um 24 x 7 de servio foi executado por um


perodo de 5.020 horas, com apenas dois intervalos, um de seis horas e uma de
14 horas, daria os seguintes nmeros:
Disponibilidade = (5.020 - (6 +14)) / 5020 x 100 = 99,60%

ITIL V3 - Service Design - Pgina:

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
Manuteno: A capacidade de um terceiro fornecedor para atender os termos de
sua contrato. Muitas vezes, esse contrato vai incluir os nveis acordados de
disponibilidade, Confiabilidade e / ou manuteno para uma servios de apoio
ou componente.
Estes aspectos e suas inter-relaes so ilustrados na figura 4.14.

Figura 4,14 termos de disponibilidade e medies

Embora o alvo principal de servio contido dentro de SLAs para o clientes e de


negcios, a disponibilidade, como ilustrado na Figura 4.14, alguns clientes
exigem tambm alvos fiabilidade e facilidade de manuteno a serem includos.
Onde estes esto includos devem se relacionar com a confiabilidade do servio
e metas de manuteno, enquanto que as metas de confiabilidade e facilidade
de manuteno constantes OLAs e contratos relacionados com componente e
servios de apoio metas e muitas vezes pode incluir metas disponibilidade
relativas aos componentes relevantes ou servios de apoio.

ITIL V3 - Service Design - Pgina:

184 de 477

O termo Funo de Negcios Vital (VBF) usada para refletir os elementos


crticos de negcio do processo de negcio suportados por um De servios de
TI. Um servio de TI pode suportar um nmero de funes de negcios que so
menos crticos. Por exemplo, um caixa automtico (ATM) ou em dinheiro VBF
servio dispensador seria a distribuio do dinheiro. No entanto, a capacidade
de obter uma indicao de um ATM no pode ser considerada como essencial.
Esta distino importante e deve influenciar o desenho disponibilidade e
associados custars. A mais vital do negcio funo em geral, quanto maior o
nvel de resilincia e disponibilidade que tem de ser incorporada no projeto
necessria nos servios de suporte de TI. Para todos os servios, quer VBFs ou
no, os requisitos de disponibilidade dever ser determinada pela negcio e no
pela TI. As metas de disponibilidade iniciais so muitas vezes fixados em um
nvel muito alto, e isso leva a tanto sobre preo de servios ou iterativo
discusso entre o provedor de servios eo negcio de concordar um equilbrio
adequado entre a disponibilidade do servio e os custos do servio e sua
tecnologia de apoio.
VBFs certos pode precisar de projetos especiais, que esto agora a ser
utilizados como uma questo de curso dentro Design de Servios planos, que
inclui:

Alta disponibilidade: A caracterstica do servio de TI que minimiza ou


mscaras de falha os efeitos do componente de TI para o usurios de um
servio.
A tolerncia a falhas: A capacidade de um servio de TI, componente CI
ou para continuar a operar correctamente depois falha de uma parte do
componente.
A operao contnua: Uma abordagem ou projeto para eliminar tempo de
inatividade planejado de um servio de TI. Observe que os componentes
individuais ou cis pode ser para baixo, mesmo que o servio de TI
permanece disponvel.
Disponibilidade contnua: Uma abordagem ou desenho para atingir 100%
de disponibilidade. Um continuamente disponvel De servios de TI no
tem tempo de inatividade planejado ou no.

Muitos fornecedors comprometer com alta disponibilidade ou solues de


disponibilidade contnua somente se rigorosos padres ambientais e resistente
processoes so usados. Eles muitas vezes concordam em tais contratos
somente aps um levantamento do local foi concluda e adicionais, s vezes
caros, melhorias foram feitas.
Gerenciamento de Disponibilidade comea assim que os requisitos de
disponibilidade de um servio de TI so claras o suficiente para ser articulada.
um processo contnuo, terminando somente quando o servio de TI
desclassificada ou aposentado. As principais atividades do processo de
Gerenciamento de Disponibilidade so:

ITIL V3 - Service Design - Pgina:

185 de 477

Determinar os requisitos de disponibilidade do negcio por um novo ou


aprimorado de servios de TI e de formular a disponibilidade e
recuperao critrios de projeto para os componentes de suporte de TI
Determinar as VBFs, em conjunto com o negcio e ITSCM
Determinando o impacto resultante de servio de TI e falha do
componente em conjunto com ITSCM e, se for caso disso, a reviso dos
critrios de concepo de disponibilidade para fornecer adicionais
resilincia para evitar ou minimizar o impacto para a negcio
Definir os objectivos para disponibilidade, Confiabilidade e manuteno
para o Infra-estrutura de TI componentes que sustentam o servio de TI
para permitir que estas sejam documentadas e acordadas no mbito
SLAs, e OLAs contratos
Estabelecimento de medidas e relatrios de disponibilidade, confiana ea
facilidade de manuteno que refletem o negcio, usurio e suporte de TI
organizao perspectivas
Monitoramento e anlise de tendncias dos componentes de
confiabilidade, disponibilidade e capacidade de manuteno de TI
Reviso de servios de TI e disponibilidade de componentes e identificar
os nveis inaceitveis
Investigar as razes subjacentes para inaceitvel disponibilidade
Produo e manuteno de um Plano de disponibilidade que prioriza e
planeja melhorias a disponibilidade de TI.

4.4.5 as atividades de processo, mtodos e tcnicas


O Gerenciamento de Disponibilidade processo depende fortemente da medio
de servio e as realizaes de componentes que respeita disponibilidade.
"Se voc no medir, voc no pode control-lo '
"Se voc no medir, voc no pode melhor-lo '
"Se voc no medir, voc provavelmente no se importa '
"Se voc no pode influenciar ou controlar, ento no medir '
'O que medir e como denunci-lo "inevitavelmente depende de qual atividade
est a ser apoiada, que os destinatrios so e como a informao para ser
utilizado. importante reconhecer as diferentes perspectivas de disponibilidade
para assegurar satisfaz medio e elaborao de relatrios a essas
necessidades variadas:

O perspectiva de negcios considera De servios de TI disponibilidade


em termos de sua contribuio ou impacto sobre os VBFs que
impulsionam o negcio operao.

ITIL V3 - Service Design - Pgina:

186 de 477

A perspectiva do usurio considera a disponibilidade do servio como


uma combinao de trs fatores, ou seja, a frequncia, a durao ea
escopo de impacto, ou seja, todos os usurios, alguns usurios, todas as
funes de negcios ou determinadas funes empresariais - o usurio
considera tambm a disponibilidade do servio em termos de tempo de
respostas. Para muitos de desempenho centrada aplicaos, os tempos
de resposta pobres so considerados iguais em termos de impacto para
falhas da tecnologia.
O Provedor de servios de TI perspectiva considera o servio de TI e
disponibilidade de componentes em relao ao disponibilidade,
Confiabilidade e facilidade de manuteno.

A fim de satisfazer as diferentes perspectivas de disponibilidade, gerenciamento


de disponibilidade deve considerar o espectro de medidas necessrias para
informar o nvel de "mesmo" de disponibilidade de formas diferentes. Medidas
precisam ser significativa e agregar valor se a medio de disponibilidade e de
informao so, em ltima anlise para entregar benefcios para a TI e as
organizaes empresariais. Esta fortemente influenciada pela combinao 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 servio e componente disponibilidade


A sada a partir da chave Gerenciamento de Disponibilidade processo a
medio e comunicao de TI a disponibilidade. Disponibilidade medidas devem
ser incorporadas SLA, OLA e qualquer subjacente contratos. Estes devem ser
revistos regularmente em Nvel de Servio rever reunies. Medio e
comunicao proporcionam a base para:

Monitorando o real disponibilidade alvos entregues contra concordaram


Estabelecer medidas de disponibilidade e concordar metas de
disponibilidade com o negcio
Identificar os nveis inaceitveis de disponibilidade que o impacto negcio
e os usurios
Revendo disponibilidade com o suporte de TI organizao
Atividades de melhoria contnua para otimizar disponibilidade.

As organizaes prestadoras de servios de TI que, por muitos anos, medida e


informou sobre sua perspectiva de disponibilidade. Tradicionalmente, essas
medidas tm se concentrado na disponibilidade de componentes e tm sido um
pouco divorciada do negcio e usurio pontos de vista. Tipicamente, estas
medidas tradicionais baseiam-se numa combinao de uma percentagem
disponibilidade (%), perda de tempo e a frequncia de falha. Alguns exemplos
destas medidas tradicionais so os seguintes:

ITIL V3 - Service Design - Pgina:

187 de 477

Por cento disponvel - 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 servio. Ele geralmente usado para
rastrear e relatar conquista contra um alvo de nvel de servio. Isso tende
a valorizar o 'nmero grande "de tal forma que, se o meta de nvel de
servio foi de 98,5% e para a realizao foi de 98,3%, ento no parece
to ruim. Isso pode estimular um comportamento complacente da
organizao de suporte de TI.
Por cento indisponvel - O inverso do acima. Essa representao, no
entanto, tem a vantagem de se concentrar em no-disponibilidade.
Baseado no exemplo acima, se o alvo para a no-disponibilidade de
1,5% e para a realizao foi de 1,7%, em seguida, esta uma diferena
muito maior relativo. Esse mtodo de comunicao mais provvel que
criar a conscincia da diferena na entrega do nvel de disponibilidade
exigido.
Durao - Obtido atravs da converso a percentagem disponvel 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 tendncia que leva a um adicional
de quatro dias de no-disponibilidade para a empresa durante um ano
inteiro. Este tipo de medida e relatrios mais susceptvel de encorajar
foco na melhoria dos servios.
Freqncia de falha - Utilizado para registrar o nmero de interrupes
no servio de TI. Ela ajuda a fornecer uma boa indicao de confiana a
partir de um usurio perspectiva. melhor usado em combinao com a
"durao" para ter uma viso equilibrada do nvel de interrupo do
servio e da durao do tempo perdido para o negcio.
Impacto de falha - Esta a verdadeira medida de indisponibilidade do
servio. Ela depende maduro incidente gravao onde a incapacidade de
usurios para realizar tarefas de seus negcios a mais importante pea
de informao capturada. Todas as outras medidas sofrem de um
potencial para mascarar os efeitos reais de falha de servio e muitas
vezes so convertidos em um impacto financeiro.

O negcio pode ter, por muitos anos, aceitou que a disponibilidade de TI que a
experincia representada em termos de disponibilidade de componentes e no
global servio ou de negcios disponibilidade. No entanto, isso no mais visto
como aceitvel eo negcio est ansiosa para melhor representar a
disponibilidade de medida (s) que mostram as conseqncias positivas e
negativas de a disponibilidade de TI em seus negcios e usurios.
As medies de disponibilidade mais importantes so aqueles que refletem e
medir a disponibilidade do negcio e usurio perspectiva.

ITIL V3 - Service Design - Pgina:

188 de 477

Gerenciamento de Disponibilidade preciso considerar a disponibilidade de


ambos um negcio / TI provedor de servios perspectiva e do ponto de vista de
componentes de TI. Estes so aspectos totalmente diferentes, e enquanto o
conceito subjacente semelhante, na medida, foco e impacto so inteiramente
diferentes.
O nico propsito de produzir essas medidas disponibilidade e relatrios,
incluindo os da perspectiva de negcios, o de melhorar o qualidade e
disponibilidade dos servios de TI fornecidos para a empresa e os usurios.
Todas as medidas, relatrios e as atividades devem refletir esta finalidade.
Disponibilidade, quando medido e indicado para refletir a experincia do usurio,
Fornece uma viso mais representativa em geral De servios de TI qualidade. O
usurio ver de disponibilidade influenciada por trs fatores:

Freqncia de tempo de inatividade


Durao do tempo de inatividade
Escopo de impacto.

Medies e relatrios de disponibilidade usurio deve, pois, contemplar esses


fatores. A metodologia empregada para refletir a disponibilidade do usurio
poderia considerar duas abordagens:

Impacto por minuto usurio perdido: Esta a base de clculos sobre a


durao do tempo de inactividade, multiplicado pelo nmero 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 tambm incluir o custars de recuperao por perda de
produtividade (por exemplo, pagamento de horas extras aumentou).
Impacto de negcios transao: Esta a base de clculo do nmero de
transaes comerciais que no pde ser processado durante o perodo
de inatividade. Isto proporciona uma melhor indicao do impacto
comercial reflectindo diferentes perfis de processamento de transaco
atravs da hora do dia, etc semana, em muitos casos, pode ser o caso de
que o usurio impacto correlaciona com uma VBF, e.g. se o usurio
recebe ordens de compra dos clientes e um VBF de vendas dos
clientes. Esta medida simples a base para refletir o impacto para o
negcio operao e do usurio.

O mtodo utilizado deve ser influenciada pela natureza da operao de negcio.


A operao de negcio de suporte de dados de atividade entrada bem
adequado ao relatrio que reflete usurio perda de produtividade. Operaes
comerciais que so mais voltados para o cliente, por exemplo, Servios ATM,
beneficiar de relatrios transao impacto. Tambm deve ser notado que no
impacto todos os negcios de uso relacionado. Com crescente automao e

ITIL V3 - Service Design - Pgina:

189 de 477

processamento eletrnico, a capacidade de processar transaes automatizadas


ou atender o mercado de corte vezes tambm pode ter um grande impacto
financeiro que pode ser maior do que a capacidade dos usurios para o
trabalho.
O suporte de TI organizao precisa ter um conhecimento apurado da
experincia do usurio de disponibilidade. No entanto, os benefcios reais vm
de agregar a viso do usurio para a visualizao geral dos negcios. Um
princpio orientador da Gerenciamento de Disponibilidade processo que
"Melhorar a disponibilidade s pode comear quando a tecnologia forma suporta
o negcio compreendido". Portanto gerenciamento de disponibilidade no
apenas sobre a compreenso da disponibilidade de cada TI componente, Mas
tudo sobre a compreenso do impacto da falha de um componente no servio e
disponibilidade do usurio. Do ponto de vista comercial, um servio de TI s
pode ser considerado disponvel quando o negcio capaz de realizar todas
funo de negcios vitals necessrio para conduzir a operao do negcio. Para
o servio de TI para estar disponvel, por isso, depende de todos os
componentes em que a servio depende sendo disponveis, ou seja, sistemas,
componentes principais, rede de dados e aplicaos.
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 operao do negcio depende. Esta abordagem assegura que
os SLAs de TI e comunicao disponibilidade so baseados em medidas que
so entendidos por ambas as empresas e de TI. Ao medir os VBFs que
dependem de servios de TI, medio e elaborao de relatrios torna-se
orientado a negcios, com o impacto da falha refletindo as conseqncias para o
negcio. Tambm importante que a disponibilidade dos servios definido e
acordado com o negcio e refletida dentro de SLAs. Esta definio de
disponibilidade deve incluir:

Qual o nvel mnimo de funcionalidade disponvel do servio?


Em que nvel de resposta do servio o servio considerado
indisponvel?
Onde que este nvel de funcionalidade e de resposta ser medido?
Quais so os pesos relativos de indisponibilidade parcial do servio?
Se um local ou escritrio afetado, considerado todo o servio
indisponvel ou esta considerada "indisponibilidade parcial"? Isso
precisa ser acordado com o clientes.

Ferramentas de relatrios e anlise so necessrios para a manipulao 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 so muitas vezes uma combinao dos dois. Isto vai ser
influenciada pelas tecnologias de banco de dados de repositrio seleccionados e

ITIL V3 - Service Design - Pgina:

190 de 477

da complexidade do processamento de dados e relatrio necessrio.


Gerenciamento de Disponibilidade, uma vez implementado e implantado, sero
necessrios para produzir relatrios regulares sobre uma base de acordo, por
exemplo, relatrios mensais de disponibilidade, Plano de disponibilidade,Anlise
de falha de servio Relatrios (SFA) de status, etc As atividades envolvidas
nessas atividades de relatrios podem exigir esforo manual muito ea nica
soluo automatizar o mximo de gerao de relatrio atividade quanto
possvel. Para efeitos de relatrios, padres de relatrios organizacionais devem
ser utilizados sempre que possvel. Se estes no existirem, as normas devem
ser desenvolvidos de modo que os relatrios podem ser desenvolvidos usando
as ferramentas padro e tcnicas. Isto significa que a integrao e consolidao
de relatrios posteriormente ser muito mais fcil de conseguir.
Anlise de indisponibilidade
Todos os eventos e incidentes que causam indisponibilidade de servios e
componentes devem ser investigadas, com aes corretivas a ser aplicado
dentro ou a disponibilidade Plano ou o SIP geral. Tendncias devem ser
produzidos a partir dessa anlise para dirigir e concentrar atividades como
Anlise de Falhas de Servio (AGS) para as reas causando mais impacto ou
interrupo dos negcios e da usurios.
Os custos globais de um De servios de TI so influenciadas pelos nveis de
disponibilidade necessrio e os investimentos necessrios em tecnologia e
servios prestados pela organizao de suporte de TI para atender a essa
exigncia. Disponibilidade certamente no vem de graa. No entanto,
importante indicar que a indisponibilidade de TI tambm tem um custo, portanto,
no livre indisponibilidade ou. Para o negcio altamente crtica processoes e
VBFs, preciso considerar no apenas o custo da prestao do servio, mas
tambm os custos que so suportados a partir de falha. O equilbrio ptimo para
golpear o custo da soluo disponibilidade comparadas com os custos de
indisponibilidade.
Antes de qualquer SLR aceito, e, finalmente, o SLR ou SLA negociado e
acordado entre o negcio ea organizao de TI, essencial que os requisitos de
disponibilidade do negcio so analisados para avaliar se / como o servio de TI
pode entregar os nveis requeridos de disponibilidade. Isto aplica-se no s a
novos servios de TI que esto a ser introduzidas, mas tambm a qualquer
pedido mudars para os requisitos de disponibilidade dos actuais servios de TI.
O custar de uma falha que poderia simplesmente ser expresso como o nmero
de negcios ou TI transaos impactados, quer como um nmero real (derivado
de instrumentao) ou com base em um estimativa. Quando medido contra os
VBFs que suportam o negcio operao, O que pode proporcionar uma
indicao bvia de a consequncia da falha. A vantagem dessa abordagem a
relativa facilidade de obteno dos dados de impacto e da falta de quaisquer

ITIL V3 - Service Design - Pgina:

191 de 477

clculos complexos. Torna-se tambm um "valor" que compreendido por


ambas as empresas e organizao de TI. Isso pode ser o estmulo para a
identificao de oportunidades de melhoria e pode se tornar uma chave mtrico
no controlo da disponibilidade dos servios de TI.
A principal desvantagem desta abordagem que ela no oferece bvio valor
monetrio que seria necessrio para justificar quaisquer decises de
investimento financeiros significativos para melhorar a disponibilidade. Onde
importantes decises de investimento financeiro so necessrios, melhor para
expressar o custo do fracasso decorrente de servio, A aplicao do sistema, ou
funo perda para o negcio como um "valor" monetrio.
O valor monetrio pode ser calculada como uma combinao dos custos
associados ao insucesso tangveis, mas tambm pode incluir uma srie de
custos intangveis. O valor monetrio tambm deve refletir o impacto do custo
para o conjunto organizao, Ou seja, o negcio ea organizao de TI.
Custos tangveis podem incluir:

Perdido usurio produtividade


Perdeu a produtividade da equipe
Perda de receita
Pagamento de horas extraordinrias
Bens e materiais desperdiados
Imps multas e sanes pecunirias.

Estes custars so muitas vezes bem compreendida pela rea financeira do


negcio e de TI, organizao e em termos relativos so mais fceis de obter e
agregado do que os custos intangveis associados com TI falha.
Custos intangveis podem incluir:

Perda de clientes
Perda da boa vontade do cliente (insatisfao do cliente)
Perda de oportunidade de negcio (vender, conquistar novos clientes ou
de receita, etc)
Danos reputao do negcio
Perda de confiana no Provedor de servios de TI
Danificar a moral do pessoal.

importante no apenas para descartar o intangvel custars (e as possveis


consequncias), alegando que eles podem ser difceis de medir. A
indisponibilidade geral do servio, o custo total tangvel e os custos intangveis
totais decorrentes indisponibilidade do servio so todas as mtricas-chave na
medio da eficcia do Gerenciamento de Disponibilidade processo.

ITIL V3 - Service Design - Pgina:

192 de 477

O ciclo de vida do incidente expandida


Um princpio norteador de gerenciamento de disponibilidade reconhecer que
ainda possvel ganhar a satisfao do cliente, mesmo quando as coisas do
errado. Uma abordagem para ajudar a atingir este requer disponibilidade de
Gesto para garantir que a durao de uma eventual incidente minimizada
para permitir normais operaes comerciais para retomar o mais rapidamente
possvel. Um objectivo de gerenciamento de disponibilidade garantir a durao
e impacto de incidentes impactando De servios de TIs so minimizadas, para
permitir que as operaes comerciais de retomar o mais rapidamente possvel. A
anlise da 'ciclo de vida do incidente expandida'Permite que o servio de TI total
de tempo de inatividade por qualquer incidente dado ser discriminados e
mapeados contra as grandes etapas atravs das quais todos os progressos
incidentes (o ciclo de vida). Gerenciamento de Disponibilidade deve trabalhar em
estreita colaborao com Gerenciamento de Incidentes e Gerenciamento de
Problemas Na anlise de todos os incidentes que causam indisponibilidade.
Uma boa tcnica para ajudar com a anlise tcnica dos incidentes que afectam
a disponibilidade de componentes servios e de TI ter viso 'ciclo de vida' de
um incidente. Cada incidente passa por vrias fases principais. O tempo
decorrido nestas fases pode variar consideravelmente. Para fins de
gerenciamento de disponibilidade, "ciclo de vida" do incidente padro, como
descrito em Gerenciamento de Incidentes, foi ampliado para fornecer ajuda e
orientao especificamente na rea de "projetar para recuperao'. 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 - Pgina:

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 gesto para evento e
incidente deteco, Captura de dados de diagnstico requisitos e ferramentas
para diagnstico, Planos de recuperao para ajudar na recuperao rpida e
como verificar se o servio de TI foi restaurado. As fases individuais do ciclo de
vida so consideradas com mais pormenor como se segue.

Deteco de incidentes: O momento em que o IT provedor de servios


organizao 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 nveis de
disponibilidade que podem ser entregues. Implementao e explorao
deve ter um forte foco em atingir alta disponibilidade e reforada
recuperao objetivos. No contexto da recuperao, essas ferramentas
devem ser exploradas para proporcionar a deteco automtica de falhas,
auxiliar no diagnstico de falhas e suporte automatizado erro
recuperao, com respostas script. Ferramentas so muito importantes
na reduo de todas as etapas do ciclo de vida do incidente, mas,
principalmente, a deteco de eventos e incidentes. Idealmente, o evento
automaticamente detectado e resolvido, antes da usurios ter notado ou
foram impactadas de forma alguma.
Diagnstico incidente: O tempo em que o diagnstico para determinar a
causa subjacente tenha sido concluda. Quando a TI componentes falhar,
importante que o nvel requerido de diagnstico capturada, para
permitir a determinao do problema para identificar o causa raiz e
resolver o problema. A utilizao e capacidade de ferramentas de
diagnstico e habilidades fundamental para a rpida resoluo de
questes de servio. Por certo falhas, a captura de diagnstico pode
estender o tempo de inatividade do servio. No entanto, a captura no
dos diagnsticos apropriados cria e expe o servio de repetir falhas.
Onde o tempo requerido para levar o diagnstico considerado
excessivo, ou que varia desde o alvo, um rever deve ser iniciada para
identificar se as tcnicas e / ou procedimentos pode ser simplificada para
reduzir o tempo necessrio. Igualmente o escopo dos dados de
diagnstico disponvel para a captura pode ser avaliada para assegurar
que apenas os dados de diagnstico consideradas essenciais tomado.
O tempo de inatividade adicional necessria para capturar diagnsticos
deveriam ser includos na recuperao mtricos 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 servios fornecidos externamente e fornecedor atuao.

ITIL V3 - Service Design - Pgina:

194 de 477

Sempre que forem observadas quebras, tcnicas devem ser usados para
reduzir ou eliminar as falhas de incidentes semelhantes no futuro.
Recuperao de incidentes: O momento em que a recuperao de
componentes tenha sido concluda. O apoio e requisitos de recuperao
para os componentes subjacente a uma nova De servios de TI devem
ser identificados o mais cedo possvel no ciclo de design. Estes requisitos
devem cobrir hardware, software e dados e de recuperao. O resultado
disto atividade deve ser um conjunto de requisitos de recuperao
documentado que permite que o desenvolvimento de planos de
recuperao apropriados. Para antecipar e se preparar para a realizao
de recuperao tal reintegrao de que o servio eficaz e eficiente exige
o desenvolvimento e teste de recuperao adequado planos com base
nos requisitos de recuperao documentados. Sempre que possvel, o
operacional atividades dentro da recuperao plano deve ser
automatizado. O teste dos planos de recuperao tambm oferece
horrios aproximados para a recuperao. Essas mtricas de
recuperao pode ser usado para apoiar a comunicao de recuperao
estimado de servio e validar ou melhorar o componente falha
documentao Anlise de Impacto. Gerenciamento de Disponibilidade
deve continuamente buscar e promover mtodos mais rpidos de
recuperao para todos os incidentes potenciais. Isto pode ser
conseguido atravs de uma variedade de mtodos, incluindo a no
automatizada deteco, Recuperao automatizado, mais rigorosas
escalada procedimentos, explorao de ferramentas de recuperao de
novas e mais rpidas e tcnicas. Os requisitos de disponibilidade devem
tambm contribuir para determinar que peas de reposio so mantidos
dentro das Peas definitivas para facilitar reparos rpidos e eficazes,
como descrito no Transio de Servio publicao.
Restaurao incidente: O tempo no qual normais servio de negcio
retomada. Um incidente s pode ser considerado 'fechado'Uma vez o
servio foi restaurado e comercial normal operao foi retomado.
importante que o restaurado de servios de TI verificado como trabalhar
corretamente assim que a restaurao do servio concludo e antes de
qualquer equipe tcnica envolvida no incidente so permaneceu baixo.
Na maioria dos casos, isso simplesmente um caso de obter a
confirmao de que os usurios afetados. No entanto, os usurios de
alguns servios pode ser clientes do negcio, ou seja, servios de caixa
eletrnico, de servios de Internet. Para estes tipos de servios,
recomenda-se que o servio de TI verificao procedimentos so
desenvolvidos para permitir a Provedor de servios de TI organizao
para verificar se um restaurado de servios de TI agora est trabalhando
como esperado. Estes poderiam ser simplesmente controlos visuais
transao rendimento ou scripts de usurio de simulao que validam o
servio end-to-end.

ITIL V3 - Service Design - Pgina:

195 de 477

Cada fase, e o tempo associado tomadas, influencia o total tempo de inatividade


percebido pela usurio. Ao adotar essa abordagem, possvel ver que o tempo
est sendo "perdido" para a durao de um incidente. Por exemplo, o servio
no estava disponvel para o negcio por 60 minutos, mas levou apenas cinco
minutos para aplicar uma correo - onde os outros 55 minutos vo?
Usando essa abordagem identifica possveis reas de ineficincia que se
combinam para tornar a perda de servio experimentado pelo negcio maior do
que o necessrio. Estes poderiam abranger reas como automao pobres
(alertars, recuperao automtica etc), pobres ferramentas de diagnstico e
scripts, claro escalao procedimentos (o que demora a escalada para o
apropriado grupo de suporte tcnico ou fornecedor), Ou falta de documentao
operacional abrangente. Gerenciamento de Disponibilidade deve trabalhar em
estreita associao com a Incidentes e Gerenciamento de Problemas para
assegurar ocorrncias repetidas so eliminados. Recomenda-se que estas
medidas so estabelecidas e capturado para todos os incidentes disponibilidade.
Isto proporciona Gerenciamento de Disponibilidade com mtricos para ambos os
incidentes especficos e informaes de tendncias. Esta informao pode ser
usada como entrada para SFA atribuies, atividades SIP e relatrios de gesto
regular Disponibilidade e para fornecer um impulso para a melhoria contnua
atividade para prosseguir melhoramentos rentveis. Ele tambm pode permitir a
fixao de objectivos para fases especficas do ciclo de vida do incidente.
Embora admitindo que cada incidente pode ter uma ampla gama de
complexidade tcnica, os alvos podem ser usados de modo a reflectir a
consistncia da forma como a TI provedor de servios organizao responde a
incidentes.
Uma sada do Gerenciamento de Disponibilidade processo a requisitos de
monitoramento em tempo real para De servios de TIs e componentes. Para
atingir os nveis de disponibilidade necessria e / ou assegurar a rpida
restaurao do servio na sequncia de um IT falha requer investimento e
explorao de um conjunto de ferramentas de gerenciamento de sistemas.
Ferramentas de gerenciamento de sistemas, so um elemento essencial para os
servios de TI que requerem um alto nvel de disponibilidade e pode fornecer um
valor inestimvel papel em reduzir a quantidade de tempo de inatividade
incorridos. Requisitos de gerenciamento de disponibilidade cobrir a deteco e
alerta de TI servio e excees de componentes, escalao automatizada e
notificao de falhas de TI e da recuperao automatizada e recuperao dos
componentes de situaes de falha conhecido. Isto faz com que seja possvel
identificar onde "tempo perdido e proporciona a base para a identificao de
factores que podem melhorar os tempos de recuperao e de restaurao.
Estas atividades so realizadas em uma base regular dentro Operao de
Servio.
Anlise de falha de servio

ITIL V3 - Service Design - Pgina:

196 de 477

Anlise de falha de servio (SFA) uma tcnica destinada a proporcionar uma


abordagem estruturada para identificar as causas das interrupes de servio
para o usurio. SFA utiliza uma variedade de fontes de dados para avaliar onde
e por deficincias na disponibilidade esto ocorrendo. SFA permite uma viso
holstica do ser tomados para no impulsionar melhorias apenas de tecnologia,
mas tambm melhorias no suporte de TI da organizao, processos,
procedimentos e ferramentas. SFA executado como uma tarefa ou projeto, E
pode utilizar mtodos disponibilidade outros e tcnicas de gesto para formular
as recomendaes de melhoria. A anlise detalhada das interrupes de servio
podem identificar oportunidades para melhorar os nveis de disponibilidade. SFA
uma tcnica estruturada para identificar oportunidades de melhoria no fim-definal a disponibilidade do servio, que pode trazer benefcios para o usurio.
Muitas das atividades envolvidas na SFA esto estreitamente alinhados com os
de Gerenciamento de Problemas, e em um nmero de organizaes essas
atividades so realizadas em conjunto pela Problema e Gerenciamento de
Disponibilidade.
O alto nvel objetivos de SFA so:

Para melhorar a disponibilidade global de servios de TI atravs da


produo de um conjunto de melhorias para a implementao ou de
entrada para o Plano de disponibilidade
Para identificar as causas de interrupo do servio aos usurios
Para avaliar o eficcia do suporte de TI e processos de organizao
chave
Para produzir relatrios detalhando as principais concluses e
recomendaes
Que as melhorias Disponibilidade derivados de SFA-driven atividades so
medidos.

Iniciativas SFA deve usar a entrada de todas as reas e todos os processos,


incluindo, principalmente, o negcio e usurios. Cada atribuio SFA deve ter
um patrocinador reconhecido (s) (de preferncia, o patrocnio conjunto da TI e
de negcios) e envolver recursos de diversas reas tcnicas e de processo. A
utilizao da abordagem SFA:

Fornece a capacidade de oferecer melhores nveis de disponibilidade sem


grande custar
Fornece o negcio com o compromisso visvel da organizao de suporte
de TI
Desenvolve-se em casa de habilidades e competncias para evitar
atribuies 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 - Pgina:

197 de 477

pensamentos tradicionais e fornecendo inovador, de baixo custo e, muitas


vezes, solues
Fornece uma programa de oportunidades de melhoria que podem fazer
uma diferena real para o servio qualidade e usurio percepo
Oferece oportunidades que esto focados em oferecer benefcio para o
usurio
Fornece um "exame de sade" independente de IT Service Management
processos e o estmulo para melhorias de processo.

Para maximizar o tempo de indivduos afectados atribuio SFA e a qualidade


do relatrio entregue, uma abordagem estruturada necessria. Esta estrutura
ilustrada na Figura 4.16. Esta abordagem semelhante a muitos consultoria
modelos utilizados na indstria, 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 Anlise de Falhas de Servio (AGS)

A estrutura de alto nvel acima descrito resumidamente como se segue.

ITIL V3 - Service Design - Pgina:

198 de 477

Selecione oportunidade: Antes de agendar uma atribuio SFA,


necessrio que haja acordo quanto ao que De servios de TI ou
tecnologia para ser selecionado. Recomenda-se que um nmero
acordado de atribuies so programadas por ano dentro do Plano de
disponibilidade e, se possvel, os servios de TI so selecionados com
antecedncia como parte da abordagem proativa para Gerenciamento de
Disponibilidade. Antes de se iniciar com o SFA, importante que a
atribuio tem um promotor reconhecido a partir da organizao de TI e /
ou o negcio e que eles esto envolvidos e atualizado regularmente com
o progresso da SFA atividade. Isso garante visibilidade organizacional
SFA e garante recomendaes so aprovados em um nvel snior dentro
da organizao.
Escopo atribuio: Esta a declarar explicitamente que reas so e no
so cobertas pela atribuio. Isto normalmente documentada em
Termos de referncia emitidos antes da atribuio.
Plano de atribuio: A atribuio SFA precisa ser planejado um nmero
de semanas de antecedncia da atribuio incio, com um acordo projeto
plano e um conjunto de recursos comprometidos. O projeto deve olhar
para a identificao de oportunidades de melhoria que beneficiem a
usurio. Portanto, importante que uma viso fim-a-fim dos dados e
Sistema de Gerenciamento de Informaes (MIS) requisitos tomada. Os
dados e documentos devem ser recolhidas e analisadas todas as reas
do usurio e perspectiva de negcios. Um "virtual" time SFA deve ser
formado a partir de todas as reas relevantes para assegurar que todos
os aspectos e perspectivas so considerados. O tamanho da equipe deve
refletir o escopo e complexidade do servio SFA.
Construir hiptese: Este um mtodo til de construo de cenrios
provveis, que podem ajudar a equipe do estudo tirar concluses iniciais
dentro do perodo de anlise. Esses cenrios podem ser construdos a
partir de discutir a atribuio prxima com a chave papels, por exemplo,
alta administrao e os usurios, ou usando o planejamento sesso de
brainstorm a lista da equipe montada. A lista completa hipteses devem
ser documentados e entrada para o perodo de anlise para fornecer
algum foco inicial dos dados e Sistema de Gerenciamento de Informaes
(MIS) que coincidem com os cenrios individuais. Deve notar-se que esta
abordagem tambm elimina os problemas percebidos, isto , no existem
dados ou MIS substancia que percebido como um servio questo.
Analisar os dados: O nmero de pessoas que formam a equipe SFA dita
como atribuir responsabilidades especficas de anlise. Durante este
perodo, a anlise da lista hipteses devem ser usados para ajudar a
extrair algumas concluses iniciais.
Pessoal-chave da entrevista: essencial que os representantes-chave
de negcios e usurios so entrevistados para garantir o negcio e
usurio perspectivas so capturados. surpreendente como este dilogo
pode identificar oportunidades de ganhos rpidos, como muitas vezes o
que a empresa v como um grande problema pode ser resolvido atravs

ITIL V3 - Service Design - Pgina:

199 de 477

de uma soluo de TI simples. Portanto, essas entrevistas deve ser


iniciado o mais cedo possvel dentro da atribuio SFA. A equipe de
estudo tambm deve procurar a entrada de pessoas-chave dentro da
Provedor de servios de TI organizao para identificar reas
problemticas e possveis solues adicionais que podem ser
alimentadas de volta para a equipe de estudo. O dilogo tambm ajuda a
capturar aquelas questes que no so facilmente visveis a partir dos
dados reunidos e relatrios MIS.
Resultados e concluses: Aps a anlise dos dados fornecidos e MIS,
entrevistas e re contnuaviso da lista de hipteses, a equipe de estudo
deve estar em uma posio para comear a documentar os resultados
iniciais e concluses. Recomenda-se que a equipe de atender
imediatamente aps o perodo de anlise para compartilhar suas
descobertas individuais e, em seguida, ter uma viso agregada para
formar os resultados preliminares e as concluses. importante que os
resultados podem ser comprovadas atravs de dados recolhidos durante
a anlise. Durante esta fase do trabalho, pode ser necessrio para validar
encontrar (s) por uma anlise adicional para garantir a equipe SFA pode
fazer backup de todos os resultados com evidncias documentadas claro.
Recomendaes: Depois de todos os resultados e as concluses foram
validadas, a equipe SFA deve estar em condies de formular
recomendaes. Em muitos casos, as recomendaes para apoiar uma
concluso particular, so simples e bvio. No entanto, o benefcio de
trazer uma equipe multifuncional juntos para a atribuio SFA criar um
ambiente para o pensamento inovador-lateral abordagens. O lder
atribuio SFA deve facilitar esta sesso com o objectivo de identificar as
recomendaes que so prticos e sustentveis, uma vez implementado.
Relatrio: O relatrio final deve ser entregue ao patrocinador com um
resumo de gesto. Estilos de relatrios normalmente so determinados
pelas organizaes individuais. importante que o relatrio mostra
claramente que a perda de disponibilidade est sendo incorridos e como
as recomendaes resolver esta questo. Se o relatrio contm vrias
recomendaes, uma tentativa dever ser feita para quantificar a
vantagem da disponibilidade de cada uma recomendao, juntamente
com o esforo estimado de implementar. Isto permite escolhas
informadas a ser feito sobre a forma de receber as recomendaes para a
frente e como estes devem ser priorizados e com recursos.
Validao: Recomenda-se que para cada SFA, medidas-chave que
refletem o negcio e usurio perspectivas antes da atribuio so
capturados e registrado como o 'antes' vista. Como recomendaes SFA
esto progredindo, o positivo impactos de disponibilidade dever ser
capturada para proporcionar o ponto de vista do "depois" para fins
comparativos. Onde os benefcios esperados no foram entregues, esta
deve ser investigada e aes corretivas tomadas. Depois de ter investido
tempo e esforo em completar a tarefa SFA, importante que as
recomendaes, uma vez aprovadas pelo patrocinador, ento, so

ITIL V3 - Service Design - Pgina:

200 de 477

levados para a frente para a implementao. O melhor mecanismo para


conseguir isso atravs da incorporao das recomendaes como
atividades para ser concludo 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 eficcia.
Considere categorizar as recomendaes sob os seguintes ttulos:
DETECO: Recomendaes que, se implementado, vai fornecer relatrios
reforada de indicadores-chave para garantir TI subjacente questes de servio
so detectados cedo para permitir uma resposta pr-ativa.
REDUO: Recomendaes que, se implementado, vai reduzir ou minimizar o
usurio impacto da TI interrupo do servio, por exemplo, recuperao e / ou
restaurao pode ser melhorado para reduzir a durao do impacto.
PREVENO: Recomendaes que, se implementado, ir eliminar esta causa
especial de De servios de TI interrupo.
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 mtodos e tcnicas pr-activas
utilizadas pelo processo. As seguintes atividades so as tcnicas proativas e
atividades do processo de Gerenciamento de Disponibilidade.
Identificao de funes vitais para o negcio (VBFs)
O termo Funo de Negcios Vital (VBF) usada para refletir os elementos
crticos de negcio do processo de negcio suportados por um servio de TI. O
servio pode tambm apoiar as funes de negcio menos crticas e processos,
e importante que os VBFs so reconhecidos e documentados para fornecer o
alinhamento de negcios adequado e se concentrar.
Projetando para disponibilidade
O nvel de disponibilidade exigida pela negcio influencia a global custar do
servio oferecido. Em geral, quanto maior o nvel de disponibilidade requerido
pela empresa, maior o custo. Estes custos no so apenas os contratos da base
de tecnologia da informao e servios necessrios para apoiar o Infra-estrutura
de TI. Os custos adicionais so incorridos na prestao do adequado Servio de
Gesto de processos, sistemas de gesto e ferramentas de alta disponibilidade
solues necessrias para atender os requisitos de disponibilidade mais
rigorosos. O maior nvel de disponibilidade dever ser includa na projeto dos
servios de apoio a mais crtica das VBFs.

ITIL V3 - Service Design - Pgina:

201 de 477

Ao considerar como os requisitos de disponibilidade do negcio devem ser


satisfeitos, importante para assegurar que o nvel de disponibilidade de ser
prevista uma De servios de TI , na verdade, ao nvel necessrio, e acessvel
e economicamente justificvel para o negcio. Figura 4.17 indica os produtos e
processos necessrios para fornecer diferentes nveis de disponibilidade e as
implicaes de custo.

Figura 4.17 Relao entre os nveis de disponibilidade e custos gerais

Produto base e componentes


A aquisio ou desenvolvimento da tecnologia de base de produtos, e
componentes deve ser com base na sua capacidade para cumprir a
disponibilidade e rigoroso confiana requisitos. Estes devem ser considerados
como a pedra angular do projeto disponibilidade. O investimento adicional
necessrio para alcanar nveis ainda mais altos de disponibilidade ser
desperdiado e nveis de disponibilidade no atingida se esses produtos de base
e componentes no so confiveis e propenso a falha.
Sistemas de gesto

ITIL V3 - Service Design - Pgina:

202 de 477

Gerenciamento de sistemas deve fornecer o monitoramento, De diagnstico e


automatizado erro recuperao para permitir rpido deteco e rpida resoluo
de falha de TI potencial e real.
Gesto de processos de servios
Eficaz Servio de Gesto de processos contribuem para os nveis mais altos de
disponibilidade. Processos tais como Gerenciamento de
Disponibilidade,Gerenciamento de Incidentes,Gerenciamento de
Problemas,Gesto da Mudana,Gerenciamento da Configurao, Etc
desempenhar um papel crucial papel na gesto global do servio de TI.
Alta disponibilidade desenho
O projeto para alta disponibilidade tem de considerar a eliminao de SPoFs e /
ou a proviso de componentes alternativos para fornecer o mnimo de
interrupo para o negcio operao deve falha de um componente de TI
ocorrer. O desenho tambm necessita de eliminar ou minimizar os efeitos da
planeada tempo de inatividade para a operao comercial normalmente
necessrio para acomodar operaes de manuteno, a implementao de
mudars para a infra-estrutura de TI ou de aplicativos de negcios. Os critrios de
recuperao deve definir a rpida recuperao e reintegrao de TI servio
como uma chave objetivo dentro do projeto para a fase de recuperao do
design.
Solues especiais com redundncia total
Para abordar disponibilidade contnua na gama de 100% requer solues caras
que incorporam espelhamento completo ou redundncia. Redundncia a
tcnica de melhorar a disponibilidade, usando componentes duplicados. Os
requisitos de disponibilidade estritas a serem cumpridas, estes precisam
trabalhar de forma autnoma em paralelo. Essas solues no esto restritas
apenas aos componentes de TI, mas tambm para os ambientes de TI, ou seja,
centros de dados, fontes de alimentao, ar condicionado e de
telecomunicaes.
Em caso de novos servios de TI esto sendo desenvolvidos, essencial que a
Administrao Disponibilidade leva um projeto adiantado e participar papel na
determinao 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 nvel de disponibilidade exigido. A
importncia dessa participao no incio da projeto da infra-estrutura de TI no
pode ser subestimada. preciso haver um dilogo entre a TI eo negcio, para
determinar o equilbrio entre a percepo de negcios da custar de
indisponibilidade eo custo exponencial de entregar os nveis mais altos de
disponibilidade.

ITIL V3 - Service Design - Pgina:

203 de 477

Como ilustrado na Figura 4.17, existe um aumento significativo nos custos


quando o requisito do negcio maior do que o nvel ptimo de disponibilidade
que a infra-estrutura de TI pode entregar. Esses aumentos de custos so
movidos por grande reformulao da tecnologia e da mudana de requisitos
para o suporte de TI organizao.
importante que o nvel de disponibilidade concebido para o servio
apropriada para as necessidades comerciais, a criticidade da processo de
negcioes sendo apoiado e do oramento disponvel. O negcio deve ser
consultado no incio do Design de Servios ciclo de vida de modo que a
empresa precisa de disponibilidade de um novo ou aprimorado De servios de TI
podem ser avaliados e concordou. Isto particularmente importante quando os
requisitos de disponibilidade rigorosos pode exigir investimento adicional em
Servio de Gesto de processos, servios de TI e Sistema de Gesto de
ferramentas, alta disponibilidade de design e solues especiais com
redundncia total.
provvel que as actividades necessrias para a disponibilidade de TI no pode
ser expressa em termos tcnicos. Gerenciamento de Disponibilidade portanto,
proporciona um importante papel em ser capaz de traduzir os negcios e usurio
requisitos em metas quantificveis disponibilidade e condies. Esta uma
contribuio importante para a TI Design de Servios e fornece a base para a
avaliao do capacidade do projeto de TI e suporte de TI organizao em
atender os requisitos de disponibilidade do negcio.
Os requisitos de negcio para a disponibilidade de TI deve conter, pelo menos:

A definio dos VBFs suportados pelo servio de TI


A definio de TI downtime do servio, isto , as condies em que o
negcio considera o servio de TI para estar disponvel
O impacto nos negcios causado pela perda de servio, Em conjunto com
a associada risco
Requisitos de disponibilidade quantitativos, isto , a medida em que a
actividade de TI tolera servio tempo de inatividade ou servio degradado
As horas de servio necessrios, ou seja, quando o servio prestado
Um avaliao a importncia relativa de diferentes tempos de trabalho
Especfico segurana requisitos
O servio apoio e recuperao capacidade.

Uma vez que o design de tecnologia de TI e suporte de TI organizao so


determinados, o provedor de servios organizao , ento, em posio de
confirmar se os requisitos de disponibilidade podem ser cumpridas. Onde so
identificados dfices dilogo, com a negcio obrigado a apresentar as opes
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 - Pgina:

204 de 477

nveis mais baixos ou mais altos de disponibilidade so necessrios, e para


entender o impacto apropriado e custars associados sua deciso.
Determinando os requisitos de disponibilidade provvel que seja um processo
iterativo processo, Em particular quando existe uma necessidade de equilibrar a
disponibilidade comercial exigncia contra os custos associados. Os passos
necessrios so os seguintes:

Determinar a actividade impacto causada pela perda de servio


A partir dos requisitos de negcios, especifique o disponibilidade,
Confiabilidade e manuteno requisitos para o De servios de TI e
componentes apoiada pelo suporte de TI organizao
De servios de TI e componentes fornecidos externamente, identificar o
manuteno requisitos
Estimar os custos envolvidos no atendimento a disponibilidade, confiana,
Facilidade de manuteno e requisitos de utilizao
Determinar, com o negcio, se os custos identificados no cumprimento
dos requisitos de disponibilidade so justificados
Determinar, a partir do negcio, os custos que possam ser efectuadas a
partir de perda ou degradao do servio
Onde estes so vistos como custo justificado, definir os requisitos de
disponibilidade, confiabilidade, manuteno e manuteno em acordos e
negociar em contratos.

Se os custos so vistos como proibitivo, ou:

Reavaliar a Infra-estrutura de TI projetar e fornecer opes para reduzir


os custos e avaliar as consequncias sobre a disponibilidade, ou
Reavaliar o uso comercial e confiana no servio de TI e renegociar a
disponibilidade metas dentro do SLA.

O processo SLM normalmente responsvel pela comunicao com o negcio


sobre a forma como os seus requisitos de disponibilidade dos servios de TI
esto 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
perodo. Embora os nveis mais altos de disponibilidade muitas vezes pode ser
fornecida pelo investimento em ferramentas e tecnologia, no h justificativa
para a prestao de um maior nvel de disponibilidade do que a necessria e
proporcionada pelo negcio. A realidade que satisfazer requisitos de
disponibilidade sempre um equilbrio entre custo e qualidade. Este o lugar
onde Gerenciamento de Disponibilidade pode jogar uma chave papel na
disponibilidade de otimizao da TI Design de Servios para atender a demanda
crescente disponibilidade enquanto adiar um aumento nos custos.

ITIL V3 - Service Design - Pgina:

205 de 477

Projetando servio de disponibilidade uma chave atividade impulsionado pelo


gerenciamento de disponibilidade. Isso garante que o nvel de disponibilidade de
um servio 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 tcnico da De servios de TI e o alinhamento do interno e externo
fornecedors necessrio para atender os requisitos de disponibilidade do
negcio. Ele deve abranger todos os aspectos da tecnologia, incluindo
infra-estrutura, ambiente, Dados e aplicaos.
Projetando para recuperao: Esta actividade est relacionada com os
pontos de design necessrios para assegurar que, no caso de um servio
de TI falha, O servio e seu apoio componentes pode ser reintegrado
para permitir normais operaes comerciais para retomar o mais
rapidamente possvel. Este novo deve abranger todos os aspectos da
tecnologia.

Alm disso, a capacidade de recuperar rapidamente pode ser um factor crucial.


Em termos simples, pode no ser possvel ou economicamente justificados para
construir um projeto que altamente resistente a falha (s). A capacidade de
atender os requisitos de disponibilidade, dentro dos parmetros 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 servio processo e deve considerar todas as etapas
dentro do ciclo de vida de servios.
A contribuio de gerenciamento de disponibilidade dentro das atividades do
projeto fornecer:

O especificao dos requisitos de disponibilidade de todos os


componentes do servio
Os requisitos para pontos disponibilidade de medio (instrumentao)
Os requisitos para novos sistemas / aumentada e Servio de Gesto de
Assistncia com o Infra-estrutura de TI projeto
A especificao da confiabilidade, manuteno e manuteno requisitos
para componentes fornecidos pelo interno e externo fornecedors
Validao do projeto final para atender os nveis mnimos de
disponibilidade exigidos pela empresa para o servio de TI.

Se os requisitos de disponibilidade no podem ser atendidas, a prxima tarefa


a re-avaliar o Design de Servios e identificar o custo justificado projeto mudars.
Melhorias no design para atender os requisitos de disponibilidade pode ser
alcanada atravs da reviso do capacidade da tecnologia a ser implantada no
projeto de TI proposto. Por exemplo:

ITIL V3 - Service Design - Pgina:

206 de 477

A explorao de tecnologia tolerante a falhas para mascarar o impacto da


componente planejada ou no tempo de inatividade
Duplexao, ou o prviso de componentes alternativos de infra-estrutura
para permitir que um componente para assumir o trabalho de outro
componente
Melhorar a componente confiana por regimes de ensaio realando
Design de software melhorado e desenvolvimento
Melhoria de processos e procedimentos
Sistemas de gesto de melhorias / explorao
Melhorou fornecido externamente servios, contratos ou acordos
Desenvolver a capacidade de as pessoas com mais formao.

Considere documentar os requisitos de disponibilidade de design e


consideraes para novos servios de TI, tornando-os disponveis para o projeto
e execuo funes. Longo prazo procuram impor estes requisitos e integrar
dentro da apropriadas governo mecanismos que cobrem a introduo de novos
servios de TI.
Parte da atividade de projetar a disponibilidade deve garantir que todos os
negcios de dados e informaes segurana requisitos so incorporados no
interior da Design de Servios. O objectivo global da segurana de TI
"segurana equilibrado em profundidade", com justificvel controlars
implementados para assegurar que o Poltica de Segurana da Informao
aplicada e que continuou De servios de TIs dentro de parmetros de segurana
(isto , confidencialidade,integridade e disponibilidade) Continuam a operar.
Durante a reunio dos requisitos de disponibilidade de novos servios de TI,
importante que os requisitos que abrangem a segurana de TI so definidos.
Estes requisitos devem ser aplicados na fase de projeto para a tecnologia de
apoio. Para muitos organizaos, a abordagem adoptada para TI segurana
coberto por uma Poltica de Segurana da Informao de propriedade e mantido
por Gesto de Segurana da Informao. Na execuo do poltica de
segurana,Gerenciamento de Disponibilidade desempenha um importante papel
na sua operao para novos servios de TI.
Quando a operao de negcio tem uma alta dependncia em TI a
disponibilidade do servio, eo custar de falha ou perda de reputao das
empresas considerada no aceitvel, a empresa pode definir os requisitos de
disponibilidade rigorosas. Esses fatores podem ser suficientes para o negcio
para justificar os custos adicionais necessrios para atender a esses nveis mais
exigentes de disponibilidade. Atingir nveis acordados de disponibilidade comea
com o desenvolvimento, aquisio, design e / ou de produtos de boa qualidade e
componentes. No entanto, estes isolados no so susceptveis de proporcionar
os nveis sustentados de disponibilidade requeridos. Para atingir um nvel
consistente e sustentada de disponibilidade requer investimento e
desenvolvimento de efetivo Servio de Gesto de processos, ferramentas de

ITIL V3 - Service Design - Pgina:

207 de 477

gerenciamento de sistemas de alta disponibilidade e solues de design


finalmente especiais com espelhamento total ou redundncia.
Projetando para disponibilidade uma chave atividade, Impulsionado pelo
gerenciamento de disponibilidade, que garante que os requisitos de
disponibilidade estabelecidos para um servio de TI podem ser cumpridas. No
entanto, gerenciamento de disponibilidade tambm deve garantir que dentro
desta atividade de design no o foco sobre os elementos necessrios para
assegurar que, quando os servios de TI falham, o servio pode ser reintegrado
para permitir normais operaes comerciais para retomar o mais rapidamente
possvel. "Projetando para recuperao"Pode, em primeiro som negativo.
Projeto disponibilidade claramente bem sobre como evitar falhas e entrega,
sempre que possvel, um tolerante a falhas de infra-estrutura de TI. No entanto,
com este foco colocado muita confiana na tecnologia, e tem como muita
nfase foi colocada nos aspectos de tolerncia a falhas do Infra-estrutura de TI?
A realidade que as falhas ocorrer. A forma como a organizao de TI
gerencia situaes de falha pode ter um efeito positivo sobre a percepo do
negcio, clientes e usurios dos servios de TI.
Todo fracasso um "momento da verdade" importante - uma oportunidade para
fazer ou quebrar sua reputao com o negcio.
Ao fornecer o foco no "projetar para recuperao" aspectos da geral
disponibilidade,projeto pode garantir que cada fracasso uma oportunidade
para manter e at mesmo melhorar negcios e usurio satisfao. Para fornecer
uma efetiva 'projeto para a recuperao ", importante reconhecer que o
negcio e da organizao de TI tm necessidades que precisam ser satisfeitas
para permitir uma recuperao eficaz de TI falha. Estas so as necessidades
informativas que o negcio exige para ajud-los a gerenciar o impacto de falha
em seus negcios ea expectativa do jogo dentro da comunidade de usurios de
negcios, e sua empresa clientes. Estas so as habilidades, conhecimentos,
processoes, procedimentos e ferramentas necessrias para permitir a
recuperao tcnica para ser concluda em um momento timo.
Considere documentar os requisitos de recuperao de design e consideraes
para novos servios de TI e torn-los disponveis para as reas responsveis
pela concepo e execuo. A longo prazo, buscam impor estes requisitos e
integr-los dentro dos mecanismos de governao adequados que cobrem a
introduo de novos servios de TI.
Um objectivo essencial para evitar incidentes menores se tornem incidente
graves, garantindo as pessoas certas esto envolvidos cedo o suficiente para
evitar os erros que esto sendo feitas e para garantir o negcio apropriado e
tcnica recuperao procedimentos so invocados na primeira oportunidade. A
instigao destas atividades de responsabilidade do Gerenciamento de
Incidentes e um processo de papel do Service Desk. Para garantir as

ITIL V3 - Service Design - Pgina:

208 de 477

necessidades do negcio sejam atendidas durante grande De servios de TI


falhas, e para garantir a recuperao mais ideal, o processo de Gerenciamento
de Incidentes e Service Desk precisa ter definido e executar procedimentos
eficazes para a avaliao e gesto de todos os incidentes.
O exposto acima no so de responsabilidade do Gerenciamento de
Disponibilidade. No entanto, o eficcia do processo de Gerenciamento de
Incidentes e Service Desk pode influenciar fortemente o perodo de recuperao
global. A utilizao de mtodos de gesto e disponibilidade de tcnicas para
posterior otimizar TI recuperao pode ser o estmulo para as atividades
subseqentes de melhoria contnua do processo de Gerenciamento de
Incidentes e Service Desk.
A fim de manter a eficcia, a manuteno de servios de TI e componentes
devem ser monitorados, e seu impacto sobre o 'ciclo de vida do incidente
expandida'Entendido, geridos e melhorados.
Componente Anlise de Impacto falha
Componente Anlise de Impacto falha (CFIA) podem ser utilizados para prever e
avaliar o impacto sobre o servio de TI resultantes da falha de componentes
dentro da tecnologia. A sada de um CFIA pode ser usado para identificar onde
adicional resilincia devem ser consideradas para evitar ou minimizar o impacto
da falha de componentes para a operao de negcio e usurios. Isto
particularmente importante durante a Design de Servios palco, onde
necessrio prever e avaliar o impacto sobre a disponibilidade do servio de TI
decorrentes de falhas de componentes dentro do Design de Servios de TI
proposta. No entanto, a tcnica tambm pode ser aplicada aos servios
existentes e infra-estrutura.
CFIA uma tcnica relativamente simples, que pode ser usada para fornecer
esta informao. IBM concebeu CFIA no incio de 1970, com suas origens
baseadas em design de hardware e configurao. 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, aplicaos,
centros de dados e pessoal de apoio. Alm disso, a tcnica tambm pode ser
aplicado para identificar e dependncias impacto sobre o suporte de TI
organizao habilidades e competncias entre o pessoal de apoio do servio de
TI novo. Este atividade geralmente completada em conjunto com ITSCM e
possivelmente Gerenciamento da Capacidade.
A sada de um CFIA fornece informaes vitais para garantir que a
disponibilidade e recuperao critrios de projeto para o novo servio de TI
influenciado para evitar ou minimizar o impacto de falha para o funcionamento
da empresa e os usurios. ACIA realiza esta oferecendo e indicando:

ITIL V3 - Service Design - Pgina:

209 de 477

SPoFs que podem impactar disponibilidade


O impacto da falha de um componente sobre o negcio operao e os
usurios
Dependncias do componente e as pessoas
Recuperao horrios de componentes
A necessidade de identificar e documentar opo de recuperaos
A necessidade de identificar e implementar medidas de reduo de risco.

A descrio acima pode tambm fornecer o estmulo para a entrada de ITSCM a


considerar o equilbrio entre as opes de recuperao e medidas de reduo
de risco, ou seja, onde o impacto potencial alto, h uma necessidade de se
concentrar em alta disponibilidade de medidas de reduo de risco, ou seja,
aumento da resilincia ou espera sistemas.
Tendo determinado o Infra-estrutura de TI configurao a ser avaliada, a
primeira etapa criar uma grade com IC em um eixo e os servios de TI que tm
um dependncia no CI por outro lado, como ilustrado na Figura 4.18. Esta
informao deve estar disponvel a partir do CMS, ou, alternativamente, pode
ser construdo usando tabelas de configurao documentados e SLAs.

Figura 4.18 Componente Anlise de Impacto falha

O passo seguinte consiste em realizar a CFIA e preencher a grade da seguinte


forma:

ITIL V3 - Service Design - Pgina:

210 de 477

Deixe um espao em branco quando um falha do IC no tem impacto


sobre o servio de qualquer maneira
Insira um 'X' quando o fracasso da CI faz com que o servio de TI a ser
inoperante
Inserir um "A", quando no h um CI alternativa para fornecer o servio
Inserir um "M" quando existe um CI alternativa, mas o servio requer a
interveno manual para ser recuperado.

Tendo construdo a grade CIs, que tm um grande nmero de Xs so crticos


para muitos servios e pode resultar em grande impacto no caso de o CI falhar.
Da mesma forma, os servios de TI com alta contagem de Xs so complexos e
so vulnerveis ao fracasso. Esta abordagem de base para CFIA pode fornecer
informaes valiosas a identificar rapidamente SPoFs, servios de TI em risco
de fracasso CI e que alternativas esto disponveis devem CIs falhar. Deve
tambm ser utilizada para avaliar a existncia e validade de recuperao
procedimentos para a CEI selecionado. O exemplo acima assume infra-estrutura
comum de apoio mltiplos servios de TI. A mesma abordagem pode ser
utilizada por um servio nico de TI, mapeando o componente IC contra os
VBFs e utilizadores suportados por cada componente, Assim, compreender o
impacto de uma falha de componente no negcio e usurio. A abordagem
tambm pode ser aperfeioado e desenvolvido para incluir e desenvolver
factores 'disponibilidade de ponderao componente que podem ser utilizados
para avaliar e calcular o efeito global do componente falha sobre a
disponibilidade do servio total.
Para realizar uma CFIA avanada requer a matriz CFIA a ser expandido para
fornecer campos adicionais necessrios para a anlise mais detalhada. Isto
poderia incluir campos, tais como:

Ponderao disponibilidade dos componentes: Um factor de


ponderao apropriado para o impacto de falha do componente na
disponibilidade de servio total. Por exemplo, se a falha de um switch
pode causar 2.000 usurios de perder o servio de um servio total
usurio base de 10.000, ento o factor de ponderao deve ser de 0,2, ou
20%
Probabilidade de falha: Esta pode basear-se na confiana do
componente medido pela Tempo mdio entre falhas (MTBF) informao
disponvel ou, se as tendncias atuais. Isto pode ser expresso como um
indicador de baixo / mdio / alto, ou como uma representao numrica
O tempo de recuperao: Esta a estimativa recuperao tempo para
se recuperar da IC. Isto pode ser baseado em horrios de recuperao,
informaes recentes de recuperao a partir de testes de recuperao
de desastre ou uma recuperao teste programado
Procedimentos de recuperao: Este verificar que os procedimentos
de up-to-date de recuperao esto disponveis para o CI

ITIL V3 - Service Design - Pgina:

211 de 477

Independncia de dispositivos: Onde CIs software tem arquivos duplex


para fornecer resilincia, Isto para assegurar que os canais de arquivo
foram verificados como estando na configurao de hardware de disco
separados. Isto tambm se aplica ao fornecimento de energia - deve-se
verificar que as fontes de alimentao alternativas esto conectados
corretamente
Dependncia: Isso para mostrar as dependncias entre os ICs. Se uma
falha CI, pode haver um impacto sobre outros CIs - por exemplo, se o
segurana IC falhou, o sistema operacional pode impedir o
processamento de fita.

Ponto nico de Anlise de falha


APonto nico de falha (SPOF) qualquer componente dentro da infra-estrutura
de TI que no tem apoio ou failover capacidade, E tem o potencial para causar
perturbaes ao negcio,clientes ou usurios quando ele falhar. importante
que nenhum SPoFs no reconhecidos existir dentro da infra-estrutura ou
desenho da tecnologia actual, e que eles so evitados sempre que possvel.
A utilizao de anlise ou SPOF CFIA como tcnicas para identificar SPoFs
recomendada. SPOF e exerccios de anlise CFIA deve ser efectuado numa
base regular, e sempre que forem identificadas SPoFs, CFIA pode ser usado
para identificar o cliente potencial comercial, ou usurio 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 justificvel. O impacto e os transtornos
causados pela falha potencial do SPOF deve ser usado para custar-justificam
sua implantao.
Anlise da rvore de Falhas
Anlise da rvore de Falhas (TLC) uma tcnica que pode ser usada para
determinar a cadeia de eventos que provoca uma perturbao De servios de
TIs. TLC, em conjunto com os mtodos de clculo, pode oferecer detalhada
modelos de disponibilidade. Isto pode ser usado para avaliar a melhoria de
disponibilidade que pode ser alcanado atravs de tecnologia individuais opes
de concepo dos componentes. Usando FTA:

A informao pode prever-se que pode ser usado para os clculos de


disponibilidade
As operaes podem ser executadas na rvore de falhas resultantes;
estas operaes corresponder com opes de concepo
O nvel de detalhe desejado para a anlise pode ser escolhida.

TLC faz uma representao de uma cadeia de eventos usando notao


booleana. Figura 4.19 apresenta um exemplo de uma rvore de falhas.

ITIL V3 - Service Design - Pgina:

212 de 477

Figura 4.19 Exemplo de Anlise da rvore de Falhas

Essencialmente FTA distingue os seguintes eventos:

Acontecimentos bsicos - Pontos terminais para a rvore de falhas, por


exemplo, falha de energia operador, erro. Eventos bsicos no so
investigados em grande profundidade. Se os eventos bsicos so
investigados em mais profundidade, eles tornam-se automaticamente
eventos resultantes.
Eventos resultantes - Ns intermedirios da rvore de falhas,
resultantes de uma combinao de eventos. O ponto mais alto da rvore
de falhas geralmente um falha do servio de TI.
Eventos condicionais - Eventos que ocorrem apenas em determinadas
condies, por exemplo, falha do equipamento de ar-condicionado s
afeta o servio de TI se a temperatura ultrapassa os valores equipamento
reparadas.

ITIL V3 - Service Design - Pgina:

213 de 477

Os eventos de disparo - Eventos que desencadeiam outros eventos, por


exemplo, falha de energia deteco equipamento pode provocar o
desligamento automtico da De servios de TIs.

Estes eventos podem ser combinados usando operadores lgicos, 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 porto - O evento resultante somente ocorre quando a condio de
entrada no for cumprida.

Esta a tcnica bsica FTA. Esta tcnica pode tambm ser refinados, mas
complexo e FTA a avaliao matemtica de rvores de falhas esto fora do
mbito da presente publicao.
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. Simulao,
modelagem ou carregar ferramentas de teste para gerar o esperado usurio
demanda para o servio de TI novo deve ser seriamente considerado para
garantir componentes continuam a operar sob volume antecipado e condies
de estresse.
Ferramentas de modelagem tambm so obrigados a previso de
disponibilidade e para avaliar a impacto de alteraes no Infra-estrutura de TI.
As entradas para a modelagem processo incluem dados descritivos da
confiabilidade dos componentes, manuteno e manuteno. Um pacote de
folha de clculo para realizar clculos geralmente suficiente. Se os dados mais
detalhados e precisos necessrio, uma ferramenta de modelagem mais
complexos podem ter de ser desenvolvidas ou adquiridas. A falta de ferramentas
de modelagem disponibilidade prontamente disponveis 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 benefcio claramente
percebida a partir de um tal desenvolvimento e os custos de manuteno, o uso
das ferramentas existentes e planilhas devem ser suficientes. No entanto, alguns
Sistema de Gesto de ferramentas no fornecem capacidade de modelagem e
pode fornecer informaes teis sobre tendncias e previso das necessidades
de disponibilidade.

ITIL V3 - Service Design - Pgina:

214 de 477

Anlise e Gesto de Riscos


Para avaliar o vulnerabilidade de falha no interior da configurao e capacidade
do servio de TI e suporte organizao recomenda-se que existente ou
propostas de infra-estrutura de TI, configuraes de servios, Design de
Servios e apoiar a organizao (interna e externa fornecedors) esto sujeitos a
anlise de risco formal e exerccios de gesto. Anlise de Risco e Gesto uma
tcnica que pode ser usada para identificar e quantificar os riscos e
contramedidas justificveis que podem ser implementadas para proteger a
disponibilidade de sistemas de TI. A identificao dos riscos e da proviso de
contramedidas justificadas para reduzir ou eliminar a ameaas colocados por
esses riscos podem desempenhar um importante papel em alcanar os nveis
necessrios de disponibilidade para um novo ou aprimorado De servios de TI.
Anlise de Risco deve ser realizada durante o projeto fase para a tecnologia de
TI e de servio para identificar:

Riscos que podem incorrer indisponibilidade de componentes de TI dentro


da tecnologia e Design de Servios
Riscos que podem incorrer confidencialidade e / ou integridade
exposies no mbito da tecnologia de TI e Design de Servios.

A maioria avaliao de risco e metodologias de gesto de envolver o uso de


uma abordagem formal ao avaliao de risco e para a mitigao do risco
posterior com a implementao de posterior custo justificvel contramedidas, tal
como ilustrado na Figura 4.20.

Figura 4.20 Anlise e Gesto de Riscos

Anlise de risco envolve a identificao e avaliao do nvel (medida) de riscos


calculados a partir dos valores avaliados dos ativos e os nveis avaliados de
ameaas a, e vulnerabilidades de, esses ativos. Risco tambm determinada
em certa medida pela sua aceitao. Algumas organizaes e empresas podem
estar mais dispostos a aceitar o risco, enquanto outros no podem.

ITIL V3 - Service Design - Pgina:

215 de 477

Gesto de risco envolve a identificao, seleco e adopo de medidas


defensivas justificadas pelos riscos identificados para o ativo em termos de seu
potencial impacto na servios se falha ocorre, e a reduo dos referidos riscos
para um nvel aceitvel. A gesto de riscos um atividade que est associada
com muitas outras actividades, especialmente ITSCM, Gesto de Segurana e
Transio de Servio. Todos estes exerccios de avaliao de risco devem ser
coordenadas em vez de serem atividades separadas.
Esta abordagem, quando aplicada atravs de um mtodo formal, assegura a
cobertura completa, juntamente com toda a confiana suficiente de que:

Todos os possveis riscos e contramedidas foram identificados


Todas as vulnerabilidades foram identificadas e os seus nveis de
preciso avaliada
Todas as ameaas foram identificados e os seus nveis de preciso
avaliada
Todos os resultados so consistentes em todo o amplo espectro da
tecnologia avaliao
Todas as despesas de contramedidas selecionados pode ser justificada.

Mtodos formais de riscos Anlise e Gesto de agora so um elemento


importante na geral projeto e proviso de servios de TI. A avaliao do risco
muitas vezes baseada na probabilidade e potencial impacto de um evento
ocorrendo. Contramedidas so implementadas, onde quer que sejam
economicamente justificvel, para reduzir o impacto de um evento ou a
probabilidade de um evento ocorrer, ou ambos.
Gesto de Risco (M_o_R) fornece uma estrutura alternativa genrica para a
gesto de risco em todas as partes de uma organizao estratgico,programa,projeto e operacional. Ele incorpora todas as atividades
necessrias para identificar e controlar a exposio a qualquer tipo de risco,
Positivo ou negativo, que pode ter um impacto sobre a realizao de sua
organizao objetivo de negcios.
M_o_R fornece uma estrutura que experimentado, testado e eficaz para ajudar
a eliminar - ou gerenciar - os riscos envolvidos em alcanar seus objetivos.
M_o_R adota uma aplicao sistemtica de princpios, abordagem e processoes
para a tarefa de identificar, avaliar e depois planejamento e implementao de
respostas de risco. Orientao enfatiza uma abordagem de colaborao e incide
sobre os seguintes elementos fundamentais:

Desenvolvimento de um quadro que transparente, repetvel e adaptvel


Comunicar claramente a poltica e seus benefcios para todos os
funcionrios
Nomeao indivduos-chave na gesto snior para 'possuir' gesto de
risco iniciativas e garantir que eles se mover para frente

ITIL V3 - Service Design - Pgina:

216 de 477

Garantir a cultura se envolve com e suporta adequadamente


consideradas de risco, incluindo a inovao
Incorporao de sistemas de gesto de risco na gesto e aplic-los de
forma consistente
Garantir que a gesto de risco suporta objetivos - em vez de vice-versa
Explicitamente avaliar os riscos envolvidos no trabalho com outras
organizaes
Adopo de uma abordagem no-culpa para monitoramento e reviso de
avaliao de risco atividade.

Cronograma de testes disponibilidade


Uma chave entrega do Gerenciamento de Disponibilidade processo o "teste de
disponibilidade programao '. Esta uma agenda para o teste regular de todos
os mecanismos disponibilidade. Alguns mecanismos de disponibilidade, como
"balanceamento de carga", "espelhamento" e "grid computing", so usados no
proviso de servio normal no dia-a-dia, outros so usados em uma base
reconfigurao fail-over ou manual. , portanto, essencial que todos os
mecanismos de disponibilidade so testadas de uma maneira regular e
programada para assegurar que, quando eles so realmente necessrios para
real eles funcionam. Este esquema tem de ser mantido e amplamente divulgada,
de modo que todas as zonas esto conscientes do seu contedo e de modo a
que todas as outras actividades propostas pode ser sincronizado com o seu
contedo, como por exemplo:

O alterao de horrio
Planos de lanamento e os liberar programar
Todos transio planos, projetos e programas
Planejadas e programaes de manuteno preventiva
O cronograma para testar a continuidade dos servios de TI e
recuperao planos
Planos de negcios e horrios.

Manuteno planejada e preventiva


Todos TI componentes devem ser sujeitos a uma manuteno planejada
estratgia. A frequncia e nvel de manuteno necessria varia de componente
a componente, tendo em conta as tecnologias envolvidas, criticalidade e as
vantagens comerciais potenciais que podem ser introduzidas. Atividades de
manuteno planejada ativar o suporte de TI organizao para fornecer:

Manuteno preventiva para evitar falhas


As atualizaes planejadas de software ou hardware para oferecer novas
funcionalidades ou adicional capacidade
Empresas solicitado mudars para o negcio aplicaos

ITIL V3 - Service Design - Pgina:

217 de 477

Implementao de novas tecnologias e funcionalidade para explorao


pela negcio.

O requisito para tempo de inatividade planejado claramente influencia o nvel de


disponibilidade que pode ser entregue por um De servios de TI, Especialmente
aqueles que tm requisitos de disponibilidade rigorosas. Ao determinar os
requisitos de disponibilidade para um novo ou aprimorado de servios de TI, o
tempo de inatividade ea perda resultante de renda necessria para a
manuteno planejada pode no ser aceitvel para o negcio. Isto est a tornarse um problema crescente na rea de 24 x 7 Operao de Servio. Nesses
casos, essencial que operao contnua um recurso de design de ncleo
para permitir a manuteno atividade a ser realizado, sem afetar a
disponibilidade dos servios de TI.
Onde as horas de servio requeridos para os servios de TI esto a menos de
24 horas por dia e / ou sete dias por semana, provvel que a maioria da
manuteno planeada pode ser acomodada sem impactar TI disponibilidade do
servio. Todavia, quando a empresa precisa de servios de TI disponveis 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
manuteno planejada contra a perda de servio para o negcio. A no ser que
existem mecanismos para permitir a operao contnua, o tempo de inatividade
programada para manuteno planejada essencial se altos nveis de
disponibilidade devem ser alcanados e mantidos. Para todos os servios de TI,
no deve, logicamente, ser um perodo de "baixo impacto" para a
implementao de manuteno. Uma vez que as necessidades de gesto de
manuteno programada foram definidos e acordados, estes devem ser
documentados, no mnimo, em:

SLAs
OLAs
Subjacente contratos
Gesto da Mudana horrios
Lanamento de Gerenciamento de Implantao horrios.

Gerenciamento de Disponibilidade deve assegurar que o edifcio em


manuteno preventiva uma das principais consideraes de projeto para um
'24 x 7 'servio de TI.
O momento mais adequado para programar o tempo de inatividade planejado
claramente quando o impacto sobre o negcio e os seus clientes o menor.
Esta informao deve ser fornecida inicialmente pela empresa ao determinar os
requisitos de disponibilidade. Para um servio de TI existente, ou uma vez que o
novo servio Foi estabelecido, monitoramento de negcios e de clientes
transaos ajuda a estabelecer as horas em que a utilizao de servios de TI

ITIL V3 - Service Design - Pgina:

218 de 477

a mais baixa. Isto deve determinar o tempo mais apropriado para o


componente(S) a ser removido para manuteno planeada atividade.
Para acomodar os requisitos de componentes individuais para tempo de
inatividade planejado , equilibrando o De servios de TI requisitos de
disponibilidade do negcio uma oportunidade para considerar a manuteno
de programao planejada para vrios componentes simultaneamente. O
benefcio desta abordagem que o nmero de interrupes de servio
requeridos para satisfazer os requisitos de manuteno reduzido. Embora esta
abordagem tem vantagens, existem riscos potenciais que precisam ser
avaliados. Por exemplo:

O capacidade do suporte de TI organizao para coordenar a execuo


simultnea de um elevado nmero de mudars
A capacidade de realizar a determinao do problema eficaz em que o
servio de TI impactado aps a concluso das modificaes mltiplas
O impacto de mudana dependncia em vrios componentes, onde backout de uma alterao no requer mudanas mltiplas a ser removido.

A gesto eficaz de tempo de inatividade planejado uma contribuio


importante para atender os nveis exigidos de disponibilidade para um servio de
TI. Onde o tempo de inatividade planejado necessria em uma base cclica a
um componente de TI (s), o tempo que o componente no est disponvel para
permitir a atividade de manuteno 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
manuteno planejada deve ser agendada, geridos e controlados para
assegurar que os objectivos individuais e os horrios no so ultrapassados e
para garantir que as atividades so coordenadas com todos os outros horrios
de atividade para minimizar os confrontos e conflitos (por exemplo, mudana e
liberar horrios, horrios de testes). Alm disso, eles fornecem um alerta durante
a atividade de manuteno do tempo alocado para a durao da interrupo
planejada que est sendo violado. Isso pode permitir que uma deciso rpida de
ser feita sobre se a atividade permitida para completar com o potencial de
impacto adicional de servio ou para abortar a atividade e instigar a volta- plano.
Tempo de inatividade planejado e atuao contra os objectivos definidos para
cada componente deve ser registrada e utilizada em servio de relatrio.
Produo do Servio documento Outage Projetada (PSO)
Gerenciamento de Disponibilidade deve produzir e manter a PSO documento.
Este documento consiste de quaisquer variaes da disponibilidade do servio
acordado no SLA. Este deve ser apresentado com base na entrada de:

O alterao de horrio
Os horrios de liberao

ITIL V3 - Service Design - Pgina:

219 de 477

Planejadas e programaes de manuteno preventiva


Teste de horrios disponibilidade
ITSCM e Gesto de Continuidade de Negcios teste de horrios.

O PSO contm detalhes de todas as paradas servio programado e planejado


dentro das horas de servio acordados para todos os servios. 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
servio, planejado.
Reviso contnua e melhoria
As necessidades de negcio e demanda dos clientes pode exigir os nveis de
disponibilidade previsto um servio de TI a ser revisto. Tais revises devem
fazer parte das revises regulares do servio com a actividade desenvolvida
pela SLM. Outra entrada tambm devem ser considerados em uma base regular
de ITSCM, particularmente a partir da atualizao Anlise de Impacto no
Negcio e Anlise de exerccios de Risco. A criticalidade de servios, muitas
vezes, mudar e importante que o projeto ea tecnologia de apoio a esses
servios regularmente revisto e melhorado por gerenciamento de
disponibilidade para garantir que a mudana de importncia no servio
refletida dentro de um projeto de revista e tecnologia de suporte. Quando os
nveis exigidos de disponibilidade j esto sendo entregues, pode demorar um
esforo considervel e incorrem significativa custar para atingir uma melhoria
incremental pequeno dentro do nvel 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 Servio Continuada actividades. Os benefcios
desta abordagem reviso regular so de que, s vezes, melhores nveis de
disponibilidade pode ser possvel, mas com custos muito mais baixos. A
abordagem de otimizao um passo sensato primeiro a oferecer melhores
valor para o dinheiro. Uma srie de tcnicas de gerenciamento de
disponibilidade pode ser aplicada para identificar oportunidades de otimizao.
Recomenda-se que o escopo no deve ser limitado tecnologia, mas tambm
incluem um rever de ambos os processo de negcio e outros end-to-end de
negcios de propriedade responsabilidades. Para ajudar a alcanar estes
objectivos, gerenciamento de disponibilidade tem de ser reconhecido como um
lder influncia sobre o Provedor de servios de TI organizao para assegurar
foco contnuo na disponibilidade e estabilidade da tecnologia.
Gerenciamento de Disponibilidade pode fornecer o suporte de TI organizao
com um negcio real e usurio perspectiva sobre como as deficincias no
mbito da tecnologia e da sustentao processo e procedimento impacto no

ITIL V3 - Service Design - Pgina:

220 de 477

negcio operao e, finalmente, a sua clientes. O uso de Business-Driven


mtricos pode demonstrar esta impacto em termos reais e, mais importante,
tambm ajudam a quantificar os benefcios de oportunidades de melhoria.
Gerenciamento de Disponibilidade podem desempenhar um importante papel
em ajudar o TI provedor de servios organizao reconhecer onde ela pode
agregar valor atravs da explorao de suas habilidades tcnicas e
competncias em contexto disponibilidade. A tcnica de melhoria contnua pode
ser usado pela Administrao Disponibilidade para aproveitar essa tcnica
capacidade. Isto pode ser usado tanto com pequenos grupos de pessoal tcnico
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 servios de TIs para cumprir as


metas de SLA em uma base consistente
Perodo (s) de TI instabilidade do servio, resultando em nveis
inaceitveis de disponibilidade
Disponibilidade tendncias de medio indicando uma deteriorao
gradual da disponibilidade
De servios de TI inaceitvel recuperao e os tempos de restaurao
Pedidos da empresa para aumentar o nvel de disponibilidade, desde
Impacto crescente na negcio e seus clientes de servios de TI falhas,
como resultado do crescimento e / ou prioridades de negcio aumento ou
funcionalidade
Um pedido de SLM para melhorar disponibilidade como parte de um SIP
geral
Monitoramento de disponibilidade e de Gesto anlise de tendncias.

Gerenciamento de Disponibilidade deve ter uma pr-ativa papel na identificao


e progredindo economicamente justificados oportunidades de melhoria dentro da
disponibilidade Plano de disponibilidade. A capacidade de fazer essa confiana
lugares em ter disponibilidade de medio adequada e significativa e relatrios.
Para garantir melhorias Disponibilidade trazer benefcios para o negcio e
usurios, importante que a medio e relatrio reflecte no apenas de TI
componente disponibilidade, mas tambm a disponibilidade de uma operao de
negcios e usurio perspectiva.
Onde a empresa tem a obrigao de melhorar a disponibilidade, o processo e as
tcnicas para reavaliar a tecnologia e TI provedor de servios organizao
capacidade para atender a essas exigncias acrescidas devem ser seguidas.
Uma sada deste atividade maior disponibilidade e critrios de projeto de
recuperao. Para satisfazer o requisito de negcios para aumento dos nveis de
disponibilidade pode exigir investimento financeiro adicional para melhorar a
tecnologia de sustentao e / ou ampliar os servios prestados pela organizao
de prestao de servios de TI. importante que qualquer investimento
adicional para melhorar os nveis de disponibilidade entregues pode ser custo-

ITIL V3 - Service Design - Pgina:

221 de 477

justificado. Determinar o custo de indisponibilidade, como resultado de TI falha


(s) podem ajudar a apoiar qualquer deciso de investimento financeiro na
melhoria da disponibilidade

4.4.6 Triggers, entradas, sadas e interfaces


Muitos eventos podem desencadear Gerenciamento de Disponibilidade
atividade. Estes incluem:

Novos ou alterados necessidades de negcios ou servios novos ou


alterados
Novas metas ou alterados dentro acordos, como SLRs, SLAs, ou OLAs
contratos
Servio ou componente violaes, eventos e disponibilidade alertars,
incluindo limiar eventos, relatrio de exceos
Atividades peridicas, tais como a reviso, reviso ou relato
Reviso de previses de disponibilidade de Gesto, relatrios e planos
Reviso e reviso de negcios e de TI planos e estratgias
Reviso e reviso de projetos e estratgias
O reconhecimento ou a notificao de uma mudana de risco ou o
impacto de um processo de negcio ou VBF, uma De servios de TI ou
componente
Pedido da SLM para assistncia com metas de disponibilidade e
explicao de realizaes.

As principais interfaces de gerenciamento de disponibilidade que tem com outros


processoes so:

Incidente e Gerenciamento de Problemas: Na prestao de assistncia


com o resoluo e justificao posterior e correo de incidentes e
problemas de disponibilidade
Gerenciamento da Capacidade: Com o proviso de resilincia e peas
sobressalentes capacidade
Gerenciamento da Continuidade do Servio: Com o avaliao dos
negcios impacto e risco e proviso de resilincia, failover e mecanismos
de recuperao
Gerenciamento de Nvel de Servio: Assistncia com a determinao de
metas de disponibilidade e da investigao e resoluo de falhas de
servio e componentes.

4.4.6.1 Entradas

Um certo nmero de fontes de informao so relevantes para o Gerenciamento


de Disponibilidade processo. Alguns destes so os seguintes:

ITIL V3 - Service Design - Pgina:

222 de 477

Informaes de negcios: De negcio da organizao estratgia, Os


planos e os planos financeiros e informaes sobre suas necessidades
atuais e futuras, incluindo os requisitos de disponibilidade para novos ou
aprimorados servios de TI
Informaes impacto nos negcios: De preconceitos e avaliao de
VBFs apoiados por servios de TI
Anlise de Risco anterior e relatrios de avaliao e um registro de
riscos
Informaes sobre o servio: De a Portflio de Servios e do Catlogo
de Servio,
Informaes sobre o servio: A partir do processo de SLM, com
detalhes dos servios do portflio de servios e do Catlogo de
Servios,meta de nvel de servios dentro de SLAs e SLRs, e,
possivelmente, a partir da monitoramento de SLAs, servio de opinies e
violaes dos SLAs
Informaes financeiras: De Gesto Financeira, O custar de servio
profissionalviso, O custo de recursos e componentes
Alterar e liberar informao: De a Gesto da Mudana com um processo
de Alterar agendamento, A agenda de divulgao de Gerenciamento de
Liberao e uma necessidade de avaliar todas as mudanas para a sua
impacto da disponibilidade do servio
Gerenciamento da Configurao: Contendo informaes sobre a relaos
entre a empresa, os servios, os servios de apoios e a tecnologia
Metas de servio: De SLAs, SLRs, e OLAs contratos
Informaes de componentes: No disponibilidade, Confiabilidade e
manuteno requisitos para os componentes de tecnologia que
sustentam De servios de TI(S)
Tecnologia da informao: A partir do CMS sobre a topologia e as
relaes entre os componentes ea avaliao das capacidades da nova
tecnologia
Passado atuao: A partir de medies anteriores, as conquistas e os
relatrios e as Disponibilidade do Sistema de Informao de Gesto
(AMIS)
Indisponibilidade e falha informao: De incidentes e problemas.

4.4.6.2 Sadas

Os resultados produzidos pelo Gerenciamento de Disponibilidade deve incluir:

A disponibilidade do sistema de Informao de Gesto (AMIS)


O Plano de disponibilidade para a melhoria pr-ativo de servios de TI e
de tecnologia
Disponibilidade e recuperao critrios de projeto e metas propostas para
servios novos ou alterados servios
Disponibilidade do servio, confiana e relatrios de manuteno de
conquistas contra alvos, incluindo a entrada de todos os relatrios de
servios

ITIL V3 - Service Design - Pgina:

223 de 477

Disponibilidade de componentes, confiabilidade e facilidade de


manuteno relatos de conquistas contra alvos
Opinies de risco revistas e relatrios de anlise e um registro de riscos
atualizados
Gesto, acompanhamento e elaborao de relatrios requisitos para
servios de TI e componentes para garantir que desvios na confiabilidade,
disponibilidade e facilidade de manuteno so detectados, acionadas,
registo e divulgao
Um Disponibilidade cronograma de testes de Gesto para testar toda a
disponibilidade, resilincia e mecanismos de recuperao
Os planejadas e programaes de manuteno preventiva
A interrupo do servio Projetada (PSO) em conjunto com Mudana e
Gerenciamento de Liberao
Detalhes das tcnicas disponibilidade proativas e medidas que sero
implantadas para proporcionar resistncia adicional para evitar ou
minimizar o impacto das falhas de componentes sobre a disponibilidade
de servios de TI
Aes de melhoria para a incluso dentro da SIP.

4.4.7 Indicadores Chave de Desempenho


KPIs muitos podem ser utilizados para medir a eficcia e eficincia de
gerenciamento de disponibilidade, incluindo os seguintes exemplos:
Gerir a disponibilidade e confiabilidade dos servios de TI:

Reduo percentual da indisponibilidade de servios e componentes


Aumento percentual na fiabilidade dos servios e componentes
Eficaz de reviso e acompanhamento de todos os SLA, OLA e subjacente
contrato violaes
O percentual de melhoria em geral fim-de-final disponibilidade de servio
Reduo percentual no nmero e impacto das quebras de servio
Melhoria no MTBF (Tempo mdio entre falhas)
Melhoria da TMEIS (Tempo Mdio Entre Incidentes Sistemas)
Reduo dos MTRS (Tempo mdio para restaurar o servio).

Satisfazer as necessidades de negcios para o acesso aos servios de TI:

Percentagem de reduo a indisponibilidade de servios


Percentagem de reduo do custar de horas extras de negcios devido
indisponibilidade de TI
Reduo percentual em falhas de tempo crticos, por exemplo, pico de
negcio e as necessidades de disponibilidade prioritrias esto previstas
para
O percentual de melhoria nos negcios e usurios satisfeito com o servio
(por resultados CSS).

ITIL V3 - Service Design - Pgina:

224 de 477

Disponibilidade de infraestrutura de TI realizados a custos timos:

Percentagem de reduo do custo de indisponibilidade


O percentual de melhoria nos custos de entrega de servios
Concluso oportuna de Anlise de Risco regular e sistema rever
Concluso oportuna de anlise custo-benefcio regularmente estabelecida
para infra-estrutura Componente Anlise de Impacto falha (CFIA)
Percentagem de reduo falhas de terceiros atuao em MTRS / MTBF
contra alvos de contrato
Reduo do tempo necessrio para completar (ou atualizao) a Anlise
de Risco
Reduo do tempo necessrio para avaliar a resilincia do sistema
Reduo do tempo necessrio para completar um Plano de
disponibilidade
Produo atempada de relatrios de gesto
Percentagem de reduo da incidncia de operacional opinies
descobrindo segurana e confiana exposies em projetos de aplicao.

4.4.8 Gesto da Informao


O Gerenciamento de Disponibilidade processo deve manter uma AMIS que
contm todas as medidas e as informaes necessrias para concluir o
gerenciamento de disponibilidade processo e fornecer a informao adequada
negcio sobre o nvel de servio prestado TI. Esta informao, que abrange
servios, componentes e servios de apoios, fornece a base para regular, ad
hoc e relatrios de exceo disponibilidade e identificao de tendncias nos
dados para a instigao de atividades de melhoria. Essas atividades e as
informaes contidas nas AMIS fornecem a base para o desenvolvimento do
contedo 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 questes mais
amplas de pessoas, processos, ferramentas e tcnicas, bem como ter um foco
de tecnologia. Nas fases iniciais, pode ser alinhada com uma implementao
plano para gerenciamento de disponibilidade, mas os dois so diferentes e no
devem ser confundidas. Como o processo de Gerenciamento de Disponibilidade
amadurece, o plano deve evoluir para cobrir o seguinte:

Nveis reais de disponibilidade contra concordaram nveis de


disponibilidade para a chave De servios de TIs. Medies de
disponibilidade deve ser sempre de negcios e foco no cliente e
disponibilidade relatrio vivida pela empresa e usurios.
Atividades que esto sendo progrediu para solucionar as carncias de
disponibilidade para os actuais servios de TI. Onde as decises de

ITIL V3 - Service Design - Pgina:

225 de 477

investimento so necessrios, opes com associados custars e os


benefcios devem ser includos.
Informaes sobre como alterar os requisitos de disponibilidade para os
servios de TI existentes. O plano deve documentar as opes
disponveis para atender a esses requisitos alterados. Onde as decises
de investimento so necessrios, os custos associados de cada opo
deve ser includo.
Detalhes dos requisitos de disponibilidade para futuros novos servios de
TI. O plano deve documentar as opes disponveis para atender a essas
novas exigncias. Onde as decises de investimento so necessrios, os
custos associados de cada opo deve ser includo.
Uma programao voltada para o futuro para as atribuies SFA
planejadas.
Revises regulares de atribuies SFA devem ser cumpridos para
garantir que a disponibilidade de tecnologia est sendo melhorada de
forma proativa em conjunto com a SIP.
Uma tecnologia seo futuros para fornecer uma indicao dos potenciais
benefcios e oportunidades de explorao que existem para atualizaes
tecnolgicas planejadas. Benefcios de disponibilidade antecipados
devem ser detalhados, sempre que possvel com base em medidas de
negcios focados, em conjunto com Gerenciamento da Capacidade. O
esforo necessrio para obter esses benefcios sempre que possvel
tambm devem ser quantificados.

Durante a produo do Plano de disponibilidade, Recomenda-se que a ligao


com todos os domnios funcionais, tcnicas e processo realizado. O Plano de
Disponibilidade deve cobrir um perodo de um a dois anos, com uma viso mais
detalhada e informaes para os primeiros seis meses. O plano deve ser revista
regularmente, com re menorvisos cada trimestre e re maiorvisos cada
semestre. Em que a tecnologia s submetida a um baixo nvel de alterao,
isto pode ser estendido, conforme apropriado.
Recomenda-se que o plano de Disponibilidade considerada complementar
Plano de capacidade e Plano Financeiro, e que a publicao est alinhada com
a capacidade e de negcios oramentao ciclo. Se um pedido for previsto para
elevados nveis de disponibilidade que no podem ser satisfeitas devido s
limitaes do actual Infra-estrutura de TI ou oramento, Ento relatrio de
exceos podem ser necessrios para a ateno tanto de TI snior e gesto de
negcios.
A fim de facilitar a produo do Plano de disponibilidade, Gerenciamento de
Disponibilidade pode querer considerar ter seu repositrio prprio banco de
dados. Os AMIS pode ser utilizado para gravar e armazenar dados selecionados
e informaes necessrias para apoiar as atividades-chave, como a gerao de
relatrios, anlise estatstica e previso de disponibilidade e planejamento. Os
AMIS deve ser o repositrio principal para a gravao de TI disponibilidade

ITIL V3 - Service Design - Pgina:

226 de 477

mtricos, medidas, metas e documentos, incluindo o Plano de Disponibilidade,


medies de disponibilidade, relatrios de realizao, relatrios de atribuio
SFA, critrios de projeto, planos de ao e horrios de ensaio.
Ser pragmtico, definir os requisitos das ferramentas iniciais e identificar o que j
est implantado, que pode ser usado e compartilhado para comear o mais
rpido possvel. Quando as ferramentas bsicas no esto j disponveis,
trabalhar com o outro De servios 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 relatrios especficos de Gerenciamento de
Disponibilidade no assegurada por repositrios existentes e integrar com eles e
seus contedos.

4.4.9 Desafios, Fatores Crticos de Sucesso e riscos


Gerenciamento de Disponibilidade enfrenta muitos desafios, mas,
provavelmente, o principal desafio , na verdade, atender as expectativas do
clientes, o negcio e gerncia snior. Estas expectativas so de que os servios
estaro sempre disponveis e no apenas durante a sua concordou servio
horas, mas que todos os servios estaro disponveis 24 horas por dia, base de
365 dias. Quando no so, supe-se que sejam recuperados em poucos
minutos. Este o caso apenas quando o nvel apropriado de investimento e
design tem sido aplicadas para o servio, e isso s deve ser feita quando o
negcio impacto justifica que o nvel de investimento. No entanto, a mensagem
precisa ser divulgado para todos os clientes e reas de negcio, de modo que,
quando os servios falham tm o nvel certo de expectativa sobre a sua
recuperao. Isso tambm significa que Gerenciamento de Disponibilidade deve
ter acesso a um nvel adequado de informao de qualidade sobre a
necessidade do negcio atual para os servios 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 integrao de todos os
dados de disponibilidade em um conjunto integrado de informaes (AMIS) que
pode ser analisado de uma forma consistente para fornecer informaes sobre a
disponibilidade de todos os servios e componentes. Isto particularmente
desafiador quando as informaes das diferentes tecnologias geralmente
fornecida por diferentes ferramentas em diferentes formatos.
No entanto, outro desafio de gerenciamento de disponibilidade convencer o
negcio e gerncia snior do investimento necessrio 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
resilincia para evitar a possibilidade de falhas que podem acontecer um
desafio difcil. Gerenciamento de Disponibilidade deve trabalhar em estreita

ITIL V3 - Service Design - Pgina:

227 de 477

colaborao com Gesto da Continuidade do Servio,Gesto de Segurana e


Gesto de capacidade em produzir as justificativas necessrias para assegurar
o investimento necessrio.
Os QCA principais para o processo de gerenciamento de disponibilidade so:

Gerir disponibilidade e confiana de servio de TI


Satisfazer as necessidades de negcios para o acesso ao De servios 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 negcio para o processo de Gerenciamento de


Disponibilidade
A falta de compromisso do negcio e uma falta de informao adequada
sobre os planos e estratgias futuras
A falta de compromisso da alta administrao ou a falta de recursos e / ou
oramento para o Gerenciamento de Disponibilidade processo
Os processos de comunicao tornam-se muito de trabalho intensivo
Os processos se concentrar demais na tecnologia e no o suficiente
sobre os servios e as necessidades do negcio
A informao de gerenciamento de disponibilidade (AMIS) mantido em
isolamento e no compartilhada ou consistente com outras reas de
processo, especialmente ITSCM, Gesto de Segurana e Gerenciamento
da Capacidade. Este investimento particularmente importante quando
se considera o servio necessrio e componente apoio e ferramentas de
recuperao, tecnologia e processos para atender as necessidades
acordadas.

ITIL V3 - Service Design - Pgina:

228 de 477

4,5 Gerenciamento de Continuidade do Servio


4.5.1 Finalidade objetivo / / objetivo
'O objectivo da ITSCM consiste em apoiar o conjunto Gesto de Continuidade de
Negcios processo, garantindo que as instalaes de TI necessrios tcnicos e
de servios (incluindo sistemas de computadores, redes, aplicaos, repositrios
de dados, telecomunicaes, ambiente,suporte tcnico e Service Desk) pode ser
retomado dentro necessrio e acordado, prazos de negcio. "

Como a tecnologia um ncleo componente mais de processo de negcioes,


continuado ou alta disponibilidade de TI crtica para a sobrevivncia do
negcio como um todo. Isto conseguido atravs da introduo de medidas de
reduo de risco e opo de recuperaos. Como todos os elementos de ITSM,
a implementao bem sucedida de ITSCM s pode ser alcanada com o
compromisso da alta administrao e ao apoio de todos os membros da
organizao. Manuteno contnua da recuperao capacidade essencial para
que possa manter a sua eficcia. O objetivo do GCSTI manter a capacidade
de recuperao necessrio em curso no mbito dos servios de TI e de seus
componentes de apoio.
O objetivos de ITSCM so os seguintes:

Manter um conjunto de TI Plano de Continuidade do Servios de TI e


planos de recuperao que suportam o geral Plano de Continuidade de
Negcioss (PCN) da organizao
Completa regulares Anlise de Impacto no Negcio (BIA) exerce a
assegurar que todos os planos de continuidade so mantidos em
conformidade com os impactos de mudana da empresa e os requisitos
Realizar Anlise de Risco regular e exerccios de gesto, particularmente
em conjunto com a empresa eo Gerenciamento de Disponibilidade e
Gesto de Segurana processos, que gerenciar servios de TI dentro de
um nvel acordado de negcios risco
Prestar assessoria e orientao para todas as outras reas de negcio e
de TI em todas as questes de continuidade e recuperao relacionados
Certifique-se que a continuidade adequada e mecanismos de
recuperao so postas em prtica para atender ou exceder as metas de
continuidade de negcios acordados
Avaliar a impacto de todos mudars sobre os Planos de Continuidade de
Servio de TI e planos de recuperao de TI
Assegurar que as medidas pr-ativas para melhorar a disponibilidade de
servios so implementados onde quer que seja de custo justificvel para
faz-lo
Negociar e acordar o necessrio contratos com fornecedors para o
proviso da recuperao necessrio capacidade para suportar todos os
planos de continuidade em conjunto com o Gesto de Fornecedores
processo.

ITIL V3 - Service Design - Pgina:

229 de 477

4.5.2 mbito
ITSCM incide sobre os eventos que o negcio considera significativo o suficiente
para ser considerado um desastre. Eventos menos importantes sero tratados
como parte da Gerenciamento de Incidentes processo. O que constitui um
desastre varia de organizao para organizao. O impacto de uma perda de
um processo de negcio, tais como perdas financeiras, danos reputao ou
violao de regulamentao, medida atravs de um exerccio BIA, que
determina os requisitos mnimos crticos. O tcnico de TI especficas e
necessidades de servio so suportados por GCSTI. O escopo do GCSTI dentro
de uma organizao determinada pela estrutura organizacional, cultura e
estratgico direo (de negcios e tecnologia) em termos dos servios prestados
e como eles se desenvolvem e mudam ao longo do tempo.
ITSCM principalmente considera a TI ativoss e configuraes que suportam o
processo de negcioes. Se (aps um desastre) necessrio se mudar para um
local alternativo de trabalho, proviso tambm ser necessria para itens como
escritrio e alojamento de pessoal, cpias de papel crtico registros, de courier
servios e instalaes de telefone para se comunicar com clientes e terceiros.
O escopo ter de ter em conta o nmero ea localizao dos escritrios da
organizao e os servios realizados em cada um.
ITSCM no costuma diretamente cobrir os riscos de longo prazo, como os de
mudanas na direo dos negcios, diversificao, reestruturao, grande
concorrente falha, E assim por diante. Enquanto esses riscos podem ter um
impacto significativo sobre os elementos de servios de TI e os mecanismos de
continuidade, geralmente h tempo para identificar e avaliar o risco e incluir
mitigao de riscos por meio de alteraes ou mudanas nos negcios e
estratgias de TI, tornando-se assim parte do negcio global e TI Gesto da
Mudana programa.
Da mesma forma, ITSCM geral, no cobrem pequenas falhas tcnicas (por
exemplo, falha do disco no crtico), a menos que haja uma possibilidade de que
o impacto pode ter um grande impacto sobre o negcio. Estes riscos seria de
esperar para ser coberto principalmente por meio da Central de Servios e do
processo de Gerenciamento de Incidentes, ou resolvidos atravs do
planejamento associado ao processoes de Gerenciamento de
Disponibilidade,Gerenciamento de Problemas, Gesto da Mudana,
Gerenciamento da Configurao e 'business as usual' operacional gesto.
O processo ITSCM inclui:

O acordo do escopo do processo ITSCM e as polticas adotadas.


Business Impact Analysis (BIA) para quantificar a impacto perda de
servios de TI teria sobre o negcio.

ITIL V3 - Service Design - Pgina:

230 de 477

Anlise de Risco (RA) - a identificao de riscos e avaliao de risco para


identificar possveis ameaas continuidade e probabilidade de as
ameaas se tornem realidade. Isto tambm inclui a tomada de medidas
para gerir o identificado ameaas onde isso pode ser custo-justificado.
Produo de um total ITSCM estratgia que deve ser integrado na
estratgia de BCM. Este pode ser produzido seguindo os dois passos
acima identificados, e provvel que incluem elementos de reduo de
risco, bem como seleo de opes de recuperao adequadas e
abrangentes.
Produo de um plano de ITSCM, que novamente deve ser integrado
com os planos de BCM geral.
Teste dos planos.
Contnuo operao e manuteno dos planos.

4.5.3 Valor para o negcio


ITSCM fornece uma valiosa papel no apoio ao processo de negcio
Planejamento da Continuidade. Em muitas organizaes, ITSCM usado para
aumentar a conscincia da continuidade e recuperao requisitos e muitas
vezes usado para justificar e implementar um processo de Planejamento de
Negcios e Continuidade Plano de Continuidade de Negcioss. O ITSCM deve
ser impulsionada por negcios risco como identificado pelo Planejamento de
Continuidade de Negcios, e assegura que o regime de recuperao para De
servios de TIs esto alinhados aos impactos, riscos de negcio identificados e
necessidades.

4.5.4 Polticas / princpios / conceitos bsicos


Uma abordagem de ciclo de vida devem ser adotados para a criao e operao
de um processo GCSTI. Figura 4.21 apresenta o ciclo de vida do GCSTI, desde
a iniciao at a garantia contnua que a proteo oferecida pelo plano atual e
reflete tudo mudars para os servios e nvel de servios. ITSCM um processo
cclico atravs do ciclo de vida de garantir que, uma vez servio planos de
continuidade e recuperao foram desenvolvidos so mantidos alinhados com
Planos de Continuidade de Negcios (PCN) e as prioridades de negcios. Figura
4.21 tambm mostra a papel jogado dentro do processo ITSCM do BCM.

ITIL V3 - Service Design - Pgina:

231 de 477

Figura 4.21 Ciclo de Vida da Gesto da Continuidade do Servio

Etapas de iniciao e os requisitos so atividades principalmente BCM. ITSCM


s deve ser envolvida nestes estgios para apoiar as atividades de GCN e
compreender a relao entre os processos de negcios e os impactos causados
sobre eles pela perda de servios de TI. Como resultado destes BIA inicial e
atividades de anlise de risco, BCM deve produzir uma Estratgia de
Continuidade de Negcios, ea tarefa ITSCM primeira real produzir uma
estratgia ITSCM que sustenta o BCM estratgia e suas necessidades.
A Estratgia de Continuidade de Negcio deve focar principalmente processo de
negcioes e problemas associados (por exemplo, a continuidade de processos
de negcios, a continuidade do pessoal, a continuidade edifcios). Uma vez que
a Estratgia de Continuidade de Negcios tem sido produzido, ea papel que os
servios de TI tem de fornecer dentro da estratgia foi determinada, uma ITSCM
estratgia pode ser produzido que apoia e permite a Estratgia de Continuidade
de Negcios. Isso garante que as decises de custo-benefcio pode ser feita,
considerando todos os "recursos" para entregar um processo de negcio. No
fazer isso tende a encorajar opes ITSCM que so mais rpidos, mais
elaborado e caro do que so realmente necessrios.
As actividades a serem tidos em conta durante a iniciao depende da extenso
em que as instalaes de continuidade foram aplicadas dentro do organizao.
Algumas partes do negcio podem ter estabelecido indivduo Plano de
Continuidade de Negcioss em torno de manuais solues alternativas, e ele
pode ter desenvolvido planos de continuidade para sistemas que so vistos
como crticos. Isto bom para a entrada processo. No entanto, ITSCM eficaz
depende de apoio funes crticas de negcios. A nica maneira de implementar
ITSCM eficaz atravs da identificao de processos crticos de negcios ea
anlise e coordenao da tecnologia necessria e apoiar servios de TI.

ITIL V3 - Service Design - Pgina:

232 de 477

Esta situao pode ser ainda mais complicada em terceirizao situaes em


que um processo dentro de uma ITSCM prestador de servios externo
contratante ou organizao tem que atender as necessidades no s do
processo de BCM cliente e estratgia, mas tambm do processo o contratante
do BCM prprio e estratgia. Estas necessidades podem estar em conflito um
com o outro, ou pode entrar em conflito com as necessidades do BCM de uma
da outra terceirizao organizao clientes.
No entanto, em muitas organizaes BCM est ausente ou tem um foco muito
pequeno, e muitas vezes ITSCM necessrio para cumprir muitos dos
requisitos e atividades do BCM. O restante desta seo assumiu que ITSCM
teve que realizar muitas das atividades exigidas pelo BCM. Se um processo de
BCM estabelecida com Estratgias e Planos de Continuidade de Negcios no
lugar, esses documentos devem fornecer o foco e unidade para estabelecer
GCSTI.

4.5.5 as atividades de processo, mtodos e tcnicas


As sees a seguir contm detalhes de cada uma das fases do ciclo de vida
dentro GCSTI.
4.5.5.1 Fase 1 - Iniciao

O processo de iniciao abrange toda a organizao e composto das


seguintes atividades:

Definio de poltica - Este deve ser criado e comunicado o mais breve


possvel de modo a que todos os membros da organizao envolvido, ou
afectados por problemas de continuidade de negcios esto cientes de
suas responsabilidades para cumprir e apoiar GCSTI. No mnimo, a
poltica deve definir a inteno da administrao e objetivos.
Especificar termos de referncia e mbito - o que inclui a definio do
escopo e as responsabilidades de todos os funcionrios na organizao.
Ela abrange tarefas como realizar uma Anlise de Risco e Anlise de
Impacto no Negcio e determinao da estrutura de comando e controle
necessrios para suportar uma interrupo de negcios. H tambm uma
necessidade de ter em conta questes como pontos de auditoria
pendentes, regulamentares ou cliente exigncias e determinaes da
organizao de seguros e observncia com normas como a ISO 27001, a
Padro em Gesto de Segurana da Informao, Que tambm trata dos
requisitos de continuidade de servio.
Distribuir recursos - O estabelecimento de um efetivo de Continuidade
de Negcios ambiente requer recursos considerveis em termos de
dinheiro e mo de obra. Dependendo da maturidade da organizao, no
que diz respeito ao GCSTI, pode haver uma exigncia para familiarizar e /
ou o pessoal de bordo para realizar a Fase 2 tarefas. Em alternativa, a

ITIL V3 - Service Design - Pgina:

233 de 477

utilizao de consultores externos experientes podem ajudar na


concluso da anlise mais rapidamente. No entanto, importante que o
organizao pode ento manter o processo vai para a frente sem a
necessidade de confiar totalmente em apoio externo.
Definir a organizao do projeto e estrutura de controle - ITSCM e
BCM projetos so potencialmente complexa e precisa ser bem
organizado e controlado. altamente aconselhvel a utilizao de um
reconhecido padro 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 variaos abordadas. Planos de qualidade
garantir que o entregas so alcanados e para um nvel aceitvel de
qualidade. Eles tambm fornecem um mecanismo para comunicar os
requisitos do projeto de recursos e resultados, obtendo assim "buy-in" de
todas as partes necessrias.

4.5.5.2 Fase 2 - Requisitos e estratgia

Determinar os requisitos de negcio para De servios de TI continuidade um


componente crtico para determinar o quo bem uma organizao ir sobreviver
a uma interrupo de negcios ou desastre eo custars que sero incorridas. Se
a anlise de requisitos incorreta, ou informaes chave foi perdida, isso pode
ter conseqncias graves sobre a eficcia de mecanismos GCSTI.
Esta fase pode efetivamente ser dividido em duas sees:

Requisitos - Executar Anlise de Impacto no Negcio e avaliao de


risco
Estratgia - Aps a anlise de requisitos, a estratgia deve documentar
as medidas de reduo de risco e necessrios opo de recuperaos
para suportar o negcio.

Requisitos - Business Impact Analysis

O objetivo de uma Anlise de Impacto nos Negcios (BIA) quantificar o


impacto ao negcio que a perda de servio teria. Esse impacto pode ser um
impacto "duro" que podem ser identificados com preciso - como perda
financeira - ou impacto "suave" - tais como relaes pblicas, sade, moral e
segurana ou perda de vantagem competitiva. A BIA vai identificar os servios
mais importantes para a organizao e, portanto, ser um contributo essencial
para a estratgia.
A BIA identifica:

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


Renda perdida

ITIL V3 - Service Design - Pgina:

234 de 477

Os custos adicionais
Reputao danificada
Perda de boa vontade
Perda de vantagem competitiva
Violao da lei de sade e segurana
Risco para a segurana pessoal
Perda imediata e de longo prazo de quota de mercado
Embarao poltico, empresarial ou pessoal
Perda de operacional capacidade - Por exemplo, em um comando
e controle ambiente
Como o grau de dano ou a perda provvel escalar aps um servio
interrupo, e os momentos do dia, semana, ms ou ano, quando a
interrupo ser mais severo
O pessoal, habilidades, instalaes e servios (incluindo os servios de
TI) necessrios para permitir crtica e essencial processo de negcioes de
continuar operando em um nvel mnimo aceitvel
O tempo em que os nveis mnimos de pessoal, instalaes e servios
devem ser recuperados
O tempo em que todos os processos de negcios necessrios e pessoal
de apoio, instalaes e servios devem ser totalmente recuperada
A recuperao de empresas em relao prioridade para cada um dos De
servios de TIs.

Um dos principais resultados de um exerccio de BIA um grfico da actividade


impacto esperado causado pela perda de um processo comercial, ou a perda de
um servio de TI ao longo do tempo, tal como ilustrado na Figura 4.22.

Figura 4.22 Representao grfica de impactos nos negcios

ITIL V3 - Service Design - Pgina:

235 de 477

Este grfico pode ento ser usada para impulsionar os negcios e as estratgias
de TI e planos de continuidade. Medidas mais preventivas precisam ser
adotadas com relao queles processoes e servios com impactos anteriores e
superiores, enquanto que maior nfase deve ser colocada na continuidade e
medidas de recuperao 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 nvel dos mecanismos de ITSCM que
precisam ser considerados ou implantado. Uma vez apresentadas as seguintes
opes, o negcio pode decidir que os nveis mais baixos de servio ou atrasos
maiores so mais aceitveis, com base numa anlise custo-benefcio, Ou talvez
que medidas gerais de preveno de desastres tero de ser implementadas.
Estes avaliaos permitir o mapeamento de crtica de servios de aplicao e
tecnologia componentes a crtica processo de negcioes, ajudando a identificar
os elementos ITSCM que precisam ser fornecidos. Os requisitos de negcio so
classificados e os elementos associados ITSCM confirmado e priorizados em
termos de reduo de riscos e recuperao planejamento. Os resultados da BIA,
discutido anteriormente, so de entrada de valor inestimvel para diversas reas
do desenho do processo, incluindo Gerenciamento de Nvel de Servio para
compreender o requerido nvel de servios.
Impactos devem ser medidos contra cenrios especficos para cada processo de
negcio, tais como a incapacidade de liquidao de operaes no mercado
monetrio de um processo de negociar, ou impossibilidade de nota fiscal por
um perodo de dias. Um exemplo um ambiente de mercado monetrio lidar
onde a perda de informaes de dados de mercado poderia significar que a
organizao comea a perder dinheiro imediatamente como o comrcio no
pode continuar. Alm disso, clientes pode ir para outra organizao, o que
significaria a perda de potencial de negcio. Perda do sistema de liquidao no
impede comrcio de acontecer, mas se ofcios j realizadas no pode ser
resolvido dentro de um determinado perodo de tempo, a organizao pode estar
em violao das regras de regulao ou perodos de liquidao e sofrer multas e
reputao danificada. Isto pode realmente ser a mais significativa impacto do
que a incapacidade para o comrcio devido a uma incapacidade de satisfazer as
expectativas dos clientes.
Tambm importante compreender como os impactos podem mudar ao longo
do tempo. Por exemplo, pode ser possvel para uma empresa para funcionar
sem uma especial processo por um perodo de tempo curto. Em um cenrio
equilibrado, os impactos para o negcio ir ocorrer e se tornar maior com o
tempo. No entanto, nem todos organizaos so afectados deste modo. Em
algumas organizaes, os impactos no so aparentes imediatamente. Em
algum ponto, no entanto, para qualquer organizao, os impactos sero
acumulados para um nvel tal que a empresa no pode mais operar. ITSCM

ITIL V3 - Service Design - Pgina:

236 de 477

garante que as opes de contingncia so identificados de forma que a medida


adequada pode ser aplicado no momento adequado para manter os impactos de
negcios de interrupo do servio para um nvel mnimo.
Ao conduzir uma BIA, importante que os pontos de vista representantes
seniores superfcies so procurados na perda de impacto seguinte de servio.
igualmente importante que os pontos de vista dos quadros e pessoal mais
jnior so procurados para garantir que todos os aspectos do impacto aps a
perda de servio so apuradas. Muitas vezes, os diferentes nveis de pessoal
tero diferentes pontos de vista sobre o impacto, e todos tm de ser tidas em
conta quando se produz a global estratgia.
Em muitas organizaes, ser impossvel, ou no vai ser custo-justificvel, para
recuperar o total do servio em um prazo muito curto. Em muitos casos, os
processos de negcios pode ser re-estabelecida sem um complemento total de
pessoal, sistemas e outras instalaes, e ainda manter um nvel aceitvel de
servio para clientes e clientes. A recuperao de empresas objetivos deve ser
definida em termos de:

O tempo em que uma equipe pr-definido de ncleo de pessoal e


instalaes mnimas indicadas devem ser recuperados
O calendrio para a recuperao do restante pessoal e instalaes.

Ela pode no ser sempre possvel fornecer os requisitos de recuperao para


um nvel mais detalhado. H uma necessidade para equilibrar o potencial
impacto contra o custar de recuperao para assegurar que os custos so
aceitveis. Os objetivos de recuperao que, no entanto, fornecer um ponto de
partida para a recuperao de negcio diferente e opes ITSCM pode ser
avaliada.
Requisitos - Anlise de Risco

O segundo motorista na determinao dos requisitos ITSCM a probabilidade


de que um desastre ou interrupo do servio outro grave ir ocorrer. Trata-se
de um avaliao do nvel de ameaa e a medida em que uma organizao que
vulnervel a ameaa. Anlise de risco pode tambm ser utilizado na avaliao e
reduzindo a probabilidade de incidentes operacionais normais e uma tcnica
utilizada pela Gerenciamento de Disponibilidade para garantir a disponibilidade
necessria e confiana nveis pode ser mantida. Anlise de Risco tambm um
aspecto fundamental do Gesto de Segurana da Informao. Um diagrama de
Anlise e Gesto de Riscos (Figura 4.20) est contido dentro do processo de
gerenciamento de disponibilidade na seco 4.4.
Um nmero de Anlise de Risco e mtodos de gesto esto disponveis para
ambos os setores comerciais e governamentais. Anlise de Risco a avaliao
dos riscos que podem dar origem a interrupo do servio ou segurana
violao. Gesto de risco est preocupado com a identificao de respostas de
ITIL V3 - Service Design - Pgina:

237 de 477

risco adequada relao custo-justificveis contramedidapara combater esses


riscos.
Uma metodologia padro, tal como o Gesto de Risco (M_o_R), deve ser usado
para avaliar e gerir os riscos dentro de uma organizao. O quadro M_o_R
ilustrado na Figura 4.23.

Figura 4.23 Gesto de Risco

A abordagem M_o_R baseado em torno do quadro acima, que consiste no


seguinte:

Princpios M_o_R: Estes princpios so essenciais para o


desenvolvimento de boas gesto de risco prtica e so derivados a partir
de empresas governo princpios.
Abordagem M_o_R: An organizaoA abordagem a estes princpios
precisa ser acordado e definido dentro dos seguintes documentos vivos:
Gesto de Risco Poltica
Guia de processo
Planos
risco registra

ITIL V3 - Service Design - Pgina:

238 de 477

Logs questo.
Processos M_o_R: Os quatro passos seguintes descrevem os principais
insumos, produtos e atividades que garantam que os riscos so
controlados:
Identificar: O ameaas e oportunidades dentro de uma atividade
que poderiam afetar a capacidade de atingir o seu objetivo
Avaliar: A compreenso do efeito lquido das ameaas
identificadas e oportunidades associadas com uma atividade
quando agregadas
Plano: Preparar uma resposta especfica de gesto que ir reduzir
as ameaas e maximizar as oportunidades
Executar: A planeada gesto de risco aces, acompanhar a sua
eficcia e tomar aes corretivas em que as respostas no
correspondem s expectativas.
Incorporao e reviso M_o_R: Ter colocado os princpios da
abordagem, e processoes no lugar, eles precisam ser continuamente
revistos e melhorados para garantir que eles permanecem eficazes.
Comunicao: Ter as atividades de comunicao adequada para garantir
que todos estejam manter-se atualizado com as mudanas na ameaas,
oportunidades e quaisquer outros aspectos gesto de risco.

Este mtodo M_o_R requer a avaliao de riscos ea desenvolvimento de um


perfil de risco, tal como no exemplo da Figura 4.24.

ITIL V3 - Service Design - Pgina:

239 de 477

Figura 4.24 Exemplo perfil de risco resumo

Figura 4.24 apresenta um perfil de risco exemplo, contendo muitos riscos que
esto fora do nvel definido de "aceitvel risco'. Aps a anlise de risco
possvel determinar as respostas adequadas de risco ou medidas de reduo de
risco (mecanismos ITSCM) para gerenciar os riscos, ou seja, reduzir o risco a
um nvel aceitvel ou mitigar o risco. Sempre que possvel, 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 nmero de riscos que precisam de ser tomadas em
considerao. O seguinte no uma lista exaustiva, mas d alguns exemplos de
riscos e ameaas que precisam ser abordadas pelo ITSCM processo.

ITIL V3 - Service Design - Pgina:

240 de 477

Risco

Ameaa

Perda de sistemas internos de TI / redes, PABX,


DACs, etc

Fogo
Falha de energia
Arson e vandalismo
Inundao
Impacto do avio
Danos do tempo, por exemplo, furaco
Desastre ambiental
Ataque terrorista
Sabotar
Falha catastrfica
Danos eltricos, por exemplo, relmpago
Danos acidentais
M qualidade de software

Perda de externas sistemas de TI / redes, por


exemplo, e-commerce servidors, sistemas
criptogrficos

Todo o acima
Excesso de demanda por servios
Ataque de negao de servio, por
exemplo, contra um firewall de Internet
Tecnologia falha, E.g. sistema
criptogrfico

Perda de dados

Falha de tecnologia
Humano erro
Vrus, software malicioso, por exemplo
applets ataque

Perda de servios de rede

Danos ou recusa de acesso s


instalaes de rede do provedor de
servios
Perda de provedor de servios de TI de
sistemas / redes
Perda de dados prestador de servios
A falha do provedor de servios

Indisponibilidade de pessoal tcnico e de apoio


fundamental

Ao industrial
Recusa de acesso s instalaes
Renncia
Doena / leso
Dificuldades de transporte

Falha de prestadores de servios, por exemplo,


terceirizados de TI

Fracasso comercial, por exemplo,


insolvncia
Recusa de acesso s instalaes
Indisponibilidade de pessoal prestador
de servios
O no cumprimento contratual nvel de
servios

Tabela 4.1 Exemplos de riscos e ameaas

ITIL V3 - Service Design - Pgina:

241 de 477

Estratgia de TI da Continuidade do Servio

Os resultados da Anlise de Impacto no Negcio e da Anlise de Risco permitir


Negcios apropriado e estratgias de TI de continuidade de servios a serem
produzidos em linha com as necessidades do negcio. O estratgia ser um
equilbrio ideal de reduo de riscos e recuperao ou opes de continuidade.
Isso inclui a considerao da relao servio prioridades de recuperao e as
mudanas na prioridade de servio relativa para a hora do dia, dia da semana, e
as variaes mensal e anual. Esses servios que foram identificados como
grandes impactos no curto prazo dentro da BIA vai querer concentrar esforos
na reduo mtodos de preveno de risco - por exemplo, atravs da plena
resilincia e culpa tolerncia - enquanto um organizao que tem baixos
impactos de curto prazo seria melhor se adequa s opes de recuperao
global, conforme descrito nas sees seguintes. Aconselhamento e orientao
semelhante pode ser encontrada no BCI a Continuidade de Negcios Instituto
Guia de Boas Prticas.
Resposta medidas de risco

A maioria das organizaes tero que adotar uma abordagem equilibrada em


que a reduo de riscos e de recuperao so complementares e ambas so
necessrias. Isto implica a reduo, na medida do possvel, os riscos para o pro
continuadaviso do servio de TI e geralmente obtida atravs de
Gerenciamento de Disponibilidade. No entanto bem planejado, impossvel
eliminar completamente todos os riscos - por exemplo, um incndio em um
edifcio prximo, provavelmente, resultar em danos, ou pelo menos a negao
de acesso, como resultado da implementao de um cordo de isolamento.
Como regra geral, a chamada de uma recuperao capacidade s deve ser
tomado como um ltimo recurso. Idealmente, uma organizao deve avaliar
todos os riscos para reduzir a necessidade potencial para recuperar o negcio, o
que provvel que incluem os servios de TI.
As medidas de reduo 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 servio.
Medidas de reduo de risco tpicas incluem:

Instalao de no-break e de energia de backup para o computador


Sistemas tolerantes a falhas de crtica aplicaos, onde mesmo que
mnima tempo de inatividade inaceitvel - por exemplo, um sistema
bancrio
Arrays RAID e espelhamento de disco para LAN servidors para evitar a
perda de dados e garantir disponibilidade contnua de dados

ITIL V3 - Service Design - Pgina:

242 de 477

Poupar equipamento /componentes para ser utilizado em caso de falha


de equipamento ou componente - por exemplo, uma LAN de reposio
servidor j configurado com a configurao padro e disponvel para
substituir um servidor com defeito mnimo construir e configurao tempo
A eliminao de SpoFs, como pontos de acesso nico de rede ou fonte
de alimentao em um nico edifcio
Resilientes sistemas de TI e de redes
Terceirizao servios para mais de um provedor
Maior fsica e baseada em TI segurana controlars
Melhores controles para detectar interrupes de servio, tais como
incndio deteco sistemas, juntamente com sistemas de supresso
Uma ampla apoio e recuperao estratgia, Inclusive fora do local de
armazenamento.

As medidas acima no vai necessariamente resolver um problema ITSCM e


remover o risco totalmente, mas a totalidade ou uma combinao dos dois, pode
reduzir significativamente os riscos associados com a maneira pela qual os
servios so prestados ao negcio.
Armazenamento off-site

Um mtodo de resposta ao risco o de garantir que todos os dados vitais so


copiados e armazenados fora do local. Uma vez que o recuperao estratgia
tem sido definido, uma estratgia de backup apropriada devem ser adoptadas e
implementadas para apoi-lo. O backup estratgia deve incluir a remoo
(provavelmente dia) regular de dados (incluindo o CMS para facilitar a
recuperao) dos centros de dados principais para um local de armazenamento
adequado fora do local. Isto ir assegurar a recuperao de dados seguinte
relativamente menor operacional falha bem como desastres total e completa.
Bem como os dados eletrnicos, todas as outras informaes importantes e
documentos devem ser guardados fora do local, com o principal dos quais os
planos GCSTI.
Opes de recuperao ITSCM

Estratgia de uma organizao ITSCM um equilbrio entre a custar de medidas


de reduo de riscos e opo de recuperaos para apoiar a recuperao da
crtica processo de negcioes dentro de prazos acordados. A seguir, uma lista
das opes de TI potencial de recuperao que precisam ser considerados no
desenvolvimento da estratgia.
Manual de solues alternativas
Para certos tipos de servios, manuais de trabalho-around pode ser uma medida
eficaz interino por um perodo de tempo limitado, at o De servios de TI
retomada. Por exemplo, uma Service Desk o registro de chamadas de servio

ITIL V3 - Service Design - Pgina:

243 de 477

poderia sobreviver por um tempo limitado usando formulrios de papel ligados a


um computador porttil com uma planilha.
Acordos de reciprocidade
No passado, acordo de reciprocidades medidas de contingncia foram tpicos
onde acordos foram postas em prtica com outro organizao utilizando uma
tecnologia semelhante. Isto j no eficaz ou possvel para a maioria dos tipos
de sistemas de TI, mas ainda pode ser usado em casos especficos - por
exemplo, a criao de um acordo para compartilhar instalaes de alta
velocidade de impresso. Reciprocidade pode tambm ser usado para o
armazenamento para fora do local de apoios e outras informaes crticas.
Recuperao gradual
Esta opo (por vezes referido como 'espera frio') Inclui o proviso de
alojamento vazio, totalmente equipada com o poder, controles ambientais e de
infra-estrutura de cabeamento de rede local, ligaes de telecomunicaes, e
disponvel em uma situao de desastre para uma organizao para instalar o
seu equipamento prprio computador. No inclui o equipamento de computao
actual, portanto, no aplicvel para servios que requerem rpida
recuperao, Como configurar-tempo necessrio para a recuperao de
servios pode comear. Esta opo de recuperao recomendado apenas
para servios que podem suportar um atraso de tempo de recuperao em dias
ou semanas, no horas. Qualquer servio no-crtica que pode suportar este tipo
de atraso deve levar em conta o custo desta opo versus o benefcio para o
negcio antes de determinar se um recuperao gradual opo deve ser includo
nas opes ITSCM para a organizao.
O alojamento pode ser fornecido comercialmente por terceiro, Para uma taxa, ou
pode ser privado, (estabelecido pela prpria organizao) e, desde como um
servio fixo ou porttil.
Ainstalao porttil tipicamente um edifcio pr-fabricado fornecido por um
terceiro, e localiza-se, quando necessrio, num local pr-determinado acordado
com a organizao. Isto pode estar em outro local a alguma distncia a partir do
local de origem, talvez um outro edifcio propriedade. O equipamento informtico
substituio ter de ser planejada, mas fornecedors de equipamentos de
computao nem sempre garantem equipamento de substituio dentro de um
prazo fixo, embora eles normalmente faz-lo sob seus melhores esforos.
Recuperao intermediria
Esta opo (por vezes referido como 'espera passiva') selecionada por
organizaes que precisam recuperar instalaes de TI dentro de um tempo pr-

ITIL V3 - Service Design - Pgina:

244 de 477

determinado para evitar impactos ao meio processo de negcio. O tempo


predeterminado ter sido acordado com o negcio durante o BIA.
O mais comum a utilizao de instalaes comerciais, que so oferecidos por
organizaes de terceiros de recuperao para um nmero de assinantes,
espalhando o custo atravs daqueles assinantes. Instalaes comerciais
incluem frequentemente operao,sistema de gesto e suporte tcnico. O custo
varia de acordo com os servios solicitados, tais como processadores,
perifricos, comunicaes, e quo rapidamente os servios devem ser
restaurard.
A vantagem disto que o servio cliente pode ter acesso praticamente
instantneo a um site, abrigado em um edifcio seguro, em caso de um desastre.
Deve ser entendido, contudo, que o restaurao do servios no local pode levar
algum tempo, como atrasos podem ser encontrados enquanto o site reconfigurado para o organizao que invoca o servio, e da organizao
aplicaos e os dados precisam ser restaurados a partir de backups.
Uma desvantagem importante a potencialmente segurana implicaes da
execuo de servios de TI em um terceiroO centro de dados. Isso deve ser
levado em conta no planejamento de usar este tipo de facilidade. Para algumas
organizaes, o externo recuperao intermediria opo pode no ser
apropriado para isso.
Se o local for invocado, existe frequentemente uma taxa diria de utilizao do
servio em caso de emergncia, embora isso possa ser compensado com
adicional custar de seguro de trabalho.
Servios de recuperao de comerciais podem ser apresentadas de forma autosuficiente, porttil ou mvel, onde um sistema acordado entregue no local de
um cliente, dentro de um prazo acordado.
Recuperao rpida
Esta opo (por vezes referido como "hot standby"), prev recuperao rpida e
restaurao de servios e s vezes fornecida como uma extenso para o
recuperao intermediria fornecida por um provedor de recuperao de
terceiros. Algumas organizaes ir fornecer suas prprias instalaes dentro da
organizao, mas no em um local alternativo ao utilizado para as operaes
normais. Outros aplicar seus prprios internos locais segundo em um local
alternativo para fornecer mais resistente recuperao.
Onde existe uma necessidade de um rpido restabelecimento de um servio,
possvel "alugar" espao no local de recuperao e instalar servidors ou
sistemas com sistemas de aplicativos e as comunicaes j disponveis e dados
espelhado dos servidores operacionais. No caso de uma falha do sistema, os

ITIL V3 - Service Design - Pgina:

245 de 477

clientes podem, ento, recuperar e passar para o apoio facilidade com pouca
perda de servio. Isso geralmente envolve o restabelecimento dos sistemas e
servios crticos dentro de um perodo de 24 horas.
Recuperao imediata
Esta opo (tambm muitas vezes referida como "hot standby", "espelhamento",
"balanceamento de carga" ou "local split '), prev a imediata restaurao dos
servios, sem prejuzo do servio. Para servios crticos de negcios, as
organizaes requerem operao contnua ir fornecer suas prprias instalaes
dentro da organizao, mas no no mesmo local das operaes normais.
Equipamentos de TI ser suficiente "dual localizado" em qualquer local de uma
propriedade ou hospedado para executar o servio de competir a partir de
qualquer localizao em caso de perda de uma unidade, sem perda de servio
para o cliente. O segundo local pode ento ser recuperado, enquanto o servio
fornecido a partir do nico local opervel. Esta uma opo cara, mas pode ser
justificada por crtico processo de negcioes ou VBFs onde no disponibilidade
de um curto perodo pode resultar numa significativa impacto, Ou em que no
seria adequado para ser executado De servios de TIs numa terceiro'S
premissas para segurana ou outras razes. A instalao precisa ser localizado
separadamente e longe o suficiente do local de casa que no ser afectado por
uma catstrofe que afeta esse local. No entanto, estes espelhado servidors
opes e sites devem ser implementadas em estreita ligao com
Gerenciamento de Disponibilidade como eles suportam servios com elevados
nveis de disponibilidade.
O estratgia provvel que inclua uma combinao de medidas de resposta a
riscos e uma combinao do acima opo de recuperaos, tal como ilustrado
na Figura 4.25.

Figura 4.25 Exemplo conjunto de opes de recuperao

Figura 4.25 mostra que um nmero de opes pode ser utilizada para
proporcionar a continuidade do servio. Um exemplo da Figura 4.25 mostra que,

ITIL V3 - Service Design - Pgina:

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 porttil, enquanto os planos de recuperao para o servio
so concludas em uma "alternativarecuperao rpida'Site. Uma vez que o stio
tornou-se alternativa operacional, O Service Desk pode voltar a usar o servio
de TI. No entanto, o uso de local alternativo externo "rpida recuperao" ,
provavelmente, limitado no tempo, por isso durante a execuo temporariamente
a partir deste site, o 'site intermedirio "pode ser feita operacional e operaes
de longo prazo pode ser transferido para l.
Diferentes servios dentro de uma organizao exigem diferentes embutido
resilincia e opes de recuperao diferentes. Seja qual for a opo escolhida,
a soluo ter de ser custo-justificado. Como regra geral, quanto mais longo for
o negcio pode sobreviver sem um servio, a soluo mais barata ser. Por
exemplo, um sistema de sade crtico que requer operao contnua ser muito
dispendiosa, como a perda de potencial de servio tero de ser eliminados por
meio da utilizao de recuperao imediata, Enquanto um servio cuja ausncia
no afetar gravemente o negcio para uma semana ou assim poderia ser
apoiada por uma soluo muito mais barata, como recuperao intermediria.
Bem como a recuperao do equipamento de computao, o planejamento deve
incluir os recuperao de alojamento e infra-estrutura para a TI e usurio
pessoal. Outras reas a serem levados em conta so os servios essenciais,
como energia, telecomunicaes, gua, correios, correio, papel registros e o
material de referncia.
importante lembrar que a recuperao baseada em torno de uma srie de
acordos stand-by, incluindo alojamento, procedimentos e as pessoas, bem como
sistemas e telecomunicaes. Certas aes so necessrias para implementar
os acordos stand-by. Por exemplo:

Negociao para instalaes de terceiros de recuperao e de entrar em


um acordo contratual
Preparar e equipar o alojamento stand-by
Aquisio e instalao de stand-by sistemas de computador.

4.5.5.3 Estgio 3 - Implementao

Uma vez que o estratgia foi aprovado, o TI Plano de Continuidade do Servios


tm de ser produzidas em conformidade com a Plano de Continuidade de
Negcioss.
ITSCM planos precisam ser desenvolvidas para que as informaes necessrias
para sistemas crticos, servios e instalaes, quer continuar a ser prestado ou a
ser reintegrado dentro de um perodo aceitvel para o negcio. Uma
recuperao ITSCM exemplo plano est contida no Apndice K. Geralmente os

ITIL V3 - Service Design - Pgina:

247 de 477

Planos de Continuidade de Negcios contar com a disponibilidade de De


servios de TIs, instalaes e recursos. Como conseqncia disso, os planos
ITSCM necessidade de abordar todas as atividades para garantir que os
servios necessrios, instalaes e recursos so entregues em um estado
aceitvel operacional e so 'apto para o efeito"Quando aceito pela empresa. Isto
implica no s a restaurao do servios e instalaes, mas tambm o
conhecimento das dependncias entre eles, o teste necessria antes da entrega
(atuao, Funcional, operacional e de testes de aceitao) e do validao de
dados integridade e consistncia.
Note-se que os planos de continuidade so mais do que apenas a planos de
recuperao, e deve incluir a documentao das medidas de resilincia e as
medidas que tm sido postas em prtica para permitir a recuperao,
juntamente com explicaes do porqu de uma abordagem particular foi tomada
(isso facilita decises devem invocao determinar que a situao particular
requer uma modificao no plano). No entanto, o formato do plano deve permitir
o acesso rpido s informaes de recuperao em si, talvez como um apndice
que pode ser acessado diretamente. Todo o pessoal-chave devem ter acesso a
cpias de toda a documentao necessria recuperao.
Gesto da distribuio das plantas importante para garantir que as cpias so
disponveis para o pessoal chave em todas as vezes. Os planos devem ser
documentos controlados (com documentos formalizados mantido sob Gesto da
Mudana e Gerenciamento da Configurao controlo), para garantir que apenas
a ltima versos esto em circulao e cada beneficirio deve garantir que uma
cpia pessoal mantida fora do local.
O plano deve garantir que todos os detalhes sobre a recuperao dos servios
de TI aps um desastre so totalmente documentados. Deve ter detalhes
suficientes para permitir que um tcnico familiarizado com os sistemas a ser
capaz de seguir os procedimentos. O recuperao planos incluem detalhes
importantes, tais como o ponto de recuperao de dados, uma lista de sistemas
dependentes, a natureza do dependncia e seus pontos de recuperao de
dados, hardware e sistema de requisitos de software, detalhes de configurao e
referncias a informaes relevantes ou essenciais outro sobre o servio e
sistemas.
uma boa idia de incluir uma lista que abrange aces especficas
necessrias durante todas as fases de recuperao para o servio e do sistema.
Por exemplo, depois que o sistema foi restaurado para um estado operacional,
cheques, cheques de conectividade funcionalidade ou consistncia de dados e
verificaes de integridade devem ser realizadas antes de entregar o servio
para o negcio.
H uma srie de planos de tcnicas que podem existir dentro de um
organizao, Documentando os procedimentos de recuperao de uma normal

ITIL V3 - Service Design - Pgina:

248 de 477

operacional falha. O desenvolvimento e manuteno desses planos ser de


responsabilidade das equipes especializadas, mas ser coordenado pela equipe
de Gesto de Continuidade de Negcios. Estes sero adies teis ou
apndices para a pgina principal plano. Alm disso, os planos que precisam ser
integrados com o BCP principal so:

Plano de Emergncia: A interface para todos os servios de emergncia


e as atividades
Plano de Avaliao de Danos: Contendo detalhes de danos avaliao
contatos, processos e planos
Plano de Salvamento: Contendo informaes sobre contatos de
salvamento, atividades e processoes
Plano Vital Records: Detalhes de todas vital registros e de informao,
em conjunto com a sua localizao, que so crticas para a continuao
operao do negcio
Plano de Gerenciamento de Crises e Relaes Pblicas: Os planos no
comando e controlar de diferentes situaes de crise e gesto dos meios
de comunicao e relaes pblicas
Plano de alojamento e servios: Detalhando a gesto de alojamento,
instalaes e os servios necessrios para o seu funcionamento contnuo
Plano de Segurana: Mostrando como todos os aspectos da segurana
ser gerida em todos os sites de casa e locais de recuperao
Pessoal Plano: Contendo detalhes de como todas as questes de
pessoal ser gerida durante um incidente grave
Plano de Comunicao: Mostrando como todos os aspectos da
comunicao sero tratados e gerenciados com todas as reas
relevantes e partes envolvidas durante um incidente grave
Plano de Finanas e Administrao: Contendo detalhes dos mtodos e
processos alternativos para a obteno de autorizao de emergncia eo
acesso aos fundos essenciais durante um incidente grave.

Por fim, cada rea de negcio crtico responsvel pelo desenvolvimento de um


plano detalhando os indivduos que estaro nas equipes de resgate e as tarefas
a serem realizadas na invocao de disposies relativas recuperao.
O Plano ITSCM deve conter todas as informaes necessrias para recuperar
os sistemas de TI, redes e telecomunicaes em uma situao de desastre, uma
vez a deciso de invocar foi feito, e ento para gerir o negcio voltar ao normal
operao uma vez que a interrupo do servio foi resolvido. Uma das entradas
mais importantes para o desenvolvimento do plano o resultado de o Anlise de
Impacto no Negcio. Adicionalmente outras reas tero de ser analisada, tal
como Acordo de Nvel de Servios (SLA), segurana requisitos, instrues
operacionais e procedimentos e externa contratos. provvel que um separado
SLA com alvos alternativos tero sido acordado se funcionando em um local de
recuperao aps um desastre.

ITIL V3 - Service Design - Pgina:

249 de 477

Outras reas que precisam ser implementadas aps a aprovao do estratgia


so os seguintes:
Planejamento, organizao

Durante a recuperao de desastres processo, A estrutura organizacional ser


inevitavelmente diferente da operao normal e baseado em torno de:

Executivo - Incluindo a alta administrao / diretoria, com autoridade total


e controlo na organizao e responsvel pela gesto de crises e ligao
com outros departamentos, divises, organizaes, meios de
comunicao, reguladores, servios de emergncia, etc
Coordenao - Normalmente um nvel abaixo do grupo executivo e
responsvel pela coordenao do esforo de recuperao global dentro
da organizao
Recuperao - Uma srie de negcios e equipes de recuperao de
servios, representando as funes crticas de negcios e os servios que
devem ser estabelecidos para suportar essas funes. Cada equipe
responsvel por executar os planos dentro de suas reas prprias e de
ligao com a equipe, clientes e terceiros. Dentro dele as equipes de
recuperao devem ser agrupados por De servios de TI e aplicao. Por
exemplo, a equipe de infra-estrutura pode ter uma ou mais pessoas
responsveis para a recuperao de conexes externas, servios de voz,
redes locais, etc, e as equipes de apoio pode ser dividido por plataforma,
sistema operacional ou aplicativo. Alm disso, as prioridades de
recuperao para o servio de aplicao, ou a sua componentes
identificados durante a Anlise de Impacto no Negcio devem ser
documentadas dentro dos planos de recuperao e aplicados durante a
sua execuo.

Teste

A experincia tem mostrado que os planos de recuperao que no tenham sido


totalmente testados no 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 estratgia,espera arranjos, logstica,
planos de negcios e procedimentos de recuperao vai realmente trabalhar em
prtica.
O Provedor de servios de TI responsvel por assegurar que os servios de TI
podem ser recuperados nos prazos necessrios com a funcionalidade
necessria e exigida atuao aps a catstrofe.
Existem quatro tipos bsicos de testes que podem ser realizados:

ITIL V3 - Service Design - Pgina:

250 de 477

Walk-atravs 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 possvel aps
a produo de planta e em intervalos regulares de, pelo menos,
anualmente. Elas devem envolver o unidade de negcioss para auxiliar a
provar a capacidade para recuperar os servios adequadamente. Eles
devem, na medida do possvel, replicar uma invocao real de todos os
acordos stand-by e deve envolver partes externas se eles esto
planejados para serem envolvidos em uma invocao real. Os testes
devem no s provar recuperao dos servios de TI, mas tambm a
recuperao da processo de negcioes. Recomenda-se que um
observador independente registra todas as atividades dos testes e os
horrios da servio recuperao. Documentao do observador dos
testes ser de entrada vital para o post mortem posterior rever. Os testes
completos podem ser anunciados ou sem aviso prvio. O primeiro teste
do plano susceptvel de ser anunciado e cuidadosamente planejada,
mas os testes subsequentes podem ser 'saltado' em jogadores-chave
sem aviso. tambm essencial que muitas pessoas diferentes se
envolver, incluindo aqueles no muito familiarizados com o servio de TI e
sistemas, como as pessoas com mais conhecimento podem no estar
disponveis quando um desastre ocorre realmente.
Testes parciais tambm pode ser realizada em que a recuperao de
alguns elementos do conjunto plano testada, como servios individuais
ou servidors. Estes tipos de ensaios deve ser em adio ao ensaio
completo no, em vez da totalidade do teste. O teste completo a melhor
maneira de testar todos os servios que podem ser recuperados em
prazos necessrios e pode ser executado em conjunto sobre os sistemas
de recuperao.
Testes de cenrios pode ser usado para reaes de testes e planos para
condies especficas, eventos e cenrios. Eles podem incluir testes que
BCPs e TI Plano de Continuidade do ServioA interface com o outro,
assim como a interface com todos os outros planos envolvidos no
manuseamento e administrao de um incidente grave.

Todos os testes devem ser realizados contra cenrios de teste definidos, que
so descritos de forma to realista quanto possvel. Deve notar-se, contudo, que
mesmo a mais abrangente teste no cobre tudo. Por exemplo, em uma
interrupo do servio onde houve leso ou at mesmo a morte de colegas, a
reao do pessoal a uma crise no pode ser testada e os planos precisam fazer
a permisso para isso. Alm disso, os testes devem ter claramente definido
objetivos e Fator Crtico de Sucessos, que vai ser utilizado para determinar o
grau de sucesso do exerccio.
4.5.5.4 Fase 4 - Operao Contnua

Esta etapa consiste no seguinte:


ITIL V3 - Service Design - Pgina:

251 de 477

Sensibilizao, educao e formao - Esta deve cobrir o organizao


e, em particular, a organizao de TI, para a continuidade de servios
especficos de itens. Isso garante que todos os funcionrios esto cientes
das implicaes de continuidade de negcios e de continuidade de
servio e consider-las como parte de seu trabalho normal, e que todos
os envolvidos no plano foi treinado em como implementar suas aes.
Comente - Reviso peridica de todos os entregas a partir do ITSCM
processo precisa ser realizado para garantir que eles permanecem atuais.
Teste - Aps o teste inicial, necessrio estabelecer um programa de
testes regulares para assegurar que o crtico componentes da estratgia
so testadas, preferencialmente, pelo menos uma vez por ano, apesar de
testar TI Plano de Continuidade do Servios devem ser organizados em
conformidade com as necessidades de negcio e as necessidades do
SBDC. Todos os planos tambm devem ser testados aps cada grande
negcio mudar. importante que qualquer alterao tecnologia de TI
esto tambm includos no estratgia, Executadas de uma forma
adequada e testados para assegurar que funcionam corretamente dentro
do pr globalviso de TI aps um desastre. O apoio e recuperao de De
servios de TI tambm devem ser monitorizados e testados para
assegurar que, quando so necessrios durante um incidente principal,
eles vo operar conforme a necessidade. Este aspecto coberto com
mais detalhes no Operao de Servio publicao
Gesto da Mudana - O processo de Gerenciamento de Mudana deve
garantir que todas as alteraes so avaliados quanto ao seu potencial
impacto sobre os planos GCSTI. Se o planeado mudar invalidar os
planos, ento o plano deve ser atualizado antes de a mudana
implementada, e deve ser testado como parte do teste de mudana. Os
planos prprios devem estar sob Gesto da Mudana muito rigoroso e
Gerenciamento da Configurao controlar. Planos imprecisas e
capacidades de recuperao inadequado pode resultar na falha do
SBDC. Alm disso, em uma base contnua, sempre que houver novos
servios ou quando os servios tm grandes mudanas, essencial que
a BIA e avaliao de risco realizado no servio novo ou alterado eo
estratgia e planeja actualizado em conformidade.

Invocao

Invocao o ltimo teste da Continuidade de Negcios e Planos GCSTI. Se


todo o trabalho preparatrio foi concluda com xito, e planeja desenvolvido e
testado, em seguida, uma invocao do Plano de Continuidade de Negcioss,
deve ser um processo simples, mas, se os planos no foram testados, as falhas
podem ser esperados. importante que a devida considerao dada ao
projeto de todos os processos de chamada, para assegurar que eles so apto
para o efeito e interface com todos os outros processos de invocao relevantes.
Invocao um componente-chave dos planos, que devem incluir o processo de
invocao e orientao. Deve ser lembrado que a deciso de invocar,
ITIL V3 - Service Design - Pgina:

252 de 477

especialmente se uma instalao de recuperao de terceiros para ser usado,


no deve ser tomada de nimo leve. Custars estar envolvido e o processo
envolver a interrupo para o negcio. Esta deciso normalmente feita por
um 'gesto de crisesEquipa de Informao, compreendendo os gerentes
seniores das reas de negcio e suporte (incluindo TI), usando recolhidas
atravs de danos avaliao e de outras fontes.
A perturbao pode ocorrer em qualquer momento do dia ou da noite, de modo
que essencial que o processo de orientao sobre a chamada est
prontamente disponvel. Os planos devem estar disponveis para o pessoalchave no escritrio e fora do escritrio.
A deciso de invocar deve ser feito rapidamente, pois pode haver uma vantagem
de tempo envolvido no estabelecimento de instalaes de um local de
recuperao. No caso de um incndio do edifcio grave, a deciso pode ser
relativamente fcil de fazer. No entanto, no caso de falha de energia ou de
hardware culpa, Onde um resoluo esperado dentro de um curto perodo, o
prazo deve ser definido pelo qual tempo se o incidente no foi resolvido,
invocao ter lugar. Se usar provedores de servios externos, eles devem ser
avisados imediatamente se h uma chance de que a invocao poder ter lugar.
A deciso de invocar precisa de ter em conta o:

Extenso do dano e escopo da invocao potencial


Durao provvel do rompimento e indisponibilidade de instalaes e / ou
servios
Hora do dia / ms / ano eo impacto potencial de negcios. No final do
ano, a necessidade de invocar pode ser mais urgente, para garantir que o
processamento de fim de ano est concludo a tempo.

Por isso o design da invocao processo deve fornecer orientaes sobre como
todas essas reas e circunstncias 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:

Recuperao de apoio fitas ou uso de dados vaulting para recuperar


dados
Recuperao de documentao essencial, procedimentoimagens s,
estaes de trabalho, etc armazenados fora do local
Mobilizao do pessoal tcnicos adequados para ir ao recuperao local
para iniciar a recuperao dos sistemas e servios necessrios
Contactar e colocando em telecomunicaes alerta fornecedors apoio,
servios, aplicao fornecedores, etc, que podem ser necessrios para
realizar aes ou prestar assistncia no processo de recuperao.

ITIL V3 - Service Design - Pgina:

253 de 477

A invocao e recuperao inicial provvel que seja um momento de alta


atividade, que envolve longas horas para muitos indivduos. Isso deve ser
reconhecido e gerenciado pelos lderes da equipe de recuperao para garantir
que as pausas so fornecidos e evitar o "burn-out". Planejamento para deslocars
e handovers devem ser realizados para garantir que o melhor feito uso de
instalaes disponveis. Tambm extremamente importante para assegurar
que a actividade normal e tecnologia controlars permanecer no local durante a
recuperao de invocao, e voltar ao normal para garantir que as informaes
segurana mantida no nvel correto e que a proteco de dados preservada.
Uma vez que a recuperao foi completa, a empresa deve ser capaz de operar a
partir do local de recuperao no nvel determinado e acordado no estratgia e
relevantes SLA. O objetivo, No entanto, ser a de construir o negcio para nveis
normais, manter operao a partir do local de recuperao no curto prazo e
desocupar o local de recuperao no menor tempo possvel. Detalhes de todas
essas atividades precisam ser contido dentro dos planos. Se usar servios
externos, haver um perodo finito contratual para usar as instalaes.
Independentemente do perodo, 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 necessrio tempo de inatividade em horrio
comercial. importante que isso seja bem gerido e que todos os envolvidos
esto cientes de suas responsabilidades para garantir uma transio suave.

4.5.6 Triggers, entradas, sadas e interfaces


Muitos eventos podem desencadear atividade GCSTI. Estes incluem:

Novos ou alterados necessidades de negcios ou servios novos ou


alterados
Novas metas ou alterados dentro acordos, como SLRs, SLAs, ou OLAs
contratos
A ocorrncia de um incidente grave que requer avaliao para invocao
potencial de negcios ou de Planos de Continuidade de TI
Atividades peridicas, como a BIA ou atividades de anlise de risco, a
manuteno de planos de continuidade ou de outra reviso, reviso ou
relatar atividades
Avaliao das mudanas e participao em Alterar Conselho Consultivo
reunies
Comente e reviso de negcios e de TI planos e estratgias
Reviso e reviso de projetos e estratgias
O reconhecimento ou a notificao de uma mudana de risco ou impacto
de um processo de negcio ou VBF, uma De servios de TI ou
componente
Incio de testes de continuidade e planos de recuperao.

ITIL V3 - Service Design - Pgina:

254 de 477

Integrao e interfaces de existir a partir de ITSCM a todos os outros processos.


Exemplos importantes so os seguintes:

Gesto da Mudana - Todas as alteraes precisam ser considerados


para o seu impacto sobre os planos de continuidade, e se so
necessrias alteraes ao plano, atualizaes para o plano precisa ser
parte da mudana. O plano em si deve estar sob controle de
Gerenciamento de Mudanas.
Incidente e Gerenciamento de Problemas - Incidentes podem evoluir
facilmente para grandes incidentes ou desastres. Critrios claros
precisam ser acordadas e documentadas em para a invocao dos
planos GCSTI.
Gerenciamento de Disponibilidade - Realizao de Anlise de Risco e
implementao de respostas de risco devem ser estreitamente
coordenada com a disponibilidade processo para otimizar de mitigao de
risco.
Gerenciamento de Nvel de Servio - recuperao requisitos sero
acordados e documentados no SLAs. Diferente nvel de servios pode ser
acordado e documentado que poderia ser aceitvel em uma situao de
desastre.
Gerenciamento da Capacidade - Assegurar que h suficiente recursos
para permitir a recuperao nos computadores de substituio aps a
catstrofe.
Gerenciamento da Configurao - Os documentos do CMS os
componentes que formam a infra-estrutura ea relao entre os
componentes. Esta informao valiosa para todas as fases do ITSCM
ciclo de vida, A manuteno de planos e instalaes de recuperao.
Gesto de Segurana da Informao - Uma relao muito ntima entre
ITSCM e Gesto de Segurana da Informao. A grande falha de
segurana pode ser considerado um desastre, por isso, quando a
realizao de Anlise de Risco e BIA, segurana ser uma considerao
muito importante.

4.5.6.1 Entradas

Existem muitas fontes de entrada exigidos pelo processo ITSCM:

Informaes de negcios: a partir do organizaoEstratgia do negcio,


planos e planos financeiros, e informaes sobre suas necessidades
atuais e futuras
Informaes de TI: a partir da TI estratgia planos e atuais oramentos
A Estratgia de Continuidade de Negcios e um conjunto de Plano de
Continuidade de Negcioss: a partir de todas as reas do negcio
Informaes sobre o servio: a partir do processo de SLM, com detalhes
dos servios da Portflio de Servios e a Catlogo de Servios e meta de
nvel de servios dentro de SLAs e SLRs

ITIL V3 - Service Design - Pgina:

255 de 477

Informao financeira: a partir de Gesto Financeira, O custar de servio


profissionalviso, O custo de recursos e componentes
Alterar informao: desde o processo de Gerenciamento de Mudana,
com um programa de troca e uma necessidade de avaliar todas as
alteraes para o seu impacto em todos os planos ITSCM
CMS: que contm informaes sobre as relaes entre a empresa, a
servios, o servios de apoios e a tecnologia
Gesto de Continuidade de Negcios e Gerenciamento de
Disponibilidade programaes de testes
TI Plano de Continuidade do Servios e relatrios de ensaio de
fornecedor e parceiros, se for o caso.

4.5.6.2 Sadas

As sadas do ITSCM processo incluem:

A revista ITSCM poltica e estratgia


Um conjunto de planos ITSCM, incluindo todos os Planos de gesto de
crises, planos de emergncia e planos de recuperao de desastres,
juntamente com um conjunto de planos de apoio e contratos com
recuperao prestadores de servios
Anlise de Impacto no Negcio exerccios e relatrios, em conjunto com o
BCM e os negcios
Anlise de Risco e Gesto de opinies e relatrios, em conjunto com a
empresa, gerenciamento de disponibilidade e Gesto de Segurana
Um cronograma de testes ITSCM
ITSCM teste cenrios
Relatrios de ensaios e resenhas. ITSCM

Previses e relatrios de previso so utilizados por todas as reas para


analisar, prever e prever negcio e de TI cenrios e suas possveis solues.

4.5.7 Indicadores Chave de Desempenho


De servios de TIs so entregues e podem ser recuperadas para satisfazer
objetivo de negcios:

Regular auditars do ITSCM Planos para garantir que, em todos os


momentos, os requisitos de recuperao acordados do negcio pode ser
conseguida
Todos os objectivos de valorizao de servios esto acordadas e
documentadas em SLAs e so realizveis dentro dos Planos ITSCM
Teste regular e abrangente de Planos ITSCM
Revises peridicas so realizadas, pelo menos anualmente, dos
negcios e planos de continuidade de TI com as reas de negcio
Negociar e gerenciar todos os contratos necessrios com ITSCM terceiro

ITIL V3 - Service Design - Pgina:

256 de 477

Reduo global da risco e impacto de possvel falha de servios de TI.

Conscincia ao longo das organizaes dos planos:

Garantir a sensibilizao de impacto nos negcios, necessidades e


requisitos ao longo de TI
Garantir que todas as reas de servios de TI e funcionrios esto
preparados e capazes de responder a uma invocao dos Planos ITSCM
Comunicao regular dos objectivos ITSCM e responsabilidades dentro
da empresa apropriado e reas de servios de TI.

4.5.8 Gesto da Informao


ITSCM precisa registrar todas as informaes necessrias para manter um
conjunto abrangente de planos GCSTI. Esta base de informaes deve incluir:

Informaes da verso mais recente do BIA


A informao completa sobre o risco de dentro de um registro de riscos,
incluindo as respostas de avaliao de risco e de risco
A verso mais recente do BCM estratgia e BCPs
Detalhes relativos a todos os testes concludos e um cronograma de
todos os testes planejados
Detalhes de todos os Planos ITSCM e seus contedos
Detalhes de todos os outros planos associado a planos de ITSCM
Detalhes de toda a recuperao recuperao das instalaes existentes,
fornecedors e parceiros, acordos de recuperao e contratos, e
equipamento de reposio alternativa
Detalhes de todos apoio e recuperao processoes, horrios, sistemas e
meios de comunicao e seus respectivos locais.

Todas as informaes acima precisa ser integrado e alinhado com todas as


informaes BCM e todas as outras informaes exigidas pela GCSTI. As
interfaces com muitos outros processos so necessrias para garantir que este
alinhamento seja mantido.

4.5.9 Desafios, Fatores Crticos de Sucesso e riscos


Um dos grandes desafios ITSCM fornecer planos adequados, quando no h
processo de BCM. Se no houver um processo de BCM, ento provvel que
faa suposies incorretas sobre importncia do negcio de processo de
negcioes e, portanto, adotar as estratgias de continuidade e opes erradas.
Sem BCM, solues ITSCM caros e planos ser intil pela ausncia dos
respectivos planos e arranjos dentro do negcio. Alm disso, se o BCM est
ausente, ento a empresa pode deixar de identificar barato no-solues de TI e
dinheiro resduos no ineficazes e caros solues de TI.

ITIL V3 - Service Design - Pgina:

257 de 477

Em alguns organizaos, a percepo do negcio que a continuidade uma


responsabilidade de TI, e, portanto, a empresa assume que a TI ser
responsvel por desastre recuperao e que De servios de TIs continuar a
funcionar sob quaisquer circunstncias. Isto especialmente verdade em
algumas situaes terceirizados onde o negcio pode ser relutante em
compartilhar suas informaes com um BCM prestador de servios externo.
Se existe um processo BCM estabelecida, ento o desafio se torna um dos
alinhamento e integrao. ITSCM deve assegurar que informaes precisas
obtido a partir do processo de BCM nas necessidades, impacto e prioridades do
negcio, e que as informaes ITSCM e os planos esto alinhadas e integradas
com as da empresa. Tendo alcanado esse alinhamento, o desafio torna-se um
de mant-los alinhados pela administrao e controlar de negcios e de TI
mudar. essencial, portanto, que todos os documentos e planos so mantidos
sob estrito Gesto da Mudana e Gerenciamento da Configurao controlar.
Os CSFs principais para o processo ITSCM so:

TI servios so fornecidos e podem ser recuperadas para satisfazer


objetivo de negcios
Conscientizao de toda a organizao do negcio e TI Plano de
Continuidade do Servios.

Alguns dos principais riscos associados com ITSCM incluem:

Falta de compromisso do negcio para os processos e ITSCM


procedimentos
Falta de compromisso do negcio e falta de informao adequada sobre
os planos e estratgias futuras
A falta de compromisso da alta administrao ou a falta de recursos e / ou
oramento para o processo ITSCM
Os processos se concentrar muito nas questes de tecnologia e no o
suficiente sobre o De servios de TIs e as necessidades e prioridades da
empresa
Anlise de Risco e Gesto so realizadas isoladamente e no em
conjunto com Gerenciamento de Disponibilidade e Gesto de Segurana
Planos ITSCM e informaes tornam-se desatualizados e perder o
alinhamento com as informaes e os planos da empresa e BCM.

ITIL V3 - Service Design - Pgina:

258 de 477

4.6 Gesto de Segurana da Informao


4.6.1 Finalidade objetivo / / objetivo
"O objetivo do processo de ISM alinhar a segurana de TI com os negcios
segurana e garantir que a segurana da informao gerido de forma eficaz em
todos servio e Servio de Gesto de atividades.

ISM precisa ser considerado dentro da corporativa geral governo quadro. A


governana corporativa o conjunto de responsabilidades e prticas exercido
pela diretoria e gerncia executiva com o objetivo de fornecer estratgico
direo, garantindo a objetivos so alcanados, verificando os riscos esto a ser
geridos adequadamente e verificar que os recursos da empresa so utilizados
de forma eficaz.
A segurana da informao uma gesto atividade dentro da estrutura de
governana corporativa, que fornece a direo estratgica para atividades de
segurana e garante que os objetivos sejam alcanados. Ele ainda garante que
os riscos de segurana da informao so adequadamente gerenciados e que
os recursos de informao da empresa so usados de forma responsvel. O
objectivo do ISM fornecer um foco para todos os aspectos da TI segurana e
gerenciar todas as atividades de segurana de TI.
"Informao", o termo usado como um termo geral e inclui armazenamentos
de dados, bancos de dados e metadados. O objetivo da informao segurana
proteger os interesses dos que se basear em informaes, e os sistemas e
comunicaes que forneam as informaes, a partir de dano resultante do
falhas de disponibilidade, confidencialidade e integridade.
Para a maioria das organizaes, o objetivo da segurana cumprida quando:

A informao est disponvel e utilizvel quando necessrio, e os


sistemas que fornecem adequadamente pode resistir a ataques e
recuperar ou prevenir falhas (disponibilidade)
A informao observada por ou divulgadas somente para aqueles que
tm o direito de saber (confidencialidade)
A informao completa, precisa e protegidos contra modificaes no
autorizadas (integridade)
Negcio transaos, bem como o intercmbio de informao entre
empresas, ou com parceiros, pode ser confivel (autenticidade e norepdio).

Priorizao de confidencialidade, integridade e disponibilidade deve ser


considerado no contexto dos negcios e processo de negcioes. O principal guia
para definir o que deve ser protegida e do nvel de proteco tem que vir do
negcio. Para ser eficaz, segurana deve abordar todo processo de negcioes
de ponta a ponta e cobrir os aspectos fsicos e tcnicos. Apenas dentro do

ITIL V3 - Service Design - Pgina:

259 de 477

contexto das necessidades do negcio e os riscos a administrao pode definir a


segurana.

4.6.2 mbito
O ISM processo deve ser o ponto focal para todas as questes de segurana de
TI, e deve assegurar que um Poltica de Segurana da Informao produzido,
mantido e imposto que cobre o uso e abuso de todos os sistemas e servios de
TI. ISM precisa entender o total de TI e ambiente de segurana de negcios,
incluindo a:

Poltica de Negcios e planos de segurana


Negcio atual operao e os seus segurana requisitos
Futuros planos de negcio e requisitos
Requisitos legais
Obrigaes e responsabilidades em matria de segurana contidos SLAs
O negcio e riscos de TI e sua gesto.

Compreender tudo isto permitir ISM para assegurar que todos os actuais e
futuros aspectos de segurana e os riscos do negcio so custo-benefcio
gerenciado.
O processo de ISM deve incluir:

A produo, manuteno, distribuio e aplicao de uma Poltica de


Segurana da Informao e as polticas de segurana de apoio
Compreender os requisitos acordados de segurana atuais e futuras do
negcio e da poltica de segurana existente e planos de negcio
Implementao de um conjunto de controlos de segurana que suportam
o Poltica de Segurana da Informao e gerenciar os riscos associados
ao acesso a servios, informaes e sistemas
Documentao de todos os segurana controles, em conjunto com a
operao e manuteno dos controles e seus riscos associados
Gesto de fornecedors e contratos sobre o acesso a sistemas e servios,
em conjunto com Gesto de Fornecedores
Gesto de todas as violaes de segurana e incidentes associados a
todos os sistemas e servios
A melhoria proativa de controles de segurana e gesto de risco de
segurana e reduo de riscos de segurana
Integrao de aspectos de segurana em todos os outros processos de TI
SM.

Para conseguir informao eficaz segurana governana, a gesto deve


estabelecer e manter um Sistema de Gesto da Segurana (SGSI) para orientar
a desenvolvimento e gesto de um programa abrangente de segurana da
informao que suporta o objetivo de negcios.

ITIL V3 - Service Design - Pgina:

260 de 477

4.6.3 Valor para o negcio


ISM garante que uma Poltica de Segurana da Informao mantida e aplicada
que atende s necessidades da Poltica de Segurana de Negcios e as
exigncias da empresa governo. ISM aumenta a conscincia da necessidade de
segurana dentro de todos os servios de TI e ativoss ao longo do organizao,
Assegurando que o poltica apropriada para as necessidades da organizao.
ISM gerencia todos os aspectos de TI e segurana da informao em todas as
reas de TI e Servio de Gesto de atividade.
ISM oferece garantia de processo de negcioes impondo controles de
segurana apropriados em todas as reas de TI e de gesto de TI risco em linha
com os negcios e corporativo gesto de risco processos e orientaes.

4.6.4 Polticas / princpios / conceitos bsicos


Empresarial prudente prticas exigem que os processos de TI e iniciativas
alinhadas com os processos de negcios e objetivos. Isso fundamental quando
se trata de segurana de informaes, que devem ser estreitamente alinhados
com a segurana de negcios e necessidades de negcio. Alm disso todos os
processos dentro da organizao de TI deve incluir segurana consideraes.
Gesto executiva responsvel pela organizaoInformao 's e encarregado
de responder a questes que afetam sua proteo. Alm disso, os conselhos de
administrao so esperados para fazer a segurana da informao uma parte
integrante da governana corporativa. Todos Provedor de servios de TI
organizaes de produtores devem garantir que eles tm uma poltica
abrangente ISM (s) e os controles de segurana necessrios para acompanhar e
fazer cumprir as polticas.
4.6.4.1 estrutura de segurana

O Gesto de Segurana da Informao processo e um quadro geralmente


consistem em:

Um Poltica de Segurana da Informao e polticas especficas de


segurana que tratam cada aspecto do estratgia, Controles e regulao
Um Sistema de Gesto da Segurana (SGSI), contendo os padres de
gesto, procedimentos e diretrizes de apoio s polticas de segurana da
informao
A estratgia de segurana abrangente, intimamente ligada aos objectivos
do negcio, estratgias e planos
Uma estrutura de segurana organizacional eficaz
Um conjunto de controles de segurana para apoiar a poltica
A gesto de riscos de segurana

ITIL V3 - Service Design - Pgina:

261 de 477

Processos de monitoramento para garantir observncia e fornecer


feedback sobre eficcia
Estratgia de comunicao e um plano para a segurana
Formao e sensibilizao estratgia e plano.

4.6.4.2 A Poltica de Segurana da Informao

Informaes Gesto de Segurana atividades devem ser focado e dirigido por


uma informao geral Poltica de Segurana e um conjunto de reforar as
polticas de segurana especficas. O ITP deve ter o total apoio do executivo de
topo de gesto de TI e, idealmente, o apoio e compromisso da gesto de topo
executivo de negcios. O poltica deve cobrir todas as reas de segurana, Ser
o caso, satisfazer as necessidades do negcio e deve incluir:

Um total Poltica de Segurana da Informao


Usar e abusar de poltica de TI ativos
Uma poltica de controle de acesso
Uma poltica de controle de senha
Uma poltica de e-mail
Uma poltica de internet
Uma poltica anti-vrus
Uma informao classificao poltica
Adocumento poltica de classificao
A poltica de acesso remoto
A poltica em matria de fornecedor acesso de De servios de TI,
Informao e componentes
Um ativos disposio poltica.

Essas polticas devem estar amplamente disponvel a todos clientes e usurios,


e suas observncia deve ser referido em todas as SLRs, SLAs, contratos e
acordos. As polticas devem ser autorizados pela gerncia executiva de topo
dentro do negcio e de TI, e de conformidade com eles deve ser aprovado em
uma base regular. Todos segurana polticas devem ser revistas - e, se
necessrio, revisto - em pelo menos uma vez por ano.
4.6.4.3 O Sistema de Gesto da Segurana (SGSI)

A estrutura ou o ISMS sua vez, fornece uma base para o desenvolvimento de


um programa de segurana de baixo custo de informao que suporta o objetivo
de negcios. Que ir envolver os Quatro Ps de pessoas, processos, produtos e
tecnologia, bem como parceiros e fornecedors para garantir altos nveis de
segurana esto no lugar.
A ISO 27001 o formal padro contra a qual as organizaes podem procurar
independente certificado do seu SGSI (ou seja, suas estruturas para projetar,
implementar, gerenciar, manter e reforar os processos de segurana da
informao e controlars sistemtica e consistente ao longo das organizaes). O
ITIL V3 - Service Design - Pgina:

262 de 477

SGSI mostrado na Figura 4.26 mostra uma abordagem que amplamente


utilizado e baseada no aconselhamento e orientao descrita em muitas
fontes, incluindo ISO 27001.

Figura 4.26-Quadro para o gerenciamento de segurana de TI

Os cinco elementos dentro deste quadro so os seguintes:


Controlar
O objetivos de um elemento de controle da ISMS so os seguintes:

Estabelecer um quadro de gesto para iniciar e gerenciar informaes


segurana no organizao
Estabelecer uma estrutura de organizao para elaborar, aprovar e
implementar o Poltica de Segurana da Informao
Atribuir responsabilidades
Estabelecer e controlar a documentao.

Plano
O objetivo do plano elemento do SGSI conceber e recomendar as medidas de
segurana apropriadas, baseadas em um entendimento das exigncias da
organizao.
Os requisitos sero recolhidas a partir de fontes como a negcios e servios
risco, Planos e estratgias, SLAs e OLAs e as responsabilidades legais, morais
e ticos para informaes segurana. Outros fatores, como a quantidade de
recursos disponveis e da organizao prevalecente cultura e atitudes em
relao segurana, deve ser considerada.

ITIL V3 - Service Design - Pgina:

263 de 477

A Poltica de Segurana da Informao define a atitude da organizao e


postura em matria de segurana. Este deve ser um documento de toda a
organizao, no apenas aplicvel ao Provedor de servios de TI. A
responsabilidade pela manuteno do documento cabe ao Gerente de
Segurana da Informao.
Executar
O objectivo da implementao do ISMS assegurar que apropriado
procedimentos, ferramentas e controlars esto no local para apoiar o Poltica de
Segurana da Informao.
Entre as medidas esto:

Prestao de contas para ativos - Gerenciamento da Configurao eo


CMS so inestimveis aqui
Informaes classificao - Informao e repositrios devem ser
classificados de acordo com a sensibilidade ea impacto de divulgao.

O sucesso da implementao dos controles de segurana e das medidas


depende de uma srie de fatores:

A determinao de uma poltica clara e consensual, integrado com as


necessidades do negcio
Segurana procedimentos que so justificadas, adequadas e apoiado
pela alta administrao
O marketing eficaz e educao em requisitos de segurana
Um mecanismo para a melhoria.

Avaliao
O objetivos da avaliao elemento do ISMS so os seguintes:

Supervisionar e verificar observncia com a poltica de segurana e


requisitos de segurana em SLAs e OLAs
Realizar regularmente auditars de segurana tcnica dos sistemas de TI
Fornecer informaes aos auditores externos e reguladores, se
necessrio.

Manter
Os objectivos do presente elemento de manter o ISMS so os seguintes:

Melhorar acordos de segurana tal como especificado, por exemplo, SLA


e OLAs
Melhorar a implementao de segurana medidas e controles.

ITIL V3 - Service Design - Pgina:

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 Gesto da Segurana (SGSI) ou quadro. Este ciclo descrito em
mais detalhe na publicao de Melhoria de Servio Continuada.
A governao da segurana
Governana de segurana da informao, quando devidamente implementado,
deve fornecer seis bsica resultados:

Alinhamento estratgico:
Os requisitos de segurana deve ser impulsionada por exigncias
corporativas
Solues de segurana precisam se encaixar processos
empresariais
Investimento em informao segurana devem estar alinhados
com a empresa estratgia e acordada no perfil de risco.
Entrega de valor:
Um conjunto padro de prticas de segurana, ou seja, os
requisitos de segurana de linha de base melhores prticass
Devidamente priorizadas e distribudas esforo para reas com
maior impacto e benefcio do negcio
Solues institucionalizadas e comoditizado
Solues completas organizao, cobertura e processo, bem como
a tecnologia
Uma cultura de melhoria contnua.
Gesto de riscos:
Consensual no perfil de risco
Compreenso de exposio ao risco
Conscincia de gesto de risco prioridades
Mitigao de riscos
Aceitao de riscos / deferncia.
Gesto de desempenho:
Conjunto definido, concordou e significativa de mtricos
Processo de medio que vai ajudar a identificar deficincias e
fornecer feedback sobre os progressos realizados questes
resolver
Garantia independente.
Gesto de recursos:
Conhecimento capturado e disponvel
Documentado segurana processos e prticas
Arquitetura de segurana desenvolvido (s) para utilizar
eficientemente os recursos de infra-estrutura.
Garantia de processo de negcio.

ITIL V3 - Service Design - Pgina:

265 de 477

4.6.5 as atividades de processo, mtodos e tcnicas


A finalidade do processo de ISM assegurar que o segurana no que diz
respeito aos aspectos servios e tudo Servio de Gesto de atividades so
adequadamente geridos e controlados de acordo com as necessidades do
negcio e riscos:
As principais atividades dentro do processo ISM so:

Produo, rever e reviso de uma estratgia global Poltica de Segurana


da Informao e um conjunto de polticas de apoio especficas
Implementao, comunicao e execuo do segurana polticas
Avaliao e classificao de todas as informaes ativoss e
documentao
Implementao, reviso, reviso e melhoramento de um conjunto de
segurana controlars e avaliao de risco e respostas
Monitoramento e gesto de todos segurana violaes e incidentes de
segurana importantes
Relatrios, anlise e reduo dos volumes e impacto de violaes de
segurana e incidentes
Programao e realizao de revises de segurana, auditars e os testes
de penetrao.

As interaces entre estas actividades essenciais so ilustradas na Figura 4.27.

ITIL V3 - Service Design - Pgina:

266 de 477

Figura 4.27 TI processo de Gesto de Segurana

Desenvolvidos Gesto de Segurana da Informao processos, juntamente com


os mtodos, ferramentas e tcnicas, constituem o segurana estratgia. O
gerente de segurana deve garantir que tecnologias, produtos e servios esto
no local e que o total poltica desenvolvida e bem publicados. O gerente de
segurana tambm responsvel pela arquitetura de segurana, autenticao,
autorizao e administrao recuperao.
A estratgia de segurana tambm precisa considerar como ele vai se implantar
boas prticas de segurana em todas as reas do negcio. Treinamento e
conscientizao so vitais na geral estratgia, Conforme segurana muitas
vezes o mais fraco na fase usurio final. aqui, tambm, que h uma
necessidade de desenvolver mtodos e processos que permitem que as
polticas e normas para ser mais fcil de ser seguido e implementado.
Recursos precisam ser atribudos para acompanhar a evoluo destas
tecnologias e os produtos que eles suportam. Por exemplo, a privacidade
continua a ser importante e, cada vez mais, o foco da regulamentao do
governo, fazendo privacidade observncia tecnologia tecnologias um importante
facilitador.
4.6.5.1 Os controles de segurana

O Gerente de Segurana da Informao deve entender que a segurana no


um passo na ciclo de vida de servios e sistemas de segurana e que no pode
ser resolvido atravs da tecnologia. Em vez disso, a segurana da informao
deve ser parte integrante de todos os servios e sistemas e um curso processo
que tem de ser gerida de forma contnua atravs de um conjunto de comandos
de segurana, como mostrado na Figura 4.28.

ITIL V3 - Service Design - Pgina:

267 de 477

Figura 4,28 controles de segurana para ameaas e incidentes

O conjunto de controles de segurana deve ser projetado para apoiar e reforar


o Poltica de Segurana da Informao e para minimizar a todas as ameaas
reconhecidos e identificados. Os controles sero consideravelmente mais custoefetiva se includo no projeto de todos os servios. Isto ir assegurar a proteo
contnua de todos os servios existentes e que os novos servios eo acesso a
eles esto em linha com a poltica.
As medidas de segurana podem ser utilizados numa fase especfica na
preveno e tratamento de incidentes de segurana, conforme ilustrado na
Figura 4.28. Segurana incidentes so causados no apenas por ameaas
tcnicas - as estatsticas mostram que, por exemplo, a haste grande maioria de
erros humanos (intencional ou no) ou erros processuais, e muitas vezes tm
implicaes em outras reas, tais como segurana, legais ou de sade.
As etapas que se seguem podem ser identificados. No incio, h um risco de que
uma ameaa se materializar. Uma ameaa pode ser qualquer coisa que perturba
o processo de negcio ou tem impacto negativo sobre o negcio. Quando um
ameaa materializa, falamos de uma segurana incidente. Este incidente de
segurana pode resultar em danos (para informaes ou para bens) que tem de
ITIL V3 - Service Design - Pgina:

268 de 477

ser reparado ou corrigido. Medidas adequadas podem ser seleccionadas para


cada uma destas fases. A escolha das medidas depender da importncia
atribuda informao.

Preventivo:segurana medidas so utilizadas para prevenir um incidente


ocorra. O exemplo mais conhecido de medidas preventivas a atribuio
de acesso direitos a um grupo limitado de pessoas autorizadas. Os
requerimentos adicionais associados com esta medida incluem o controle
de direitos de acesso (concesso, manuteno e retirada de direitos),
autorizao (identificao de quem permitido o acesso a que
informaes e usar as ferramentas), identificao e autenticao
(confirmando que est buscando acesso) e controle de acesso (garantir
que somente pessoas autorizadas podem ter acesso).
Redutiva: Novas medidas podem ser tomadas com antecedncia, para
minimizar possveis danos que possam ocorrer. Estes so "reducionistas"
medidas. Conhecer exemplos de medidas de reduo esto fazendo
regularmente apoios e a desenvolvimento, Testes e manuteno de
planos de contingncia.
Detetive: Se um incidente ocorre, importante descobrir o mais
rapidamente possvel - deteco. Um exemplo familiar desta est
monitorando, ligado a um procedimento de alerta. Outro exemplo um
programa antivrus.
Repressivo: Medidas so ento usados para neutralizar qualquer
continuao ou a repetio do incidente de segurana. Por exemplo, um
endereo de conta ou rede est temporariamente bloqueada aps
inmeras tentativas fracassadas de logon ou a reteno de um carto
quando vrias tentativas so feitas com um nmero PIN errado.
Corretivo: O dano reparado, tanto quanto possvel, utilizando as
medidas correctivas. Por exemplo, medidas corretivas incluem a
restaurao do backup, ou regressar a uma situao estvel anterior (rollback, back-out). Fallback tambm podem ser vistos como uma medida
corretiva.

A documentao de todos os controles devem ser mantidos para refletir com


preciso a sua operao, A manuteno e o seu mtodo de operao.
4.6.5.2 Gesto de violaes de segurana e incidentes

Em caso de violaes graves de segurana ou incidentes, um avaliao


necessrio 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 no
deve ser limitada a casos graves de segurana. Todas as violaes de
incidentes de segurana e de segurana precisam ser estudados a fim de obter
um quadro completo da eficcia do segurana medidas como um todo. Um
relatrio procedimento para incidentes de segurana necessrio para ser
capaz de avaliar a eficcia e eficincia da segurana presente mede com base

ITIL V3 - Service Design - Pgina:

269 de 477

em uma viso de todos os incidentes de segurana. Isto facilitado por meio da


manuteno de ficheiros de registo e de controlo, e, claro, o registro de
incidentes da Service Desk funo. A anlise destas estatsticas sobre questes
de segurana deve levar a aes de melhoria voltadas para a reduo da
impacto e volume de todas as violaes e incidentes de segurana, em conjunto
com Gerenciamento de Problemas.

4.6.6 Triggers, entradas, sadas e interfaces


ISM de atividade pode ser desencadeada por vrios eventos. Estes incluem:

Novos ou alterados corporativa governo diretrizs


Nova poltica de segurana ou alterados Negcios
Novos ou alterados corporativa gesto de risco processoes e as diretrizes
Novos ou alterados necessidades de negcios ou servios novos ou
alterados
Requisitos novos ou alterados dentro de acordos, como SLRs, ou SLAs,
Olas contratos
Comente e reviso de negcios e de TI planos e estratgias
Reviso e reviso de projetos e estratgias
Servio ou componente segurana violaes ou avisos, eventos e
alertars, incluindo limiar eventos, relatrio de exceos
Atividades peridicas, tais como a reviso, reviso ou relatrios, incluindo
a reviso e reviso ISM de polticas, relatrios e planos
O reconhecimento ou a notificao de uma mudana de risco ou o
impacto de um processo de negcio ou VBF, uma De servios de TI ou
componente
Pedidos de outras reas, particularmente SLM para a assistncia com
questes de segurana.

A implementao eficaz e eficiente de um Poltica de Segurana da Informao


dentro de um organizao ir, em grande medida, dependente bom Servio de
Gesto de processos. Na verdade, a implementao efetiva de alguns
processos pode ser visto como um pr-requisito para o controle de segurana
eficaz. As interfaces de chave que tem ISM com outros processos so os
seguintes:

Incidentes e Gerenciamento de Problemas: na prestao de assistncia


com o resoluo e justificao posterior e correo de segurana
incidentes e problemas. O Gerenciamento de Incidentes processo deve
incluir a capacidade de identificar e lidar com incidentes de segurana.
Service Desk e Operao de Serviopessoal s deve "reconhecer" um
incidente de segurana.
ITSCM: com a avaliao de impacto nos negcios e de risco, e os
prviso de resilincia, Fail-over e recuperao mecanismos. A
segurana uma questo importante quando os planos de continuidade

ITIL V3 - Service Design - Pgina:

270 de 477

so testados ou invocado. A ITSCM trabalhando plano um obrigatria


exigncia para a ISO 27001.
SLM: assistncia com a determinao de requisitos de segurana e de
responsabilidades ea sua incluso dentro de SLRs e SLAs, juntamente
com a investigao e resoluo de servio e componente segurana
violaes.
Gesto da Mudana: ISM deve ajudar com a avaliao de cada mudana
para impacto em controles de segurana e de segurana. Tambm ISM
podem fornecer informaes sobre alteraes no autorizadas.
Questes legais e de RH devem ser consideradas na investigao
segurana questes.
Gerenciamento da Configurao dar a capacidade de fornecer
informaes precisas ativos informaes para ajudar com as
classificaes de segurana. Ter um CMS precisa , portanto,
extremamente til entrada ISM.
A segurana muitas vezes visto como um elemento de Gerenciamento
de Disponibilidade, Com integridade, confidencialidade e disponibilidade
(CIA), sendo a essncia de Disponibilidade e ISM. Alm disso, o ISM
deve trabalhar tanto com gerenciamento de disponibilidade e ITSCM para
realizar anlise de risco integrada e exerccios de gesto.
Gerenciamento da Capacidade deve considerar implicaes de
segurana, quando a seleo e introduo de novas tecnologias. A
segurana uma considerao importante quando da aquisio de
qualquer nova tecnologia ou software.
Gesto Financeira deve fornecer fundos suficientes para financiar os
requisitos de segurana.
Gesto de Fornecedores deve ajudar com a gesto conjunta de
fornecedores e seu acesso a servios e sistemas, bem como os termos e
condies a serem includos no contratos sobre fornecedor
responsabilidades.

4.6.6.1 Entradas

Gesto de Segurana da Informao ter que obter a entrada de muitas reas,


incluindo:

Informaes de negcios: de negcio da organizao estratgia, Os


planos e os planos financeiros e informaes sobre suas necessidades
atuais e futuras.
Governana corporativa e de negcios segurana polticas e diretrizs,
planos de segurana, Anlise de Risco e respostas
Informaes de TI: da estratgia de TI, planos e atual oramentos
Informaes sobre o servio: a partir do SLM processo com detalhes dos
servios da Portflio de Servios e a Catlogo de Servios e meta de
nvel de servios dentro de SLAs e SLRs, e, possivelmente, a partir da
monitoramento de SLAs, servio de opinies e violaes dos SLAs

ITIL V3 - Service Design - Pgina:

271 de 477

Risco de processos e relatrios de anlise: a partir de ISM,


Gerenciamento de Disponibilidade e ITSCM
Detalhes de todos os eventos de segurana e violaes: de todas as
reas de TI e de SM, especialmente Gerenciamento de Incidentes e
Gerenciamento de Problemas
Alterar as informaes: a partir do Gesto da Mudana com um processo
de Alterar agendamento e uma necessidade de avaliar todas as
alteraes para o seu impacto em todos os segurana polticas, planos e
controlars
CMS: que contm informaes sobre o relaos entre o negcio, Os
servios, servios de apoios e a tecnologia
Detalhes do parceiro e fornecedor Acesso: a partir de Gesto de
Fornecedores e gerenciamento de disponibilidade no acesso externo ao
servios e sistemas.

4.6.6.2 Sadas

Os resultados produzidos pelo Informao Gesto de Segurana processo so


utilizados em todas as reas e incluir:

Um total Gesto de Segurana da Informao Poltica, juntamente com


um conjunto de polticas de segurana especficas
A Segurana do Sistema de Informao de Gesto (SIGE), contendo
todas as informaes relativas ao ISM

Avaliao de risco de segurana revisto processoes e os relatrios

Um conjunto de segurana controles, juntamente com detalhes do


operao e manuteno e os riscos associados
Auditorias de segurana e relatrios de auditoria
Segurana horrios de testes e planos, incluindo testes de segurana e
testes de penetrao de segurana e outros relatrios
Um conjunto de classificaes de segurana e de um conjunto de
informao classificada ativoss
Comentrios e relatrios de violaes de segurana e incidente graves
Polticas, processos e procedimentos para scios-gerentes e fornecedors
e seu acesso a servios e informaes.

4.6.7 Indicadores Chave de Desempenho


Muitos KPIs e mtricos pode ser usada para avaliar a eficcia e eficincia do
processo de ISM e actividades. Estas mtricas precisam ser desenvolvidos a
partir do servio, cliente e perspectiva de negcios tais como:

Empresas protegido contra violaes de segurana:

ITIL V3 - Service Design - Pgina:

272 de 477

Diminuio do percentual de violaes de segurana relatados ao


Service Desk
Diminuio percentual no impacto de violaes de segurana e
incidentes
Aumento percentual em conformidade com SLA segurana
clusulas.
A determinao de uma clara e consensual poltica, Integrado com as
necessidades do negcio: diminuio do nmero de no-conformidades
do processo ISM com a poltica de segurana de negcios e processos.
Procedimentos de segurana que so justificadas, adequadas e apoiado
pela alta administrao:
Aumento do aceitao e conformidade dos procedimentos de
segurana
Aumento do apoio e comprometimento da alta administrao.
Um mecanismo para melhoria:
O nmero de melhorias sugeridas para segurana procedimentos e
controlars
Diminuio do nmero de segurana no-conformidade detectada
durante exames e testes de segurana.
A segurana da informao uma parte integrante de todos os De
servios de TIs e tudo ITSM processoES: aumento do nmero de servios
e conformant processos com os procedimentos de segurana e controles.
O marketing eficaz e educao em requisitos de segurana, a
sensibilizao do pessoal de TI da tecnologia de suporte dos servios:
Uma maior sensibilizao da poltica de segurana e de seu
contedo, em todo o organizao
Aumento percentual de completude do tcnico Catlogo de
Servios contra componentes de TI apoiando os servios
Service Desk apoio a todos os servios.

4.6.8 Gesto da Informao


Todas as informaes necessrias pelo ISM deve ser contido dentro dos SIGE.
Isto deve incluir todos segurana controles, riscos, violaes, processos e
relatrios necessrios para apoiar e manter a Poltica de Segurana da
Informao e o ISMS. Esta informao dever abranger todos os servios de TI
e componentes e precisa ser integrado e mantido em alinhamento com todos os
outros sistemas de TI de gesto da informao, em especial o Portflio de
Servios e do. CMS Os SIGE tambm ir fornecer a entrada para auditorias de
segurana e revises e para as atividades de melhoria contnua to importante
para todos ISMSs. Os SIGE tambm ir fornecer valiosa contribuio para o
projeto de novos sistemas e servios.

ITIL V3 - Service Design - Pgina:

273 de 477

4.6.9 Desafios, Fatores Crticos de Sucesso e riscos


ISM enfrenta muitos desafios no estabelecimento de uma poltica de segurana
adequada informao com um processo efetivo de apoio e controles. Um dos
maiores desafios garantir que haja um apoio adequado da negcio, Segurana
empresarial e de gesto snior. Se estes no estiverem disponveis, ser
impossvel estabelecer um processo ISM eficaz. Se no houver apoio da
gerncia snior de TI, mas no h suporte do negcio, a TI segurana controlos
e avaliao de risco ser severamente limitado no que eles podem alcanar por
causa desta falta de apoio da empresa. intil execuo de polticas de
segurana, procedimentos e controles em TI se estes no podem ser aplicadas
em toda a empresa. O maior uso de servios de TI e ativoss est fora da TI, e
por isso so a maioria das ameaas e riscos de segurana.
Em algumas organizaes a percepo do negcio que a segurana uma
responsabilidade de TI, e, portanto, a empresa assume que a TI ser
responsvel por todos os aspectos de segurana de TI e que os servios de TI
sero devidamente protegidos. No entanto, sem o apoio e empenho do pessoal
de negcios e de negcios, o dinheiro investido nos controlos de segurana
caros e procedimentos sero amplamente desperdiado e que a maioria ir ser
ineficaz.
Se houver um negcio segurana processo estabelecido, o desafio torna-se um
de alinhamento e integrao. ISM deve assegurar que informaes precisas
obtido a partir do processo de segurana de negcios com as necessidades, os
riscos, impacto e prioridades do negcio e que as polticas ISM, informaes e
planos esto alinhadas e integradas com as da empresa. Tendo alcanado esse
alinhamento, o desafio torna-se um de mant-los alinhados pelo gerenciamento
e controle dos negcios e de TI mudar usando estrita Gesto da Mudana e
Gerenciamento da Configurao controlar. Mais uma vez, isto requer o apoio e
compromisso da empresa e gerncia snior.
Os CSFs principais para o processo de ISM so:

Empresas protegidos contra segurana violaes


A determinao de uma clara e consensual poltica, Integrado com as
necessidades do negcio
Procedimentos de segurana que so justificadas, adequadas e apoiado
pela alta administrao
O marketing eficaz e educao em requisitos de segurana
Um mecanismo para a melhoria
A segurana da informao uma parte integral de todos os servios de
TI e todos os processos de ITSM
O disponibilidade de servios no seja comprometida por incidentes de
segurana

ITIL V3 - Service Design - Pgina:

274 de 477

Propriedade clara e conscientizao das polticas de segurana entre a


comunidade de clientes.

Sistemas de informao pode gerar muitos benefcios diretos e indiretos, e como


muitos riscos diretos e indiretos. Estes riscos tm levado a uma lacuna entre a
necessidade de proteger os sistemas e servios eo grau de proteo aplicado. A
diferena causada por fatores internos e externos, incluindo o uso
generalizado da tecnologia, a crescente dependncia do negcio em TI, a
crescente complexidade e da interconexo dos sistemas, o desaparecimento
das fronteiras tradicionais de organizao e cada vez mais onerosas exigncias
regulatrias.
Isto significa que no so novas reas de risco que podem ter um significativo
impacto em operaes crticas de negcios, tais como:

Crescentes exigncias de disponibilidade e robustez


Crescente potencial de utilizao indevida e abusiva de sistemas de
informao que afeta os valores de privacidade e tica
Perigos externos de hackers, levando a ataques de negao de servio e
ataques de vrus, espionagem, extorso industrial e vazamento de
informaes organizacionais ou dados particulares.

Porque a nova tecnologia oferece o potencial para negcios dramaticamente


melhorada atuao, Melhores informaes e demonstraram segurana podem
agregar valor real para o organizao contribuindo para a interao com
parceiros comerciais, mais perto cliente relaes, vantagem competitiva e
melhor reputao protegida. Ele tambm pode permitir novas formas e mais fcil
de processar electrnico transaos e confiana generate. Na competitiva
economia global de hoje, se uma organizao quer fazer negcios, pode muito
bem ser solicitado a apresentar detalhes de sua postura de segurana e os
resultados de seu desempenho passado em termos de testes realizados para
garantir a segurana de suas informaes recursos.
Outras reas de grandes riscos associados ISM incluem:

A falta de compromisso do negcio para os processos e ISM


procedimentos
Falta de compromisso do negcio e falta de informao adequada sobre
os planos e estratgias futuras
A falta de compromisso da alta administrao ou a falta de recursos e / ou
oramento para o processo ISM
O processoes concentrar muito nas questes de tecnologia e no o
suficiente sobre o De servios de TIs e as necessidades e prioridades da
empresa
Avaliao de risco e gesto realizada de forma isolada e no em
conjunto com Gerenciamento de Disponibilidade e ITSCM

ITIL V3 - Service Design - Pgina:

275 de 477

ISM polticas, planos, riscos e de informao se tornam desatualizados e


perder o alinhamento com a informao relevante e os planos de
negcios e de negcios segurana.

ITIL V3 - Service Design - Pgina:

276 de 477

4,7 Gesto de Fornecedores


4.7.1 Finalidade objetivo / / objetivo
"A meta da Gesto de Fornecedores processo administrar fornecedors e os
servios que eles fornecem, para oferecer perfeita qualidade de servio de TI ao
negcio, garantindo valor para o dinheiro obtida. '

O processo de Gerenciamento de Fornecedor garante que os fornecedores e os


servios eles fornecem so gerenciados de TI para apoiar metas de servio e as
expectativas de negcios. O objetivo desta seo aumentar a conscincia do
contexto do negcio de trabalhar com parceiros e fornecedores, e como este
trabalho pode ser melhor direcionado para perceber o benefcio do negcio para
a organizao.
essencial que os processos de Gesto de Fornecedores e planejamento esto
envolvidos em todas as fases do ciclo de vida de servio, a partir de estratgia e
projeto, Atravs transio e operao, Para a melhoria. As demandas de
negcios complexos exigem a amplitude completa de habilidades e capacidade
para apoiar proviso de um conjunto abrangente de servios de TI de uma
empresa, portanto, o uso de rede de valors e os fornecedores e os servios que
prestam so parte integrante de qualquer soluo end-to-end. Fornecedores e
gesto de fornecedores e parceiros so essenciais para a proviso de qualidade
de servios de TI.
A finalidade do Gesto de Fornecedores processo a obteno 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 condies.
O principal objetivos do processo de Gesto de Fornecedores so:

Obter valor para o dinheiro do fornecedor e contratos


Certifique-se que subjacente contratos e acordos com fornecedores esto
alinhados s necessidades do negcio, 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 atravs de
sua ciclo de vida
Manter um fornecedor poltica e um apoio Fornecedor e Banco de Dados
Contrato (SCD).

4.7.2 mbito
O Gesto de Fornecedores processo deve incluir a gesto de todos os
fornecedores e contratos necessrios para suportar o proviso de De servios

ITIL V3 - Service Design - Pgina:

277 de 477

de TIs para o negcio. Cada provedor de servios devem ter processos formais
para a gesto de todos os fornecedores e contratos. No entanto, os processos
devem se adaptar para atender a importncia do fornecedor e / ou do contrato e
o potencial de negcios impacto no proviso de servios. Muitos fornecedores
oferecem servios de apoio e produtos que tm um menor de forma
independente relativamente, e bastante indireta, papel na gerao de valor, mas
coletivamente fazer uma contribuio direta e importante para a gerao de
valor e implementao do negcio global estratgia. A maior contribuio que o
fornecedor faz ao valor de negcios, mais esforo o prestador de servios deve
colocar na gesto do fornecedor e do mais que fornecedor devem ser envolvidos
na desenvolvimento e realizao do negcio estratgia. A contribuio menor
valor do fornecedor, o mais provvel que o relao ser gerido principalmente
em um operacional nvel, com interao limitada com o negcio. Pode ser
adequado em alguns organizaos, especialmente as maiores, para gerenciar
equipes internas e fornecedores, onde diferentes unidade de negcioss pode
fornecer apoio de elementos-chave.
O processo de Gerenciamento de Fornecedor deve incluir:

Implementao e execuo da poltica de fornecedor


Manuteno de um Fornecedor e Banco de Dados Contrato (SCD)
Fornecedor e contrato de categorizao e avaliao de risco
Fornecedor e contrato avaliao e seleco
Negociao, desenvolvimento e acordo de contratos
Reviso de contrato, renovao e resciso
Gesto de fornecedores e desempenho do fornecedor
Acordo e implementao de planos de melhoria de servios e fornecedor
Manuteno de contratos-tipo, termos e condies
Gesto de resoluo de litgios contratuais
Gesto de sub-contratados fornecedores.

TI Gesto de Fornecedores muitas vezes tem de cumprir as normas


organizacionais ou corporativo, diretrizs e requisitos, especialmente aqueles de
finanas corporativas, jurdica e de compras, como ilustrado na figura 4.29.

ITIL V3 - Service Design - Pgina:

278 de 477

Figura 4.29 Gesto de Fornecedores - papis e interfaces

A fim de assegurar que os fornecedores fornecem valor para o dinheiro e


cumprir as metas de servio, a relao entre cada fornecedor deve ser
propriedade de um indivduo dentro da provedor de servios organizao. No
entanto, um nico indivduo pode possuir a relao de um ou de muitos
fornecedores, como ilustrado na Figura 4.29. Para garantir que relaos so
desenvolvidos de uma forma consistente e desempenho que os fornecedores
est devidamente revisado e gerenciado, papels precisam ser estabelecidas
para uma Gesto de Fornecedores proprietrio do processo e Gerente de
Contratos. Em menor organizaos, estes separado papels podem ser
combinadas em uma nica responsabilidade.

4.7.3 Valor para o negcio


O principal objetivos da Gesto de Fornecedores processo so proporcionar
valor para o dinheiro de fornecedores e contratos e para garantir que todos os
alvos em contratos com fornecedores e acordos subjacentes esto alinhadas s
necessidades de negcio e metas acordados dentro de SLAs. Isso para
garantir a entrega ao negcio de ponta a ponta, de qualidade, sem costura
servios de TI que esto alinhados s expectativas do negcio. O processo de
Gesto de Fornecedores devem se alinhar com todos os requisitos corporativos
e as exigncias de todos os outros processos de TI SM, particularmente ISM e
GCSTI. Isso garante que o valor de actividade obtm apoio fornecedor servios
e que eles esto alinhados com as necessidades do negcio.

4.7.4 Polticas / princpios / conceitos bsicos


O Gesto de Fornecedores tentativas processo para garantir que os
fornecedores cumpram os termos, condies e metas do seu contratos e

ITIL V3 - Service Design - Pgina:

279 de 477

acordos, enquanto tentava aumentar o valor para o dinheiro obtido de


fornecedores e os servios que prestam. Todo o processo de Gesto de
Fornecedores atividade deve ser conduzido por um fornecedor estratgia e da
poltica de Estratgia de Servio. A fim de se obter consistncia e eficcia na
implementao da poltica, 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 Gesto 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 servio(S) ou produto (s) fornecidos por cada
fornecedor, E todas as outras informaes e as relaes com o CIS associada
outro. Os servios prestados pelos fornecedores tambm constituem uma parte
essencial da Portflio de Servios e a Catlogo de Servios. A relao entre o
servios de apoios e de TI e servio de negcios eles suportam so
fundamentais para fornecer qualidade de servios de TI.
Esta informao dentro do SCD ir fornecer um conjunto completo de
informaes de referncia para todos Gesto de Fornecedores procedimentos e
atividades:

ITIL V3 - Service Design - Pgina:

280 de 477

Fornecedor categorizao e manuteno do banco de dados de


fornecedores e contratos (SCD)
Avaliao e set-up de novos fornecedores e contratos
Estabelecimento de novos fornecedores
Fornecedor e Gesto de Contratos e atuao
Renovao de contrato e resciso.

Os dois primeiros elementos da lista acima so cobertas pela Design de


Servios fase. O terceiro elemento parte de Transio de Servio, E os dois
ltimos so parte da Operao de Servio encenar e so abordados com mais
detalhes nessas publicaes.

4.7.5 as atividades de processo, mtodos e tcnicas


Esta seo fornece mais detalhes sobre a Gesto de Fornecedores processo,
seus sub-processos e atividades, bem como a gesto 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 atravs dos estgios de seu ciclo
de vida, desde a identificao da necessidade de negcio para a operao e da
cessao do contrato:

Identificao das necessidades do negcio e preparao da caso de


negcio:
Produzir uma Declarao de Necessidade (SOR) e / ou concurso
(ITT)
Assegurar a conformidade com estratgia/poltica
Preparar o caso de negcio inicial, incluindo opes (interna e
externa), custars, prazos, metas, benefcios, avaliao de risco.
Avaliao e aquisio de novos contratos e fornecedores:
Identificar o mtodo de compra ou contratao
Estabelecer critrios de avaliao - por exemplo, de servios,
capacidade (Ambos pessoal e organizao), qualidade e custo
Avaliar opes alternativas
Selecionar
Negociar contratos, metas e os termos e condies, incluindo
responsabilidades, fecho, Renovao, prorrogao, disputa de
transferncia,
Concordar e adjudicar o contrato.
Estabelecer novos fornecedores e contratos:
Configure o fornecedor servio e do contrato, dentro do SCD e
quaisquer outros associados sistemas corporativos
Transio de servio
Estabelecer contatos e relacionamentos.
Categorizao de fornecedores e contratos:

ITIL V3 - Service Design - Pgina:

281 de 477

Avaliao ou reavaliao do fornecedor e contrato


Assegurar mudanas progrediram atravs Transio de Servio
Categorizao do fornecedor
Atualizao do SCD
Manuteno contnua da SCD.
Gerenciar o fornecedor e contrato desempenho:
Gesto e controlar da operao e entrega de um servio / produtos
Monitor e relatrio (servio, Qualidade e custos)
Rever e melhorar (qualidade, servio e custars)
Gesto do fornecedor e a relao (Comunicao, riscos,
mudanas, falhas, melhorias, contatos, interfaces)
Reviso, pelo menos anualmente, servio escopo contra a
necessidade de negcios, metas e acordos
Plano para possvel fecho/ Renovao / extenso.
Fim do prazo:
Review (determinar os benefcios entregues, em andamento
exigncia)
Renegociar e renovar ou cancelar e / ou transferncia.

O negcio, TI, finanas, compras e contratos precisam trabalhar juntos para


garantir que todas as fases do contrato ciclo de vida so geridos de forma eficaz.
Todas as reas precisam ser conjuntamente envolvidas na escolha da soluo e
gesto do curso atuao do fornecedor, Com cada rea assumir a
responsabilidade para os interesses de sua prpria rea, embora seja
consciente das implicaes sobre o organizao como um todo. Os processos
envolvidos nas fases do ciclo de vida do contrato so explicados em detalhes
nas sees seguintes.
4.7.5.1 Avaliao de novos fornecedores e contratos

As atividades associadas com a identificao de necessidades de negcio e das


subsequentes avaliao de novos fornecedores e contratos fazem parte do
Design de Servios processo. As sadas desta rea fornecem entradas para
todas as outras fases do ciclo de vida do contrato. vital para o sucesso
contnuo do contrato e da relao que o negcio est intimamente envolvido em
todos os aspectos dessas atividades. Toda organizao deve ter modelos e um
mtodo formal para a produo de caso de negcios e sua aprovao e sign-off.
O detalhamento das necessidades do negcio e os contedos do plano de
negcios deve ser acordado, aprovado e assinado por ambas as empresas e de
TI.
Ao selecionar um novo fornecedor ou contrato, uma srie de fatores precisam
ser levados em considerao, incluindo histrico, capacidade, Referncias rating
de crdito, e tamanho em relao ao negcio que est sendo colocado. Alm
disso, dependendo do tipo de fornecedor relao, pode haver questes pessoais

ITIL V3 - Service Design - Pgina:

282 de 477

que necessitam de ser consideradas. Cada organizao deve ter processoes e


procedimentos para o estabelecimento de novos fornecedores e contratos.
Embora se reconhea que os fatores que podem existir influncia a deciso
sobre o tipo de relacionamento ou escolha do fornecedor (por exemplo, a poltica
dentro da organizao, relacionamentos existentes), essencial que, nesses
casos, o raciocnio identificado e avaliado o impacto total para garantir caro
erros sejam evitados.
Os servios podem ser provenientes de um nico fornecedor ou mltiplos
fornecedores. Os servios so mais provvel de ser obtida a partir de dois ou
mais fornecedores concorrentes onde a exigncia para os servios de padro
ou de produtos que esto disponveis 'off-the-shelf ". Multi-fonte mais provvel
de ser usado onde o custo a determinante principal, e os requisitos para o
desenvolvimento de variantes do servios so baixos, mas pode tambm ser
realizada para distribuir o risco. Fornecedores em uma lista de mltiplas fontes
pode ser designado com o estatuto de "Fornecedor preferencial" dentro da
organizao, Limitar ou eliminar escopo para o uso de outros fornecedores.
Parceria relaos so estabelecidos a nvel executivo e so dependentes de
uma vontade de troca estratgico informaes para alinhar estratgias de
negcios. Muitos relacionamentos com fornecedores estrategicamente
importantes esto agora posicionados como parceria relacionamentos. Isso
reflete um movimento longe de relaes hierrquicas, nas quais tradicionalmente
o fornecedor atos subordinadamente cliente organizao, que caracterizado
por:

Alinhamento estratgico: Bom alinhamento cultura, Valores e objetivos,


que conduz a um alinhamento das estratgias comerciais
Integrao: A integrao final dos processos de ambos os organismos
O fluxo de informao: Boa comunicao e troca de informaes em
todos os nveis, especialmente no estratgico nvel, levando a fechar
entendimento
A confiana mtua: Uma relao baseada na confiana mtua entre as
organizaes e seus indivduos
Abertura: Ao informar sobre o desempenho do servio, custarAnlise de
Risco e
Responsabilidade coletiva: Articulao parceria equipas que
responsabilidade coletiva para a corrente atuao e desenvolvimento
futuro da relao
Compartilhado risco e recompensa: Por exemplo concordando custos
como investimento e resultantes eficincia benefcios so compartilhados,
ou como os riscos e recompensas de flutuaes nos custos de materiais
so compartilhadas.

ITIL V3 - Service Design - Pgina:

283 de 477

Ambas as partes obtm benefcios da parceria. Uma organizao deriva valor


progressivamente mais de um fornecedor relacionamento como a compreenso
do fornecedor da organizao como um todo aumenta, a partir de seu inventrio
de TI arquiteturas at sua cultura corporativa, valores e objetivo de negcios.
Com o tempo, o fornecedor capaz de responder mais rapidamente e de forma
mais adequada s necessidades da organizao. Os benefcios de fornecedor
de um compromisso de longo prazo da organizao, dando-lhe maior
estabilidade financeira, e que lhe permite financiar investimentos de longo prazo,
que beneficiam a sua clientes.
A parceria torna possvel 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 solues compatveis a partir de segurana,
Rede, dados / intercmbio de informaes, para o fluxo de trabalho e sistemas
de processamento de aplicaes. Esta integrao pode proporcionar melhorias
de servios e custos reduzidos. Tais movimentos tambm reduzir os riscos e
custos associados com one-off ttico solues, posto em prtica para superar
um fornecedor de TI com o da organizao.
A chave para uma relao bem sucedida parceria est sendo absolutamente
clara sobre os benefcios e os custos de tal relacionamento vai entregar antes de
entrar nela. Ambas as partes, ento sabe o que esperado deles desde o incio.
O sucesso da parceria pode envolver um acordo sobre a transferncia de
pessoal para o parceiro ou terceirizao organizao como parte do acordo e de
relacionamento.
Provedor de servios organizaes devem ter documentado e processos formais
para avaliao e seleo de fornecedores com base em:

Importncia e impacto: A importncia do servio para o negcio, fornecida


pela fornecedor
Risco: os riscos associados com o uso do servio
Custos: o custo do servio e sua prviso.

reas muitas vezes outros da organizao de prestao de servios, tais como


Finanas, Jurdico e Compras, vai se envolver com este aspecto do processo.
Organizaes prestadoras de servios devem ter processos, abrangendo:

Produo de caso de negcio documentos


Produo de Sor e convites para apresentao de propostas ou
documentos proposta
Formal avaliao e seleo de fornecedores e contratos
A incluso de clusulas, termos e condies em contratos, inclusive
resciso antecipada, aferio, Sada ou transferncia de contratos,
resoluo de conflitos, gesto de resciso sub-contratados fornecedores
e normal

ITIL V3 - Service Design - Pgina:

284 de 477

Transio 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 extenso de um acordo depende do tipo e um relacionamento
avaliao dos riscos envolvidos. Uma anlise de risco pr-acordo uma etapa
vital em estabelecer qualquer acordo com o fornecedor externo. Para cada festa,
ele expe os riscos que precisam ser abordados e precisa ser to abrangente
quanto possvel, cobrindo uma grande variedade de riscos, incluindo reputao
do negcio financeiro, operacional, Regulamentares e legais.
Um acordo global minimiza o risco de litgios resultantes de uma diferena de
expectativas. Um acordo flexvel, que atende de forma adequada para sua
adaptao em todo o perodo de vigncia do acordo, de fcil manuteno e
suporta a mudana com uma quantidade mnima de renegociao.
O contedo de uma base subjacente contrato ou contrato de servio so as
seguintes:

Condies bsicas: O termo (durao) do contrato, as partes, os locais,


escopo, Definies e base comercial.
Descrio do servio e extenso: a funcionalidade do servioest sendo
prestado e sua extenso, juntamente com restries no fornecimento de
servios, tais como desempenho, disponibilidade,capacidade, Interface
tcnico e segurana. Funcionalidade do servio pode ser explicitamente
definido, ou, no caso de servios bem estabelecidos, includo por
referncia a outros documentos estabelecidos, tal como o Portflio de
Servios e a Catlogo de Servios.
Padres de servio: As medidas de servio e os nveis mnimos que
constituem aceitvel atuao 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 servio aceitvel considerada como tendo
ocorrido quando esta condio for satisfeita desempenho em 95% dos
casos. Nvel de servios devem ser realistas, mensurveis e alinhados
organizaoAs prioridades de negcio e apoiar as metas acordadas
dentro de SLRs e SLAs.
Workload gamas: As faixas de volume dentro do qual se aplicam normas
de servio, ou para que determinado preos regimes aplicveis.
Gesto da informao (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 ttulo de
relatrios em que o relao sero avaliados. Key Performance Indicators
(KPIs) e Balanced Scorecards (BSC) podem formar o ncleo de dados de
desempenho relatados.

ITIL V3 - Service Design - Pgina:

285 de 477

Responsabilidades e dependncias: Descrio das obrigaes da


organizao (no apoio ao fornecedor nos esforos de prestao de
servios) e do fornecedor (na sua prviso do servio), incluindo a
comunicao, contatos e escalada.

Um contrato de servio extensivo tambm pode conter:

Dbito servio e regime de crdito (incentivos e sanes)


Adicional atuao critrios.

A seguir d uma pequena amostra dos temas jurdicos e comerciais


normalmente cobertos por um servio ou acordo contratual:

Escopo de servios a serem prestados


Requisitos de desempenho de servios
Diviso de responsabilidades e de acordo
Pontos de contacto, comunicao e relatrios de freqncia e contedo
Reviso de contrato e os processos de resoluo de litgios
Estrutura de preos
As condies de pagamento
Compromissos com mudar e investimento
Processo de mudana acordo
Confidencialidade e os anncios
Propriedade intelectual direitos e os direitos autorais
Limitaes de responsabilidade
Direitos de resciso de cada partido
Obrigaes de resciso e alm.

A forma final de um acordo, e parte da terminologia, pode ser ditada pelas


opinies e preferncias do concurso e departamentos jurdicos, ou por empresas
especializadas legais.
Procurar aconselhamento jurdico ao formalizar contratos de fornecimento
externo.
Contratos formais
Formal contratos so adequados para regime de abastecimento externas que
fazem uma contribuio significativa para a entrega e desenvolvimento da
negcio. Contratos prevem compromissos vinculativos legais entre cliente e
fornecedor, E cobrir as obrigaes de cada organizao tem para o outro a partir
do primeiro dia do contrato, frequentemente se estende para alm do seu termo.
Um contrato usado como a base para acordos com fornecedores externos,
onde um compromisso obrigatrio exigido. De alto valor e / ou estratgico
relacionamentos so sustentados por um contrato formal. A natureza
formalidade e ligao de um contrato no esto em desacordo com o cultura de

ITIL V3 - Service Design - Pgina:

286 de 477

um acordo de parceria, mas sim formar a base sobre a qual a confiana no


relacionamento pode ser fundada.
Um contrato susceptvel de ser estruturada com um corpo principal contendo
as clusulas comerciais e legais, e com os elementos de um contrato de servio,
conforme descrito anteriormente, que figura como horrios. Os contratos podem
tambm incluir um certo nmero de outros documentos relacionados como
agendas, por exemplo:

Segurana requisitos
Continuidade de requisitos de negcios
Mandatado tcnico padros
Planos de migrao (acordado agendada mudar)
Acordos de confidencialidade.

Maioria das grandes organizaes tm contratos e departamentos jurdicos


especializados em contratos de sourcing. Empresas especializadas legais
podem ser utilizados para financiar a aquisio interna e jurdica funo ao
estabelecer importantes contratos formais.
Acordos subjacentes
Em ITIL um SLA definido como um acordo escrito entre um provedor de
servios e o cliente (s) que os documentos acordados nvel de servios para um
'servio. Os prestadores de servios devem estar cientes de que os SLAs so
amplamente utilizados para formalizar baseadas em servios, relacionamentos,
tanto interna como externamente, e que, embora em conformidade com a
definio acima, estes acordos variam consideravelmente no detalhe coberto.
Os pontos de vista de algumas organizaes, como o Instituto Chartered de
Compra e Abastecimento (CIPS) e vrios advogados especializados, so que os
SLAs no deve ser usado para gerenciar as relaes externas, a menos que
eles fazem parte de um contrato subjacente. O Guia Completo para preparao
e execuo de Contratos de Nvel de Servio (2001) enfatiza que um SLA
autnomo pode no ser legalmente aplicvel, mas sim "representa a boa
vontade ea f das partes signatrias". Por isso, do interesse de prestadores de
servios e fornecedores, para garantir que os SLAs sejam incorporados em um
quadro adequado contratual que se encontra com o ITIL objetivo que os SLAs
so acordos vinculativos.
SLAs, acordos subjacentes e os contratos devem ser revistos em uma base
regular para garantir atuao est de acordo com a nvel de servios que foram
acordados.
A organizao susceptvel de ser dependente do seu prprio interno grupo de
apoios, em certa medida. Para ser capaz de atingir as metas de SLA,

ITIL V3 - Service Design - Pgina:

287 de 477

aconselhvel ter acordos formais no lugar com estes grupos. Acordo de Nvel
Operacionals (ANO) assegurar que os servios que sustentam suportar o
negcio / TI metas de SLA. OLAs foco no operacional os requisitos que a
servios precisam conhecer. Este um no-contratual, orientada a servios
documento descrevendo servios e atendimento padros, com
responsabilidades e obrigaes quando apropriado.
Tal como aconteceu com SLA, importante que OLAs so monitorados para
destacar os potenciais problemas. O Gerente de Nvel de Servio tem a
responsabilidade geral para avaliar o desempenho em relao s metas para
que as medidas podem ser tomadas para remediar, e prevenir a recorrncia de
futuro, quaisquer violaes OLA. Dependendo do tamanho da organizao e da
variedade de servios, por exemplo, SLAs e OLAS, um Gerente de Nvel de
Servio deve assumir a responsabilidade por seu servio ou conjunto de
servios.
4.7.5.2 categorizao Fornecedor e manuteno do banco de dados de
fornecedores e contratos (SCD)

O Gesto de Fornecedores processo deve ser adaptvel e gastar mais tempo e


esforo chave gesto fornecedors que menos importante fornecedors. Isto
significa que algum tipo de processo de categorizao deve existir dentro do
processo de Gesto de Fornecedores para categorizar o fornecedor e sua
importncia para a provedor de servios e os servios prestados negcio.
Fornecedores podem ser categorizados de muitas maneiras, mas um dos
melhores mtodos para categorizar os fornecedores baseado na avaliao da
risco e impacto associados com o uso do fornecedor, devendo o valor ea
importncia do fornecedor e os seus servios para a empresa, como ilustrado na
figura 4.31.

ITIL V3 - Service Design - Pgina:

288 de 477

Figura 4,31 categorizao Fornecedor

A quantidade de tempo e esforo gasto no gerenciamento do fornecedor e a


relao, em seguida, pode ser adequado para a sua classificao:

Estratgico: Para significativas 'parceria' relaes que envolvem


dirigentes compartilham informaes confidenciais estratgica para
facilitar planos de longo prazo. Estas relaes, normalmente, seria de
propriedade e em nvel gerencial snior dentro da provedor de servios
organizao, E envolveria um contacto regular e frequente e atuao
opinies. Estas relaes provavelmente exigiria o envolvimento de
Estratgia de Servio e Design de Servios recursos, e que incluem o
melhoramento especfico contnuo programas (por exemplo, um provedor
de servio de rede, fornecimento de servios de redes de todo o mundo e
seu apoio).
Ttico: Para as relaes que envolvem comercial significativo atividade e
de negcios interao. Estas relaes, normalmente, ser gerido pela
administrao central e que envolveria um contacto regular e avaliaes
de desempenho, muitas vezes incluindo programas de melhoria contnua
(por exemplo, uma empresa de manuteno de hardware fornecendo
resoluo de servidor ferragens falhas).

ITIL V3 - Service Design - Pgina:

289 de 477

Operacional: Para os fornecedores de produtos ou servios


operacionais. Estas relaes, normalmente, seria gerido por gesto
operacional jnior e envolveria pouco contato, mas regulares e avaliaes
de desempenho (por exemplo, de hospedagem provedor de servios,
Fornecendo espao de hospedagem para uma baixa utilizao, o site de
baixo impacto ou internamente usado De servios de TI).
Mercadoria: Para os fornecedores que oferecem baixo valor e / ou
produtos facilmente disponveis e servios, o que poderia ser
alternativamente obtida com relativa facilidade (por exemplo, papel ou
fornecedores de cartuchos de impressora).

Relacionamento com fornecedores estrategicamente importantes so dadas a


maior ateno. nestes casos que os gestores Fornecedor tem que garantir que
a cultura da organizao de prestao de servios estendida para o domnio
fornecedor, de modo que a relao funciona alm do inicial contrato. O aumento
da popularidade do externa de abastecimento, E o aumento do escopo ea
complexidade de alguns arranjos de terceirizao, resultou em uma
diversificao dos tipos de relacionamento com fornecedores. Numa estratgico
nvel, importante compreender as opes disponveis, de modo que o tipo
mais adequado de fornecedor relao pode ser estabelecida para ganhar o
mximo benefcio e evolui de acordo com as necessidades do negcio.
Para conseguir selecionar o tipo mais adequado de relacionamento com o
fornecedor, preciso que haja uma compreenso clara do objetivo de negcios
que esto a ser alcanados.
Um certo nmero de factores, da natureza do servio para o global custar,
Determinar a importncia de um fornecedor de um perspectiva de negcios.
Como mostrado mais tarde, a maior importncia do negcio de um
relacionamento com o fornecedor, mais o negcio precisa ser envolvido na
gesto e no desenvolvimento de uma relao. Uma abordagem de
categorizao formal pode ajudar a estabelecer essa importncia.
O valor do negcio, medido como a contribuio para o negcio cadeia de valor,
Proporciona uma mais negcios alinhados avaliao que o preo de contrato
puro. Alm disso, o padro mais os servios que esto sendo adquiridos, menor
a dependncia do que a organizao tem em relao ao fornecedor, e mais
prontamente o fornecedor pode ser substituda (se necessrio). Servios
padronizados apoiar o negcio atravs do tempo mnimo para o mercado ao
implantar novos ou alterados servio de negcios, e na busca de estratgias de
reduo de custos. Mais informaes sobre este assunto podem ser
encontradas no Estratgia de Servio publicao.
O mais personalizada esses servios so, maior a dificuldade em se mudar para
uma alternativa fornecedor. Personalizao pode beneficiar o negcio,

ITIL V3 - Service Design - Pgina:

290 de 477

contribuindo para a vantagem competitiva por meio de atendimento diferenciado,


ou pode ser o resultado de operacional evoluo.
Servios personalizados aumentar a dependncia do fornecedor, aumentam o
risco e pode resultar em custos aumentados. A partir de um fornecedor
perspectiva, servios sob medida pode diminuir a sua capacidade de alcanar
economias de escala atravs de operaes comuns, resultando em margens
estreitas, e capital reduzido disponvel para futuros investimentos.
Produtos padronizados e servios so a abordagem preferida, a menos que uma
vantagem de negcio claro existe, caso em que um fornecedor estratgico
oferece o servio personalizado.
Relacionamentos de alto valor ou dependncia de alta envolvem riscos maiores
para a organizao. Estes relacionamentos precisam contratos abrangentes e
ativos relao gesto.
Tendo estabelecido o tipo de fornecedor, A relao, ento, precisa ser
formalizado. Na discusso a seguir, "acordo", o termo utilizado genericamente
para se referir a qualquer formalizao de um relacionamento entre cliente e
fornecedor de organizaes, e podem ir desde o informal para abrangentes
contratos juridicamente vinculativos. Simples e de baixo valor relacionamentos
podem ser cobertos por termos padro de um fornecedor e as condies, e ser
gerido totalmente pela TI. Uma relao de estratgico importncia para o
negcio, por outro lado, exige um contrato abrangente, que assegura que o
fornecedor suporta a evoluo das necessidades comerciais ao longo da vida do
contrato. O contrato precisa ser gerenciado e desenvolvido em conjunto com a
aquisio e os departamentos jurdicos e de negcios das partes interessadass.
O acordo a base para o relacionamento. O mais adequado e completo o
acordo, o mais provvel que a relao vai entregar o benefcio do negcio para
ambas as partes.
A qualidade da relao entre o provedor de servios e seus fornecedor(S)
muitas vezes dependente dos indivduos envolvidos de ambos os lados.
Portanto, vital que os indivduos com os atributos, habilidades, competncias e
personalidades so selecionadas para serem envolvidos nessas relaes.
Aservio de negcio pode depender de um certo nmero de fornecedores
internos e / ou externos para a sua entrega. Estes podem incluir uma mistura de
fornecedores estratgicos e fornecedores de commodities. Alguns fornecedores
de fornecer diretamente organizao, outros so fornecedores indiretos ou
sub-contratada de trabalho atravs de outro fornecedor. Fornecedores diretos
so geridas directamente pelo prestador de servio; fornecedores indiretos ou
sub-contratada so gerenciados pelo fornecedor lder. Nenhum fornecedor pode

ITIL V3 - Service Design - Pgina:

291 de 477

oferecer produtos ou servios utilizados para apoiar uma srie de servios de


negcios diferentes.
Cadeia de suprimentos A anlise mostra o mapeamento entre os servios de
negcios e fornecedor servios. Anlise de processo de negcioes ir revelar os
fornecedores envolvidos em cada processo e os pontos de hand-off entre eles.
Gesto do cadeia de suprimentos assegura que os limites funcionais e atuao
requisitos so claramente estabelecidas para cada fornecedor para garantir que
o negcio global nvel de servios sejam alcanados. Servios de negcios so
mais propensos a cumprir as suas metas de forma consistente, onde h um
pequeno nmero de fornecedores na cadeia de abastecimento, e onde as
interfaces entre os fornecedores na cadeia so limitadas, simples e bem
definido.
Reduzir o nmero de fornecedores diretos reduz o nmero de relacionamentos
que precisam ser gerenciados, o nmero de questes de peer-to-peer
fornecedor que precisam ser resolvidos, e reduz a complexidade das atividades
gesto de fornecedores. Algumas organizaes podem conseguir reduzir ou
fechar toda a cadeia em torno de um nico provedor de servios, Muitas vezes
referido como um 'prime' fornecedor. Gesto de instalaes muitas vezes
terceirizada para um parceiro nico especialista ou fornecedor, que, por sua vez
servios de subcontratao de restaurante, manuteno de mquinas de venda
automtica e limpeza.
Terceirizao servios de negcios inteiros a fornecedor prime 'um nico pode
correr riscos adicionais. Por estas razes, organizaos precisa considerar com
cuidado o seu cadeia de suprimentos estratgias frente da terceirizao
grande atividade. O escopo de servios terceirizados deve ser considerada para
reduzir o nmero de fornecedores, garantindo ao mesmo tempo que risco
gerido e ele se encaixa com competncias tpicas do mercado de fornecimento.
O SCD um banco de dados contendo detalhes de fornecedores da
organizao, juntamente com detalhes dos produtos e servios que eles
fornecem para a negcio (Por exemplo, servio de correio electrnico,
fornecimento e instalao de PC Service Desk), juntamente com os detalhes do
contratos. O SCD contm fornecedor detalhes, um resumo de cada produto /
servio (incluindo mecanismos de apoio), informaes sobre o processo de
pedido e, se for caso disso, detalhes de contrato. Idealmente, o SCD deve ser
contido dentro do CMS global.
SCDs so benficas porque podem ser usados para promover os fornecedores
preferidos e para evitar compras de artigos no aprovados ou incompatvel. Ao
coordenar e controlar a compra atividade, A organizao mais provvel que
seja capaz de negociar tarifas preferenciais.
4.7.5.3 Estabelecimento de novos fornecedores e contratos

ITIL V3 - Service Design - Pgina:

292 de 477

Adicionando novos fornecedores ou contratos para o SCD precisa ser tratada


atravs da Gesto da Mudana processo, para assegurar que qualquer impacto
avaliado e compreendido. Na maioria das organizaes, o SCD de
propriedade do Gesto de Fornecedores processo ou o departamento de
compras ou de compras. O SCD proporciona um nico conjunto de foco central
de informaes para a gesto de todos os fornecedores e contratos.
Gesto de risco, Trabalhando com fornecedores, centros de avaliao de
vulnerabilidades em cada fornecedor arranjo ou contrato que representam
ameaas para qualquer aspecto do negcio, incluindo o impacto nos negcios,
probabilidade, a satisfao do cliente, imagem de marca, participao de
mercado, rentabilidade, preo da ao ou impactos regulatrios ou multas (em
algumas indstrias).
A natureza da relao afeta o grau de risco para o negcio. Riscos associados
com um fornecedor terceirizado ou estratgica tendem a ser em maior nmero, e
mais complexo de gerir, do que com o abastecimento interno. Raramente
possvel "terceirizar" risco, embora, por vezes, alguns dos riscos podem ser
transferidos para a terceirizao organizao. Culpar um fornecedor no
impressiona clientes ou interna usurios afetada por uma segurana incidente
ou um sistema de longa falha. Novos riscos decorrentes da relao precisam ser
identificados e administrados, com a comunicao e escalada , conforme
apropriado.
Um substancial avaliao de risco deveria ter sido realizado pr-contrato, mas
isso precisa ser mantido em funo da evoluo das necessidades do negcio,
alteraes no contrato escopoOu mudanas no operacional ambiente.
O provedor de servios organizao e o fornecedor deve considerar o ameaas
colocados pela relao para a sua prpria ativoss, e tm o seu prprio perfil de
risco. Cada um deve identificar seus donos de risco. Em uma relao que
funcione bem, possvel que grande parte ou todo o avaliao a ser
abertamente compartilhado com a outra parte. Ao envolver especialistas
fornecedores em avaliaes de risco, especialmente nas avaliaes de risco
operacional (ORAs), a organizao pode obter insights valiosos sobre a melhor
forma de mitigar os riscos, bem como melhorar a cobertura da avaliao.
Ao avaliar os riscos de ruptura de servio de negcios ou funes, a empresa
pode ter diferentes prioridades para o servio /funo restaurao. Anlise de
Impacto no Negcio (BIA) um mtodo utilizado para avaliar os impactos em
diferentes reas da empresa, resultante de uma perda de servio. Atividades de
avaliao de risco e BIA relativos a fornecedores e contratos devem ser
realizados em estreita colaborao com Gesto da Continuidade do
Servio,Gerenciamento de Disponibilidade e Gesto de Segurana da
Informao, Com o objectivo de reduzir o impacto e probabilidade de falha de
servio como resultado da falha do servio ou fornecedor do fornecedor.

ITIL V3 - Service Design - Pgina:

293 de 477

Uma vez que essas atividades foram concludas e as informaes do fornecedor


e do contrato tenha sido introduzido no DF, incluindo os indivduos nomeados
responsveis pela gesto do novo fornecedor e / ou contratos, a frequncia de
servio /fornecedor reunies de avaliao e reunies de reviso contratual
precisa ser estabelecido, com pontos de quebra apropriados, automatizado
limiars e avisos no local. A introduo de novos fornecedores e contratos devem
ser tratadas como grande mudars atravs transio e em operao. Isto ir
assegurar que os contactos apropriados e pontos de comunicao so
estabelecidas.
4.7.5.4 Gerenciamento de Fornecedor e Contrato e desempenho

Ao nvel operacional, processos integrados precisam estar no local entre uma


organizao e seus fornecedores para assegurar o funcionamento do dia-a-dia
eficiente prticas. Por exemplo:

o fornecedor dever estar de acordo com a gesto da organizao de


Mudana processo ou quaisquer outros processos?
Como que o Service Desk notificar o fornecedor de incidentes?
Como as informaes so atualizadas quando CMS mudana CIs como
resultado das aes de fornecedor? Quem o responsvel?

Pode haver um conflito de interesses entre o provedor de servios organizao e


os seus fornecedores, especialmente no que diz respeito Gesto da
Mudana,Gerenciamento de Incidentes,Gerenciamento de Problemas e
Gerenciamento da Configurao processos. O fornecedor pode querer usar seus
processos e sistemas, enquanto que o provedor de servios organizao vai
querer usar seus prprios processos e sistemas. Se este for o caso,
responsabilidades claras e interfaces tero de ser definidos e acordados.
Estas e muitas outras reas precisam ser abordadas para assegurar o
funcionamento regular e eficaz a nvel operacional. Para fazer isso, todos os
pontos de contacto e os contactos tm de ser identificados e procedimento
posto no lugar para que todos compreendam o seu papels e responsabilidades.
Isso deve incluir a identificao do indivduo, nico nomeado responsvel para a
posse de cada fornecedor e contrato. No entanto, uma organizao deve tomar
cuidado para no impor automaticamente seus prprios 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 organizao do departamento de TI tinha desenvolvido processoes para
apoiar o viver servio, uma vez que foi instalado. Estes procedimentos includos
para gravar e documentar o trabalho feito no servio por engenheiros de campo
(por exemplo, mudanas, reparars, valorizao e reconfiguraes). Em uma
reunio do progresso do projeto, o fornecedor confirmou que tinha olhado para
os procedimentos e poderia segui-los, se necessrio. No entanto, tendo sido

ITIL V3 - Service Design - Pgina:

294 de 477

nesta situao 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 fcil de seguir do que os
desenvolvidos e propostos pelo organizao.
Alm da interface de processo, essencial identificar como questes so
tratadas numa operacional nvel. Rotas de escalonamento por terem claramente
definidos e comunicados, questes so susceptveis de ser identificados e
resolvidos anteriormente, minimizando o impacto. Tanto a organizao eo
benefcio fornecedor da captao precoce e resoluo de problemas.
Ambos os lados devem se esforar para estabelecer relaes de boa
comunicao. O fornecedor aprende mais sobre o negcio da organizao, seus
requisitos e os seus planos, ajudando o fornecedor para entender e atender as
necessidades da organizao. Por sua vez, os benefcios da organizao de um
fornecedor mais sensvel que est ciente dos drivers de negcio e quaisquer
questes, e , portanto, mais capaz de fornecer solues adequadas. Fechar
dia-a-dia as ligaes podem ajudar cada partido para estar ciente do do outro
cultura e formas de trabalhar, o que resulta em menor nmero de enganos e que
conduz a uma relao mais bem sucedidas e de longa durao.
Dois nveis de educao formal rever precisam ocorrer ao longo do contrato ciclo
de vida para minimizar risco e assegurar o negcio percebe benefcio mximo
do contrato:

Servio /comentrios de desempenho do fornecedor: relatrios sobre o


desempenho deve ser produzido em uma base regular, com base no
categoria de fornecedor, e deve formar a base de reunies de avaliao
de servios. O mais importante fornecedor, o mais frequente e extensa de
relatrios e revises devem ser
Comentrios Servio de escopo de servio e contrato: Estes tambm
devem ser realizados em uma base regular, pelo menos anualmente para
todos os principais fornecedores. O objetivo destes deve ser a reviso do
servio, Em geral o desempenho do servio, escopo e metas e do
contrato, juntamente com quaisquer acordos associados. Isto deve ser
comparado com as necessidades de negcios originais e os negcios
atual precisa garantir que fornecedor e contratos permanecem alinhados
s necessidades do negcio e continuar a oferecer valor para o dinheiro.

Reunies de avaliao formais de desempenho deve ser realizada em uma base


regular para analisar o desempenho do fornecedor contra nvel de servios, a
um nvel operacional detalhada. Estes encontros proporcionam uma
oportunidade para verificar se o servio em andamento gesto de desempenho
continua focada em atender as necessidades de negcio. Temas tpicos
incluem:

ITIL V3 - Service Design - Pgina:

295 de 477

Desempenho do servio contra alvos


Incidente e problema revises, incluindo quaisquer questes escalada
Feedback das empresas e dos clientes
Esperada grande mudars que vai (ou pode) afetam o servio durante o
perodo de servio seguinte, bem como as alteraes e mudanas
fracassadas que causaram incidentes
Principais eventos de negcios durante o perodo prximo servio que
precisam de ateno especial do fornecedor (Por exemplo, o
processamento final do trimestre)
Melhores prticas e Planos de Melhoria de Servio (PIS).

Iniciativas de melhoria de servios importantes e aes so controladas atravs


de PIS com cada fornecedor, incluindo quaisquer aes para lidar com qualquer
falhas ou fraquezas. Progresso do PIS existentes, ou a necessidade de uma
nova iniciativa, revisado em reunies de avaliao de servios. Organizaes
pr-ativas ou com viso de futuro, no s usar PIS para lidar com falhas, mas
tambm para melhorar um servio consistentemente alcanado. importante
que um contrato fornece incentivos adequados para ambas as partes para
investir na melhoria do servio. Estes aspectos so abordados com mais
detalhes na publicao Melhoria de Servio Continuada.
O governo mecanismos de fornecedores e contratos so retirados das
necessidades de adequada das partes interessadass em diferentes nveis dentro
de cada organizao, e so estruturados de modo que os representantes da
organizao face-off com os seus homlogos no de fornecedor organizao.
Definir as responsabilidades de cada representante, atendendo fruns e
processos de assegurar que cada pessoa est envolvida no momento certo em
influenciar ou dirigir as atividades certas.
A escala ea importncia da servio e / ou fornecedor influenciar os mecanismos
de governana necessrios. O mais significativo a dependncia, O maior
empenho e esforo envolvidos na gesto da relao. O esforo necessrio no
provedor de servios lado para governar um terceirizao contrato no deve ser
subestimado, especialmente em indstrias de perto regulamentados, como
setores de finanas e farmacuticos.
Um objetivo chave para Gesto de Fornecedores o de assegurar que o valor
de um fornecedor para a organizao completamente realizado. Valor
percebido atravs de todos os aspectos da relao, a partir operacional atuao
garantia, capacidade de resposta para mudar pedidos e as flutuaes da
demanda, por meio de contribuio de conhecimento e de experincia para a
organizao do capacidade. O fornecedor de servios tambm devem assegurar
que as prioridades do fornecedor corresponder prioridades do negcio. O
fornecedor deve compreender que a sua nvel de servios so mais
significativos para o negcio.

ITIL V3 - Service Design - Pgina:

296 de 477

Uma empresa multi-nacional de grande tinha acordos de software no lugar com


o mesmo fornecedor em nada menos que 24 pases. 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 so
consistentes e coordenadas, cada relacionamento fornecedor deve ter um nico
indivduo nomeado responsvel por todos os aspectos do relacionamento.
A organizao nacional de varejo teve um indivduo possuir geral a gesto do
seu principal fornecedor de servios de rede. No entanto, servios, contratos e
faturamento foram geridos por vrios indivduos espalhados por toda a
organizao. O proprietrio individual apresentar uma caso de negcio para a
posse nica do fornecedor e todos os diversos contratos, em conjunto com a
consolidao de todas as facturas individuais em uma nica fatura trimestral. A
economia de custos estimados para a organizao estavam em excesso de
600.000 por ano.
Pesquisas de satisfao tambm desempenham um importante papel em revelar
o quo bem fornecedor nvel de servios esto alinhados s necessidades do
negcio. Uma pesquisa pode revelar casos em que h insatisfao com o
servio, mas o fornecedor , aparentemente, um bom desempenho contra seus
alvos (e vice-versa). Isto pode acontecer quando os nveis de servio so
inadequadamente definidos e deve resultar numa rever dos contratos, acordos e
metas. Alguns provedores de servios publicar tabelas da liga fornecedores com
base em seus resultados de pesquisa, estimular a concorrncia entre os
fornecedores.
Para aqueles significativa fornecedor relaes em que o negcio 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 benefcios que eles esperam para realizar. Isso forma uma parte
importante do plano de negcios para assumirem a relao.
Estes benefcios devem ser ligados e complementares, e deve ser medido e
gerenciado. Onde a empresa est buscando melhorias no atendimento ao
cliente, relaes fornecedor de TI contribuindo para os clientes servios deve ser
capaz de demonstrar um melhor servio em seu prprio domnio, e quanto isso
tem contribudo para melhor atendimento ao cliente.
Para benefcios avaliaos para permanecer vlida durante a vida do contrato,
Alteraes nas circunstncias que ocorreram desde o caso benefcios original foi
preparada deve ser tida em conta. Um fornecedor pode ter sido selecionado em
sua capacidade de fornecer uma poupana anual de 5% custo operacional em
comparao com outras opes, mas depois de dois anos entregou nenhuma
poupana. No entanto, quando isso devido a alteraes no contrato, ou custos

ITIL V3 - Service Design - Pgina:

297 de 477

da indstria em geral que afectaram tambm as outras opes, provvel que


uma poupana de custos em relao ainda est sendo realizado. Um caso
mantida benefcios mostra que a poupana.
Avaliaes de benefcios muitas vezes recebem prioridade menor do que o
custo de poupana de iniciativas, e so dadas menos prioridade em relatrios de
desempenho do que as questes e problema resumos, mas importante para a
relao de longo prazo que realizaes so reconhecidas. Um relatrio
benefcios deve fazer avaliaes objetivas contra os objectivos iniciais, mas
pode tambm incluir moralizadora evidncia anedtica de realizaes e de valor
agregado.
importante para os dois organismos, e para a longevidade da relao, que os
benefcios de ser derivado da relao so regularmente analisados e relatados.
Um avaliao do sucesso de uma relao de fornecedor, a partir de um
perspectiva de negcios, provvel que seja substancialmente baseado
financeira atuao. Mesmo quando um servio um bom desempenho, pode
no 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 fora pode
levar a falta de investimento por parte do fornecedor, resultando em uma
degradao gradual do servio, ou at mesmo ameaar a viabilidade do
fornecedor. Em ambos os casos isso pode resultar em impactos adversos de
negcios para a organizao.
A chave para o sucesso a longo prazo Gesto Financeira do contrato de um
esforo conjunto dirigido no sentido de manter o equilbrio financeiro, em vez de
uma relao de confronto entrega de benefcios de curto prazo para um s
partido.
Construir relacionamentos leva tempo e esforo. Como resultado, o organizao
s pode ser capaz de construir relacionamentos de longo prazo com poucos
fornecedores-chave. A experincia, cultura e compromisso dos envolvidos na
execuo de um fornecedor relacionamento so pelo menos to importante
quanto ter um bom contrato e governo regime. As pessoas certas com as
atitudes certas no relao equipe pode fazer um contrato de trabalho pobre, mas
um bom contrato no garante que uma equipe de m relao proporciona.
Uma quantidade considervel de tempo e dinheiro normalmente investido em
negociar acordos principal fornecedor, com mais de novo em risco para ambas
as partes, se a relao no for bem sucedida. Ambas as organizaes devem
garantir que eles investem adequadamente nos recursos humanos afectos
gesto do relacionamento. A personalidade, comportamento e cultura dos
representantes de relacionamento todos influenciar o relacionamento. Para que

ITIL V3 - Service Design - Pgina:

298 de 477

uma relao de parceria, todos os envolvidos precisam ser capazes de respeitar


e trabalhar de perto e de forma produtiva com os seus homlogos.
4.7.5.5 renovao do Contrato e / ou resciso

Crticas de contrato deve ser feita em uma base regular para garantir o contrato
de continuar a atender s necessidades de negcio. Crticas de contrato
avaliar a operao de contrato de forma holstica e em um nvel mais alto do que
os comentrios de servios que so realizados em um operacional nvel. Esses
exames devem considerar:

Como bem o contrato de trabalho e sua relevncia para o futuro


Se mudars so necessrios: servios, produtos, contratos, acordos,
metas
Qual a viso de futuro para o relacionamento - o crescimento,
encolhimento, alterao, resciso, transferncia, etc?
Desempenho comercial do contrato, revises contra referncias ou de
mercado avaliaos, adequao do preos estrutura e carregamento
arranjos
Orientao sobre direo contrato futuro e assegurar melhores prticas
gesto processoes so estabelecidos
Fornecedor e governana contrato.

Para regime de abastecimento de alto valor, longos e complexos, o perodo de


negociao do contrato e acordo pode ser demorado, caro e pode envolver um
perodo prolongado de negociao. Pode ser uma tendncia natural para
desejar evitar alteraes adicionais a um contrato para o maior tempo possvel.
No entanto, para o negcio para obter o valor integral do relacionamento com o
fornecedor, o contrato deve ser capaz de ser regular e rapidamente alterada
para permitir a negcio a beneficiar da evoluo do servio.
Aferio fornece uma avaliao em relao ao mercado. O fornecedor pode ser
cometida por contrato a manter as acusaes contra uma taxa de mercado. Para
manter a mesma margem, o fornecedor obrigada a melhorar o seu
funcionamento eficincia em linha com os seus concorrentes. Coletivamente,
esses mtodos de ajudar a fornecer uma avaliao de uma melhoria da
eficincia ou deteriorao.
O ponto de responsabilidade dentro da organizao para decidir alterar uma
relao fornecedor provvel que dependem do tipo de relacionamento. O
provedor de servios pode ter identificado uma necessidade de mudar de
fornecedor, com base no existente fornecedor atuao, Mas por uma relao
contratual a deciso precisa ser tomada em conjunto com os contratos da
organizao e departamentos jurdicos.
A organizao deve tomar medidas cuidadosas para:

ITIL V3 - Service Design - Pgina:

299 de 477

Realizar um impacto profundo e Anlise de Risco de uma mudana de


fornecedor sobre a organizao e seus negcios, especialmente durante
um perodo de transio. Isto pode ser particularmente importante no
caso de um estratgico relao.
Faa um comercial avaliao da sada custars. Isso pode incluir os custos
de resciso contratual, se fornecedor responsabilidade no clara, mas
os maiores custos so susceptveis de ser associado com um transio
projeto. Para qualquer relao significativa de tamanho, este geralmente
inclui um perodo de alimentao dupla como servios so migrados.
Qualquer alterao associada a uma mudana de fornecedor ir
aumentar os custos, seja imediatamente como custos fixos, ou ao longo
do tempo, onde suportados pelo fornecedor e refletida de volta em taxas
de servio.
Aconselhamento jurdico em termos de resciso, o perodo de aviso
prvio aplicvel e mecanismos, e quaisquer outras conseqncias,
especialmente se o contrato ser antecipada.
Reavaliar o mercado para identificar potenciais benefcios em mudar de
fornecedor.

A prudente organizao compromete a maioria destes passos, no momento do


contrato original estabelecido para assegurar que as disposies adequadas e
clusulas esto includos, mas este comentrio atividade deve ser reavaliado
quando a mudana de fornecedor est sendo considerado.

4.7.6 Triggers, entradas, sadas e interfaces


Existem muitos eventos que podem desencadear Gesto de Fornecedores
atividade. Estes incluem:

Novos ou alterados corporativa governo diretrizs


Novo negcio ou alterado e estratgias, polticas ou planos
Necessidades de negcios novos ou alterados ou novas ou alteradas
servios
Requisitos novos ou alterados dentro de acordos, como SLRs, SLAs,
Olas ou contratos
Reviso e reviso de projetos e estratgias
Atividades peridicas, tais como a reviso, reviso ou comunicao,
incluindo reviso e reviso de polticas de gesto de fornecedores,
relatrios e planos
Pedidos de outras reas, particularmente SLM e Gesto de Segurana,
Para a assistncia com fornecedor questes
Requisitos para os contratos novos, renovao de contrato ou resciso de
contrato
Re-categorizao de fornecedores e / ou contratos.

ITIL V3 - Service Design - Pgina:

300 de 477

As principais interfaces que Gesto de Fornecedores se com outros processos


so os seguintes:

ITSCM: com relao gesto de fornecedores de servios de


continuidade.
SLM: ajuda com a determinao de metas, exigncias e
responsabilidades ea sua incluso nos acordos subjacentes e contratos
para garantir que eles suportam todos SLR e metas de SLA. Alm disso,
a investigao de violaes de SLA e SLR causada por desempenho do
fornecedor pobres.
ISM: na gesto de fornecedores e seu acesso a servios e sistemas, e
suas responsabilidades com respeito conformidade com as polticas e
os requisitos do ISM.
Gesto Financeira: Fornecer fundos suficientes para financiar Gesto de
Fornecedores requisitos e contratos e de aconselhamento e orientao
sobre a compra e matria de contratos.
Gesto de Portflio de Servios: Para garantir que todos servios de
apoios e os seus pormenores e relaos so precisamente refletido
dentro do Portflio de Servios.

4.7.6.1 Entradas

Informaes de negcios: De negcio da organizao estratgia, Os


planos e os planos financeiros e informaes sobre suas necessidades
atuais e futuras
Fornecedor e estratgia de contratos: Abrange a terceirizao poltica
do provedor de servios e os tipos de fornecedores e contratos utilizados.
produzido pela Estratgia de Servio processos
Fornecedor planos e estratgias: Detalhes dos planos de negcios e
estratgias de fornecedores, Juntamente com detalhes de seus
desenvolvimentos tecnolgicos e planos e declaraes e informaes
sobre a sua actual situao financeira ea viabilidade da empresa
projetada
Contratos com fornecedores, acordos e metas: De ambos os contratos
existentes e novos acordos de fornecedores
Fornecedor e informaes sobre o desempenho do contrato: De
ambos os contratos existentes e novos e fornecedores
Informaes de TI: A partir da IT estratgia planos e atuais oramentos
Problemas de desempenho: O incidente e Gerenciamento de
Problemas processos, com incidentes e problemas relativa ao contrato de
pobre ou o desempenho do fornecedor
Informaes financeiras: De Gesto Financeira, a custar fornecedor de
servio (s) e pro servioviso, O custo de contratos e os benefcios de
negcios resultante e os planos financeiros e oramentos, bem como os
custos associados ao servio e falha fornecedor
Informaes sobre o servio: A partir do processo de SLM, com
detalhes dos servios da Portflio de Servios e a Catlogo de

ITIL V3 - Service Design - Pgina:

301 de 477

Servios,meta de nvel de servios dentro de SLAs e SLRs, e,


possivelmente, a partir da monitoramento de SLAs, servio de opinies e
violaes dos SLAs. Tambm cliente Dados de satisfao no servio
qualidade
CMS: Contendo informaes sobre as relaes entre o negcio, Os
servios, o servios de apoios e a tecnologia.

4.7.6.2 Sadas

As sadas dos Gesto de Fornecedores so utilizados em todas as outras partes


do processo, por muitos outros processos e por outras partes do organismo.
Muitas vezes, essa informao fornecida como relatrios eletrnicos ou
displays em reas comuns ou como pginas de intranet servidors para garantir o
mais up-to-date informaes sempre utilizado. A informao fornecida como
se segue:

O Banco de Dados de Fornecedores e Contratos (SCD): Contm as


informaes necessrias a todos os sub-processos dentro Gesto de
Fornecedores - Por exemplo, os dados monitorados e coletados como
parte da gesto de fornecedores. Este , ento, invariavelmente, usada
como entrada para todas as outras partes do processo de gesto de
fornecedores.
Fornecedor e informaes sobre o desempenho do contrato e
relatrios: Usado como entrada para reunies de avaliao de
fornecedores e contratos para gerenciar a qualidade do servio prestado
pela fornecedors e parceiros. Isto deve incluir informaes sobre
compartilhado risco se for caso disso.
Fornecedor minutos e reunio de reviso do contrato: Produzido para
registrar as atas e de todas as reunies de avaliao com os
fornecedores.
Fornecedor Planos de Melhoria de Servio (PIS): Usado para registrar
todas as aes de melhoria e planos acordados entre provedor de
servioss e seus fornecedores, onde for necessrio, e deve ser usado
para gerenciar o andamento das aes de melhoria acordadas, incluindo
as medidas de reduo de risco.
Levantamento relatrios fornecedor: Muitas vezes, muitas pessoas
dentro de um provedor de servios organizao tem relaes com os
fornecedores. Os comentrios destas pessoas devem ser reunidas para
garantir que a consistncia na qualidade de servio prestado pelos
fornecedores fornecida em todas as reas. Estes podem ser publicados
como tabelas da liga de incentivar a concorrncia entre os fornecedores.

4.7.7 Indicadores Chave de Desempenho


Muitos KPIs e mtricos pode ser usada para avaliar a eficcia e eficincia do
Gesto de Fornecedores processos e atividades. Essas mtricas precisam ser

ITIL V3 - Service Design - Pgina:

302 de 477

desenvolvidas a partir do servio ao cliente, e perspectivas de negcios, tais


como:

Empresas protegido de fornecedor pobres atuao ou perturbao:


O aumento do nmero de fornecedores que satisfaam os alvos
dentro da contrato
Reduo do nmero de violaes de metas contratuais.
Servios de apoios e os seus objectivos alinhados com as necessidades
do negcio e metas:
Aumento do nmero de servios e revises contratuais mantidas
com fornecedores
Aumento do nmero de fornecedores e contratuais metas
alinhadas com SLA e metas SLR.
Disponibilidade de servios no comprometida pela fornecedor
desempenho:
Reduo do nmero de violaes de servios causada por
fornecedores
Reduo do nmero de violaes de servios ameaados
causados por fornecedores.
Propriedade clara e sensibilizao para as questes de fornecedores e
contratos:
Aumento do nmero de fornecedores com os gestores nomeados
fornecedor
Aumento no nmero de contratos com gestores de contrato
nomeados.

4.7.8 Gesto da Informao


Todas as informaes exigidas pela Gesto de Fornecedores deve ser contido
dentro da SCD. Isto deve incluir todas as informaes relativas aos fornecedores
e contratos, bem como todas as informaes relativas operao dos servios
de apoio prestados pelos fornecedores. As informaes relativas a estes
servios de apoios tambm deve estar contido no interior da Portflio de
Servios, Em conjunto com as relaes com todos os outros servios e
componentes. Esta informao deve ser integrado e mantido em alinhamento
com todos os outros sistemas de TI de gesto da informao, em especial o
Portflio de Servios e do. CMS

4.7.9 Desafios, Fatores Crticos de Sucesso e riscos


Gesto de Fornecedores enfrenta muitos desafios, que podem incluir alguns dos
seguintes:

Continuamente mudando de negcios e de TI precisa e gesto da


mudana significativa em paralelo com a entrega de servio existente

ITIL V3 - Service Design - Pgina:

303 de 477

Trabalhar com um contrato de no-ideal imposta, um contrato que tem


metas pobres ou termos e condies, ou definio pobre ou inexistente
de servio ou fornecedor metas de desempenho
Questes de legado, especialmente com servios terceirizados
recentemente
Percia insuficiente retida dentro da organizao
Sendo amarrado em contratos de longo prazo, sem possibilidade de
melhoria, que tm penalidades punitivas para sada precoce
Situaes em que o fornecedor depende da organizao no cumprimento
da prestao de servios (por exemplo, para uma alimentao de dados)
pode levar a problemas mais responsabilidade para pobre atuao
Disputas sobre acusaes
Interferncia por qualquer uma das partes na disputa da outra operao
Ser pego em um modo de combate a incndios por dia, perdendo a
abordagem proactiva
Comunicao - no interagir bastante com freqncia suficiente ou rpido
ou concentrando-se nas questes certas
Conflitos de personalidade
Uma parte usando o contrato em detrimento da outra parte, resultando
em ganha-perde mudanas, em vez de conjuntos ganha-ganha
mudanas
Perder a estratgico perspectiva, focando operacional questes,
causando uma falta de foco em relao estratgica objetivos e questes.

Os elementos-chave que podem ajudar a evitar as questes acima so:

Claramente contrato escrito, bem definido e bem gerida


Mutuamente benfica relao
Claramente definida (e comunicado) papels e responsabilidades de
ambos os lados
Interfaces de bons e comunicaes entre as partes
Bem definido Servio de Gesto de processos de ambos os lados
Seleo de fornecedores que obtiveram certificado contra certificaes
internacionalmente reconhecidas, tais como ISO 9001, ISO / IEC 20000,
etc

Os CSFs principais para o Gesto de Fornecedores processo so os seguintes:

Empresas protegido de pobres fornecedor desempenho ou interrupo


Servios de apoios e os seus objectivos alinhados com as necessidades
do negcio e metas
Disponibilidade de servios no comprometida pelo desempenho
fornecedor
Propriedade clara e conscincia do fornecedor e questes contratuais.

As principais reas de risco associado Gesto de Fornecedores incluem:

ITIL V3 - Service Design - Pgina:

304 de 477

Falta de compromisso do negcio e gerncia snior para o Gesto de


Fornecedores processo e procedimentos
Falta de informao adequada sobre futuros negcios e polticas de TI,
planos e estratgias
Falta de recursos e / ou oramento para o processo ISM
Legado de mal escrito e acordado contratos que no esto na base ou
suporte s necessidades de negcio ou de SLA e metas SLR
Fornecedores concordar com metas e nvel de servios em contratos que
so impossveis de cumprir, ou fornecedores falham ou so incapazes de
satisfazer os termos e condies do contrato
Fornecedor pessoal ou organizacional cultura no esto alinhados ao do
provedor de servios ou se a actividade
Os fornecedores no so cooperativos e no esto dispostos a participar
e apoiar a necessria Gesto de Fornecedores processo
Fornecedores so tomados e relacionamentos, pessoal e contratos so
alterados
As exigncias do fornecedor corporativa e procedimentos contratuais so
excessivas e burocrtica
Pobres processos financeiros corporativos, como compras e compra, no
suportam Gesto de Fornecedores bem.

ITIL V3 - Service Design - Pgina:

305 de 477

5 Servios de design de tecnologia actividades


relacionadas com o
Este captulo 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 Servios nas
seguintes reas:

Gesto de infra-estrutura
Gesto Ambiental
Dados e Gesto de Informao
Aplicao de Gesto de.

ITIL V3 - Service Design - Pgina:

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 negcio e usurio'S
requisitos e assegurar a rastreabilidade de mudanas para cada exigncia. Este
processo compreende as fases de elicitao, anlise (que realimenta a
eliciao) e validao. Tudo isso contribui para a produo de um rigoroso
requisitos completos documento. O ncleo deste documento um repositrio de
requisitos individuais que desenvolvido e gerenciado. Muitas vezes, estes
requisitos so instigadas pela TI, mas, finalmente, eles precisam ser
documentadas e concordou com o negcio.
Existem muitos diretrizs em engenharia de requisitos, incluindo a prtica
recomendada para Requisitos de Software Especificaos (IEEE 830), Corpo de
Engenharia de Software do Conhecimento (SWEBOK), CMMI e do V-Model, que
descrito em detalhes no Transio de Servio publicao.

5.1.1 Diferentes tipos de requisitos


Um pressuposto fundamental aqui que a anlise da corrente e da necessria
processo de negcioresultados es em requisitos funcionais conheceu atravs De
servios de TIs (compreendendo aplicaos, dados, infra-estrutura, ambiente e
habilidades de suporte).
importante notar que no so comumente dito ser de trs tipos principais de
requisitos para qualquer sistema - requisitos funcionais, de gesto e operacional
requisitos, e usabilidade requisitos.

Os requisitos funcionais so aqueles especificamente necessria para


suportar um negcio particular funo.
De gesto e operacional requisitos (por vezes referido como requisitos
no-funcionais) abordar a necessidade de um servio gil, seguro e
disponvel, e lidar com questes como a facilidade de desenvolvimento,
Operacionalidade, as necessidades de gesto e segurana.
Usabilidade requisitos so os que abordam o "look and feel"
necessidades do usurio e resultam em caractersticas do servio que
facilitam a sua facilidade de uso. Esse tipo de requisito muitas vezes
visto como parte de gesto e as necessidades operacionais, mas para os
fins desta seo que ser tratado separadamente.

5.1.1.1 Os requisitos funcionais

Os requisitos funcionais descrevem as coisas que um servio se destina a fazer,


e pode ser expressa como tarefas ou funes que o componente necessrio
para executar. Uma abordagem para especificao de requisitos funcionais
atravs de mtodos como um diagrama de contexto do sistema ou um caso de

ITIL V3 - Service Design - Pgina:

307 de 477

uso modelo. Outras abordagens mostram como as entradas esto a ser


transformados em sadas (fluxo de dados ou diagramas de objeto) e as
descries textuais.
Um diagrama de contexto do sistema, por exemplo, captura todas as trocas de
informaes entre, por um lado, o servio de TI e seu meio ambiente e, por
outro, as fontes ou destinos de dados usados pelo servio. Essas trocas de
informao e fontes de dados representam restries sobre o servio em
desenvolvimento.
Um modelo de caso de uso define um conjunto goal-oriented de interaes entre
atores externos e os servios em questo. Atores so pessoas de fora do
servio que interagir com o servio. Um ator pode refletir uma classe de usurio
papels que os usurios podem jogar, ou de outros servios 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 usurios. Os casos de uso tambm so teis para estabelecer a
comunicao entre desenvolvedores de negcios e aplicao. Eles fornecem
uma base para o dimensionamento e a definio de alimentar usabilidade
requisitos. Os casos de uso definir todos os cenrios que um aplicao tem que
apoiar e pode, portanto, ser facilmente expandido em casos de teste. Desde que
os casos de uso descrevem a funcionalidade de um servio em um nvel que
compreensvel tanto para negcios e de TI, eles podem servir como um veculo
para especificar os elementos funcionais de uma SLA, Tal como o negcio real
entregas a partir do servio.
Um nvel "abaixo" do caso de uso e o diagrama de contexto, muitas outras
tcnicas de modelao pode ser aplicado. Esses modelos representam as
caractersticas estticas e dinmicas dos servios em desenvolvimento. Um
modelo conceitual de dados (seja chamado de objeto ou dados) descreve os
diferentes 'objetos' no servio, sua mtua relaos e a sua estrutura interna.
Dinmica do servio pode ser descrita usando modelos de estado (por exemplo,
estado transio diagramas) que mostram os vrios estados das entidades ou
objetos, juntamente com eventos que podem causar estado mudars. Interaes
entre os componentes de aplicao diferentes podem ser descritos atravs de
diagramas de interao (por exemplo, diagramas de interao de objetos). Ao
lado de um processo maduro requisitos de modelagem, ferramentas CASE pode
ajudar na obteno e manuteno desses modelos consistente, correta e
completa.
5.1.1.2 Gesto e requisitos operacionais

De gesto e operacional requisitos (ou requisitos no-funcionais) so usados


para definir os requisitos e as restries ao De servios de TI. Os requisitos de
servir de base para os primeiros sistemas de colagem e de servio e as
estimativas de custar, E pode apoiar o avaliao da viabilidade do servio de TI

ITIL V3 - Service Design - Pgina:

308 de 477

proposto. Gesto e operacional requisitos tambm devem incentivar os


desenvolvedores a dar uma viso mais ampla da projeto metas.
Categorias de requisitos de gesto e operacionais incluem:

Gerenciabilidade: Ser que funciona? Ser que no? Como que falha?
Eficincia: Quantas recursos que consumir?
Disponibilidade e confiana: Como confivel que preciso para ser?
Capacidade e atuao: Qual a capacidade que precisamos?
Segurana: O que classificao de segurana necessria?
Instalao: Quanto esforo necessrio para instalar o aplicao?
usando a instalao automatizada procedimentos?
Continuidade: Qual o nvel de resilincia e recuperao necessria?
Controlabilidade: Pode ser monitorado, gerenciado e ajustado?
Manutenibilidade: Como bem pode a aplicao ser ajustada, corrigido,
mantido e mudado para necessidades futuras?
Operacionalidade: Ser que os aplicativos perturbar outras aplicaes
em suas funcionalidades?
Mensurabilidade e reportabilidade: Podemos medir e informar sobre
todos os aspectos necessrios da aplicao?

Os requisitos de gesto e operacional pode ser usado para prescrever o


qualidade atributos do aplicao sendo construda. Estes atributos de qualidade
pode ser utilizada para a concepo teste planos para testar os aplicativos no
observncia s necessidades de gesto e operacional.
5.1.1.3 Os requisitos de usabilidade

O propsito principal de usabilidade requisitos assegurar que o servio atende


as expectativas do seu usurios no que respeita sua facilidade de uso. Para
alcanar este objectivo:

Estabelecer atuao padres para avaliaes de usabilidade


Definir teste cenrios para usabilidade planos de testes e testes de
usabilidade.

Como a administrao e os requisitos operacionais, requisitos de usabilidade


tambm podem ser usados como os atributos de qualidade dos planos de teste
para testar o projeto aplicaos sobre a sua conformidade com os requisitos de
usabilidade.

5.1.2 Requisitos para apoio - a viso de usurio


Os usurios tm formalmente definida papels e atividades como usurio
representantes na definio de requisitos e testes de aceitao. Eles devem

ITIL V3 - Service Design - Pgina:

309 de 477

participar activamente na identificao de todos os aspectos do servio,


incluindo as trs categorias acima, e tambm em:

Usurio procedimentos de treinamento e instalaes


Atividades de apoio e Service Desk procedimentos.

5.1.3 Requisitos tcnicas de investigao


H uma srie de tcnicas que podem ser utilizadas para investigar situaes de
negcios e elicitar os requisitos de servio. Por vezes, o clientes e a negcio no
esto completamente certos do que realmente so suas necessidades e vai
precisar de alguma ajuda e inspirao do designer ou coletor requisitos. Este
deve ser preenchido de forma sensvel para garantir que ele no visto como TI
ditar os requisitos de negcios novamente. As duas tcnicas mais utilizadas so
entrevistas e workshops, mas estes so geralmente complementados por outras
tcnicas, como a observao e cenrios.
5.1.3.1 Entrevistas

A entrevista uma ferramenta fundamental e pode ser vital para a realizao de


vrias objetivos, tais como:

Fazer o contato inicial com a chave das partes interessadass e


estabelece uma base para o progresso
Construo e desenvolvimento de relacionamento com diferentes
usurios e gerentes
Aquisio de informaes sobre a situao da empresa, incluindo
questes e problemas.

H trs reas que so consideradas durante as entrevistas:

Atual processo de negcioes que precisam ser cumpridas em todos os


sistemas de novos negcios e servios
Problemas com as operaes atuais que precisam ser abordadas
Novos recursos exigido do novo sistema de negcio ou servio e qualquer
apoio De servios de TI.

A entrevista processo melhorada quando o entrevistador tem preparado


minuciosamente como isso economiza tempo, evitando explicaes
desnecessrias e demonstra interesse e profissionalismo. A estrutura clssica
de questionamento "Por que, O que, Quem, Quando, Onde, Como" oferece uma
excelente estrutura para preparao para entrevistas.
igualmente importante para encerrar formalmente a entrevista:

Resumindo os pontos cobertos e das aces acordadas

ITIL V3 - Service Design - Pgina:

310 de 477

Explicando o que acontece a seguir, tanto aps a entrevista e alm


Pedir ao entrevistado como qualquer contato deve ser feito.

sempre uma boa idia para escrever as notas da entrevista o mais rpido
possvel - de preferncia, de imediato e, geralmente, no dia seguinte.
As vantagens da entrevista so:

Constri uma relao com os usurios


Pode fornecer informaes importantes
Oportunidade para entender pontos de vista e atitudes diferentes em todo
o usurio grupo
Oportunidade para investigar novas reas que surgem
Conjunto de exemplos de documentos e relatrios
Valorizao de fatores polticos
Estudo do ambiente em que o novo servio operar.

As desvantagens da entrevista so:

Caro em tempo decorrido


Nenhuma oportunidade para resoluo de conflitos.

5.1.3.2 Workshops

Workshops proporcionar um frum em que as questes possam ser discutidas,


os conflitos resolvidos e requisitos provocou. Workshops so especialmente
importantes quando o tempo e oramentos so fortemente constrangido,
diversos pontos de vista precisam ser negociou e iterativo e incremental de vista
de servio desenvolvimento est sendo tomada.
As vantagens do workshop so:

Obter uma viso ampla da rea sob investigao - com um grupo de das
partes interessadass em uma sala vai permitir uma compreenso mais
completa dos problemas e problemas
Aumente a velocidade e produtividade - muito mais rpido para ter uma
reunio com um grupo de pessoas do que entrevistando-os um por um
Obter buy-in e aceitao para o servio de TI
Obter uma viso de consenso - se todos os das partes interessadass
esto envolvidos, a chance deles tomar posse dos resultados
melhorada.

Existem algumas desvantagens, incluindo:

Pode ser demorada para organizar - por exemplo, nem sempre fcil de
obter todas as pessoas necessrias em conjunto ao mesmo tempo,

ITIL V3 - Service Design - Pgina:

311 de 477

Pode ser difcil de obter todos os participantes com o nvel exigido de


autoridade
Pode ser difcil conseguir uma combinao de negcios e operacional as
pessoas a compreender as diferentes necessidades.

O sucesso ou falha de uma sesso do workshop depende, em grande parte, no


trabalho preparatrio pelo facilitador e promotor de negcios para a oficina. Eles
devem passar o tempo antes do evento planejando as seguintes reas:

O objetivo da oficina - este tem de ser um objetivo que pode ser


alcanado dentro das limitaes 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 tcnicas a serem utilizadas. Estes precisam ser
orientados no sentido de atingir o objectivo definido, por exemplo,
levantamento de requisitos ou priorizao, e deve tomar as necessidades
dos participantes em conta.
Arranjar um local adequado - o que pode estar dentro da organizao,
Mas melhor usar um local "neutro" para fora do escritrio.

Durante o workshop, um facilitador precisa garantir que as questes so


discutidas, as vises so arejadas e progresso feito no sentido de alcanar o
objetivo estabelecido. A registro precisa ser mantida dos pontos-chave que
emergem da discusso. No final da oficina, o facilitador precisa resumir os
pontos principais e aes. Cada aco deve ser atribudo a um proprietrio.
Existem duas categorias principais de tcnica necessrios para um workshop de
requisitos - tcnicas de descoberta e tcnicas de documentao, como mostrado
na figura 5.1.

ITIL V3 - Service Design - Pgina:

312 de 477

Figura 5.1 tcnicas Requisitos oficina


5.1.3.3 Observao

Observando o local de trabalho muito til para obter informaes sobre o


negcio ambiente e o trabalho prticas. Isto tem duas vantagens:

Uma melhor compreenso dos problemas e dificuldades enfrentados pela


empresa usurios
Ele vai ajudar a conceber solues viveis que so mais susceptveis de
ser aceitvel para o negcio.

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.
Observao formal envolve assistindo uma tarefa especfica a ser realizada.
Existe o perigo de ser mostrado apenas o 'front-histria ", sem qualquer do
cotidiano variaos, mas ainda uma ferramenta til.
5.1.3.4 Anlise de Protocolo

Anlise protocolo simplesmente recebendo os usurios a executar uma tarefa,


e para eles para descrever cada passo como realiz-la.
5.1.3.5 Shadowing

Sombreamento envolve seguindo um usurio durante um perodo tal como um


dia para saber sobre um determinado trabalho. uma forma poderosa de
entender uma funo de usurio em particular. Pedindo explicaes de como o
ITIL V3 - Service Design - Pgina:

313 de 477

trabalho feito, ou o fluxo de trabalho, esclarece alguns dos aspectos j


assumidos.
5.1.3.6 Anlise de Cenrio

Anlise de Cenrio essencialmente contando a histria de uma tarefa ou


transao. Seu valor que ele ajuda a usurio que incerto o que necessrio
de um novo servio para perceber isso mais claramente. Cenrios tambm so
teis quando se analisa ou redesenhar processo de negcioes. Um cenrio vai
traar o curso de uma transao a partir de um gatilho de negcios inicial por
cada um dos passos necessrios para alcanar um bem-sucedido resultado.
Cenrios fornecem um quadro para descobrir caminhos alternativos que podem
ser seguidos para completar o transao. Isto extremamente til na elicitao
de requisitos e anlise, porque situaes da vida real, incluindo as
circunstncias excepcionais, so debatidas.
Cenrios oferecem vantagens significativas:

Eles foram o usurio para incluir todas as etapas, para que no haja
tomadas como certas elementos eo problema do conhecimento tcito
dirigida
Ao ajudar o usurio visualizar todas as contingncias, eles ajudam a lidar
com a incerteza sobre os futuros sistemas e servios
Um grupo de oficina de refino de um cenrio vai identificar os caminhos
que no se adaptam a empresa cultura
Eles fornecem uma ferramenta para preparar teste scripts.

As desvantagens de cenrios que eles podem consumir muito tempo para se


desenvolver, e alguns cenrios podem se tornar muito complexo. Quando for
este o caso, mais fcil de analisar se cada um dos caminhos principais
alternativas considerada como um quadro distinto.
Uma abordagem popular para descries de cenrios documentam
desenvolver descries de casos de uso para apoiar caso de uso diagramas. No
entanto, h tambm um nmero de mtodos grficos de documentar a situao,
tal como storyboards, diagramas de atividade, tarefa modelos e diagramas de
rvore de deciso.
5.1.3.7 prototipagem

Prototipagem uma tcnica importante para suscitar, anlise, demonstrao e


validao de requisitos. difcil para os usurios a prever o novo servio antes
que seja realmente construdo. Prottipos oferecer uma maneira de mostrar a
usurio como o novo servio pode funcionar e os modos pelos quais ele pode
ser usado. Se um usurio est claro o que eles precisam do servio para fazer

ITIL V3 - Service Design - Pgina:

314 de 477

para eles, utilizando um prottipo muitas vezes libera blocos para pensar e
podem produzir uma nova onda de exigncias. Abordagens incrementais e
iterativos para o servio desenvolvimento, Tais como o Mtodo Dynamic
Systems Development (DSDM), utilize prototipagem evolutiva como uma parte
integrante do seu desenvolvimento ciclo de vida.
H uma srie de abordagens para a construo de prottipos. Eles podem ser
construdas utilizando uma aplicao ambiente de desenvolvimento de modo
que eles espelham a servio, As imagens das telas e navegaes podem ser
construdas usando software de apresentao, ou podem simplesmente ser
'mock-ups' no papel.
Existem dois mtodos bsicos de prototipagem:

O descartvel mock-up, que s usado para demonstrar a aparncia


A implementao incremental, em que o prottipo desenvolvido para o
sistema final.

importante seleccionar conscientemente o que para ser usada, caso


contrrio, existe o perigo de que a m qualidade maquete torna-se a base para o
sistema real, causando problemas mais tarde.
H uma forte ligao entre cenrios e prottipos porque os cenrios podem ser
usados como base para o desenvolvimento de prottipos. Alm de confirmar os
requisitos dos usurios, prototipagem muitas vezes podem ajudar os usurios a
identificar novas necessidades.
Prottipos so usados com sucesso para:

Esclarecer qualquer incerteza por parte dos desenvolvedores de servios


e confirmar a usurio que o que eles pediram foi entendido
Abra o usurio se s novas exigncias, como eles entendem o que o
servio ser capaz de fazer para apoi-los
Mostrar aos usurios o "look and feel" do servio proposto e suscitar
usabilidade requisitos
Validar os requisitos e identificar eventuais erros.

Problemas potenciais incluem:

Iterao infinita
Uma viso que, se o prottipo funciona, o servio completo pode estar
pronto amanh.

5.1.3.8 Outras tcnicas

Outras tcnicas que podem ser utilizadas, incluem:

ITIL V3 - Service Design - Pgina:

315 de 477

Questionrios: Pode ser til para obter uma quantidade limitada de


informaes de um grande nmero de pessoas ao entrevistar todos eles
no seria prtico ou econmico.
Especiais registros de propsito: Tcnica envolve os usurios a manter
um registro sobre um assunto especfico ou tarefa. Por exemplo, eles
poderiam manter um registro simples porto cinco-bar sobre a frequncia
com que eles precisam para transferir chamadas telefnicas - que poderia
fornecer informaes sobre os problemas com este processo de negcio.
Amostragem atividade: uma forma muito mais quantitativa de
observao e pode ser usado quando necessrio 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 usurios como o bit de um simples desenvolvimento de
novos servios, so, na verdade, o aspecto mais problemtico, e ainda o tempo
alocado muito menor do que para as outras fases.
Prazos apertados e oramentos apertados - tanto o resultado de restries
sobre o negcio - Presses lugar no desenvolvimento equipe para entregar um
servio. O problema que, sem o devido tempo para entender e definir os
requisitos corretamente, o servio que entregue na hora pode no ser o
servio que a empresa achou que estava pedindo.
Estudos realizados em projeto de TI falhas contar uma histria comum. Muitos
dos projetos e insatisfatria De servios de TIs sugerem as seguintes
concluses:

Uma grande proporo de erros (mais de 80%) so introduzidos na fase


de requisitos
Muito poucos defeitos (menos de 10%) so introduzidos em projeto e
desenvolvimento - os desenvolvedores esto desenvolvendo as coisas
direito, mas muitas vezes no 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 atribudo aos requisitos.

Estes resultados so particularmente importantes porque o custo de correo de


erros nos requisitos aumenta dramaticamente o mais tarde no ciclo de
desenvolvimento que eles so encontrados.
Um dos principais problemas com a engenharia de requisitos a falta de
habilidade detalhada e compreenso global da rea quando as pessoas usam

ITIL V3 - Service Design - Pgina:

316 de 477

isso. Se realizada com preciso, o trabalho pode integrar os requisitos de vrias


reas em algumas perguntas.
Outros problemas tpicos com os requisitos foram identificados como:

Falta de relevncia para o objetivos do servio


A falta de clareza na redao
Ambiguidade
Duplicao entre os requisitos
Os conflitos entre os requisitos
Requisitos expressos de forma que difcil de avaliar se ou no foram
alcanados
Requisitos que assumem uma soluo, em vez de declarar o que para
ser entregue pelo servio
Incerteza entre os usurios sobre o que eles precisam do novo servio
Omitindo usurios para identificar as necessidades
Nveis inconsistentes de detalhe
Um pressuposto que o pessoal do usurio e de TI tm conhecimento de
que eles no possuem e, portanto, no garantir que h um entendimento
comum
Requisitos fluncia - a adio gradual de requisitos aparentemente
pequenas, sem ter o esforo extra em conta no projeto plano.

Outro problema a aparente incapacidade por parte dos usurios de articular


claramente o que que gostaria que o servio fazer por eles. Muitas vezes, eles
so impedidos de faz-lo porque a natureza do requisito explicado em uma
declarao simples.
5.1.4.1 Resoluo de problemas de engenharia requisitos

Definindo os atores
H alguns participantes que devem ter parte nos requisitos processo. Eles
representam trs grandes das partes interessadas grupos:

O negcio
A comunidade de usurios
A equipe de desenvolvimento do servio.

O usurio comunidade deve ser representado pelo especialista do domnio (ou


objecto de especialista) e usurios finais.
Lidar com o conhecimento tcito
Ao desenvolver um novo servio, os usurios vo passar para ns o seu
conhecimento explcito conhecimento, ou seja, de procedimentos e os dados

ITIL V3 - Service Design - Pgina:

317 de 477

que est na frente da cabea e que eles podem facilmente articular. Um grande
problema quando provocando requisitos o do conhecimento tcito, ou seja, os
outros aspectos do trabalho que um usurio incapaz de articular ou explicar.
Alguns elementos comuns que causam problemas e mal-entendidos so:

Competncias - explicando como realizar aes com palavras por si s


extremamente difcil.
Tomadas como certas informaes - os usurios de negcios, mesmo
experientes e perito pode deixar de mencionar informaes ou esclarecer
a terminologia, eo analista pode no perceber que o questionamento
necessria.
Front-story/back-story - esta questo diz respeito a uma tendncia para
enquadrar uma descrio do trabalho atual prticas, ou um local de
trabalho, a fim de dar uma viso mais positiva do que realmente o caso.
Conhecimento dos sistemas de futuro - se o estudo para um
desenvolvimento de novos servios, com nenhuma experincia ou
conhecimento existente na organizao, Como pode a prospectiva
usurios sabem o que querem?
A dificuldade de uma pessoa de fora assumindo uma linguagem comum
para o discurso e as normas comuns de comunicao. (Se no tem isso,
ento o escopo por falsidade da situao pode crescer
consideravelmente.)
Compreenso intuitiva, geralmente nascem de uma experincia
considervel. Os tomadores de deciso so muitas vezes pensado para
seguir um caminho lgico, linear de inqurito ao fazer suas decises. Na
realidade, porm, como melhorou tomada de deciso habilidades e
conhecimentos so adquiridos, o caminho linear muitas vezes
abandonado em favor do reconhecimento de padres intuitiva.
Organizacional cultura - Sem uma compreenso da cultura de uma
organizao, o exerccio requisitos pode ser falho.

Comunidades de prtica so grupos distintos de trabalhadores - talvez


relacionadas por tarefa, por departamento, por localizao geogrfica ou algum
outro fator - que tm seus prprios conjuntos de normas e prticas, diferentes de
outros grupos dentro da organizao e da organizao como um todo.
Tcito

Explcito

Individual

Habilidades, valores,
tomado como certo
intuio,

Tarefas descrio do trabalhos,


metas, volumes e frequncias

Corporativo

Normas, para trs-histria,


cultura, Comunidades de
prtica

Procedimentos, guias de estilo,


processos, compartilhamento de
conhecimento

ITIL V3 - Service Design - Pgina:

318 de 477

Tabela 5.1 Engenharia de requisitos - tcito e conhecimento explcito

Exemplo nveis de conhecimento tcito e explcito:


Tcnica

O
conhecimento
explcito

O
conhecimento
tcito

Entrevistando

Habilidades

Necessidades
futuras

Sombreamento

Workshops

Prototipagem
Anlise de
cenrio

Anlise de
protocolo

Tabela 5.2 Engenharia de requisitos, exemplos de conhecimento tcito e explcito


(Maiden e Rugg, 1995)

5.1.5 Documentao de requisitos


Os requisitos documento o corao do processo e pode ter um nmero de
formas. Normalmente, o documento vai incluir um catlogo de requisitos, com
cada requisito documentado usando um modelo padro. Um ou mais modelos
mostrando aspectos especficos, tais como o processamento de dados ou
requisitos, poder complementar este catlogo.
Antes que eles so formalmente entrou para o catlogo, as exigncias so
sujeitos ao escrutnio cuidadoso. Este controlo pode envolver organizar os
requisitos em grupos e verificar que cada exigncia "bem formado".
Uma vez que o documento considerado como sendo completa, deve ser
analisado por representantes comerciais e confirmada como sendo uma
indicao verdadeira dos requisitos, neste ponto do tempo. Durante esta fase, os
revisores analisar os requisitos e pergunta se eles esto bem definida, clara e
completa.
Como descobrimos os requisitos de nossos vrios usurios, preciso
document-los. Este o melhor feito em duas fases distintas - a construo da
lista de requisitos e, mais tarde, o desenvolvimento de um catlogo 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 - Pgina:

319 de 477

Requisitos Fonte Comentrios Nvel de detalhe


Tabela 5.3 lista de requisitos

Cada requisito na lista deve ser verificado para ver se ele est ou no bem
formado e A SMART (Especfico, mensurvel, atingvel, realista e oportuno).
Ao verificar o indivduo ea totalidade dos requisitos, a lista a seguir pode ser
usado:

So os requisitos, como capturados, inequvocas?


o significado claro?
O requisito alinhado com o desenvolvimento de servios e negcios
objetivos, ou irrelevante?
a exigncia razovel, 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 soluo ao invs de um estado de
necessidade?
So eles atmica, ou so realmente vrios requisitos agrupados em uma
entrada?
Se sobrepem vrias exigncias ou duplicar o outro?

Existem vrias potenciais resultados do exerccio:

Aceite o exigncia como est


Re palavra-requisito para remover o jargo e ambigidade
Mesclar repetido / sobreposio de requisitos
Tome requisitos obscuros e ambguos de volta para a usurios para
esclarecimentos.

5.1.5.1 O Catlogo de Requisitos

O Catlogo de Requisitos o repositrio central de requisitos dos usurios, e


todos os requisitos devem ser documentados aqui, aps a anlise da lista acima
definidos. O Catlogo de Requisitos deve fazer parte do Pipeline Servio geral
dentro da geral Portflio de Servios. Cada requisito de que foi analisado est
documentado atravs de um modelo padro, tal como a mostrada na Tabela 5.4.
De servios de TI

Autor

ID exigncia

Data

Nome exigncia

Fonte

Proprietrio Prioridade
Descrio Requisito Funcional

ITIL V3 - Service Design - Pgina:

320 de 477

Processo de
negcio

Gesto e Operacional e Requisitos


de Usabilidade

Descrio

Justificao
Documentos relacionados
Requisitos relacionados
Comentrios
Resoluo
Nenhuma verso

Histrico de Alteraes pedido de Mudana


Data

Tabela 5.4 modelo de Requisitos

As entradas de chave no molde so as seguintes:

ID exigncia - Esta uma identificao nica que nunca muda e usado


para rastreabilidade - por exemplo, para fazer referncia ao exigncia em
documentos de projeto, teste especificaos ou implementadas cdigo.
Isso garante que todos os requisitos foram cumpridos e que todas as
funes implementadas so baseados em necessidades.
Fonte - A rea de negcios ou usurios que solicitou a exigncia ou a
documento onde a exigncia foi levantada. A gravao da fonte de um
requisito ajuda a garantir que as perguntas podem ser respondidas ou a
necessidade pode ser re-avaliada no futuro, se necessrio.
Proprietrio - O usurio que aceita a propriedade da exigncia individual
vai concordar que est formulado e documentado corretamente, e vai
assin-lo fora em testes de aceitao quando satisfeito.
Prioridade - O nvel de importncia e necessidade de uma exigncia.
Normalmente, tais como abordagens MoSCoW so utilizados, onde a
seguinte interpretao do mnemnico se aplica:
Deve ter - Um requisito fundamental, sem o qual o servio no 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 servio ainda teriam
valor sem eles.
Poderia ter - Um requisito que no seria benfico para incluir, se
no custa muito ou demorar muito tempo para entregar, mas no
central para o servio.
No ter (Mas quero da prxima vez) - a exigncia de que sero
necessrios no futuro, mas no necessrio para esta entrega.
Em um servio futuro liberar, Esta exigncia pode ser atualizado
para um 'must have'.

ITIL V3 - Service Design - Pgina:

321 de 477

O seguinte deve ser claramente acordados durante esta priorizao atividade:

Prioridades de requisitos podem e devem mudar ao longo da vida de um


desenvolvimento de servios projeto.
"Deve ter" requisitos precisam ser cuidadosamente considerado, pois, se
no forem entregues dentro do estgio inicial do projeto, que pode ser
impossvel de implementar mais tarde.
Os requisitos so, invariavelmente, mais difcil e mais caro para encontrar
mais tarde no Ciclo de Vida de Servio.
No so apenas os requisitos funcionais que podem ser 'must haves' alguns dos requisitos de gesto e operacional deve ser "must haves".
Exigncia Descrio - uma descrio sucinta do requisito. Uma
abordagem til para descrever o requisito usando a seguinte estrutura:
Ator (ou usurio papel)
Expresso verbal
Objeto (frase de substantivo ou substantivo).
Onde a exigncia incorpora regras de negcio complexas ou dados
validao, Mesa de deciso ou rvore de deciso pode ser mais til para
definir regras de negcio complexas, enquanto dados validao regras
pode ser definido de um repositrio. Se uma tcnica complementar
usada para especificar ou modelar o requisito, deve haver uma referncia
cruzada ao documento relacionado.
Processo de negcio - Uma frase simples de agrupar requisitos que
suportam uma especfica atividade, Tais como vendas, estoque,
atendimento ao cliente, e assim por diante.
Justificao - no todos os requisitos que so solicitados sero
cumpridos. Isto pode ser devido a restries de tempo e oramento, ou
pode ser porque o requisito abandonado em favor de um requisito
conflitantes. Muitas vezes, a exigncia no for cumprida, porque
acrescenta pouco valor para a negcio. A justificativa apresenta os
motivos para solicitar a exigncia.
Requisitos relacionados - requisitos podem ser relacionados entre si por
vrias razes. s vezes, h uma ligao entre a funcionalidade exigida
pelos requisitos ou um requisito de alto nvel clarificada por uma srie
de requisitos mais detalhados.
Mudar a histria - As entradas nesta seo fornecem uma registro de todo
o mudars que afetaram a exigncia. Isso necessrio para o
gerenciamento de configurao e fins de rastreabilidade.

5.1.5.2 documentao de requisitos completo

Um requisitos eficazes documento deve compreender os seguintes elementos:

Um glossrio 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 - Pgina:

322 de 477

jargo local e ir esclarecer sinnimos e homnimos para qualquer


pessoa usando o documento
Um escopo modelo, Tal como um diagrama de contexto do sistema
O Catlogo de Requisitos, idealmente mantidos como parte de uma
estratgia global Portflio de Servios
Modelos de apoio, como processo de negcio modelos, diagramas de
fluxo de dados e diagramas de interao.

Gerenciamento das mudanas feitas na documentao


Mudanas podem acontecer porque:

O escopo do novo servio alterou atravs de restries oramentrias


O servio deve cumprir nova regulamentao ou legislao
Mudanas nas prioridades de negcios foram anunciados
Stakeholders ter entendido um requisito melhor depois de uma anlise
detalhada - por exemplo, usando cenrios ou prottipos - e alterado o
original exigncia em conformidade.

H uma srie de ferramentas de apoio especializados no mercado para apoiar


os processos de requisitos. Estas so algumas vezes chamado CARE
(Computer Aided Engenharia de Requisitos) ou CASE (Computer Aided
Software Engineering). As caractersticas incluem:

Manter referncias cruzadas entre os requisitos


Armazenar documentao de requisitos
Gerenciamento das mudanas feitas na documentao de requisitos
Gerenciando versos da documentao de requisitos
Produzir requisitos formatados especificao documentos do banco de
dados
Documentos garantindo sido entregue por um projeto de soluo so
adequados para ativar o suporte.

5.1.6 Requisitos e terceirizao


O objetivo selecionar solues padro embalados sempre que possvel para
atender s necessidades de servio. No entanto, se os requisitos de TI esto a
ser adquiridos de prateleira, desenvolvida in-house ou externa, todas as
actividades acima para a produo de um especificao de requisitos de
negcios so feitas em casa. Desenvolvimento de servios de TI muitos
contratos assumir que possvel saber quais so os requisitos no incio, e que
possvel produzir um especificao que expressa de forma inequvoca os
requisitos. Para todos, mas os mais simples servios este raramente verdade.
Anlise de requisitos um processo iterativo - os requisitos sero alterados
durante o perodo da aplicao e servios esto sendo desenvolvidos. Isto ir

ITIL V3 - Service Design - Pgina:

323 de 477

exigir usurio envolvimento em todo o desenvolvimento processo, como no


DSDM e outros geis 'abordagens.
5.1.6.1 requisitos tpicos cenrios de terceirizao

Abordagens tpicas de contrato para o desenvolvimento de sistemas de TI para


ser entregue em suporte de um De servios de TI so os seguintes:

Requisitos de baixo nvel especificao - a fronteira entre "cliente" e


fornecedor feita entre os requisitos detalhados especificao e
quaisquer atividades de projeto. Todos os requisitos que tm impacto no
usurio foram especificadas em detalhe, dando o prestador de um alvo
aplicao muito clara e precisa. No entanto, h um aumento do esforo
de especificao, eo valor acrescentado do fornecedor restrito aos
aspectos menos difceis de desenvolvimento.
Requisitos de alto nvel especificao - o limite do cliente / fornecedor
est entre os requisitos de alto nvel e todas as outras fases. O provedor
contrato cobre tudo abaixo da linha. O cliente responsvel por testar o
servio prestado contra os requisitos de negcios. Uma vez que mais
fcil para especificar requisitos de alto nvel, h um esforo 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 espao maior de erros, instabilidade de requisitos e
maior dificuldade em saber o que os sistemas de informao que voc
deseja.

ITIL V3 - Service Design - Pgina:

324 de 477

5.2 Dados e Gesto da Informao


De dados um dos tipos de ativos crticos que precisam ser geridas de forma a
desenvolver, entregar e suportar os servios de TI de forma eficaz. Dados /
Gesto da Informao como um organizao planos, coleta, cria, organiza,
usos, controles, divulga e dispe de seus dados / informaes, tanto estruturada
registros e dados no estruturados. Assegura tambm que o valor do que os
dados / informaes so identificadas e exploradas, tanto em apoio das suas
operaes internas e no aumento do valor para o seu cliente-revestimentos
processo de negcioes.
Um nmero de termos so comuns nesta rea, incluindo "Gesto de dados",
"Gesto da Informao" e "Gesto de Recursos de Informao. Para os fins da
presente publicao, "Gesto de Dados", o termo utilizado como abreviatura
para todos os trs acima.
O papel de Gesto de Dados descrito no 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 'informao' ou 'dados em contexto' .
De dados, como base para a informao da organizao, tem todos os atributos
necessrios para ser tratado como um ativos (Ou recurso). Por exemplo,
essencial para a 'obteno de objetivo de negcios e os trabalhos bem
sucedidos dirias de uma 'organizao. Alm disso, ele pode ser "obtida e
conservada por uma organizao, mas apenas com um custo financeiro".
Finalmente, pode, juntamente com outros recursos / bens, ser usado para
"acelerar a consecuo dos objetivos de uma organizao".
Fatores-chave de sucesso para gerenciamento de dados so os seguintes:

Todos os utilizadores tm acesso imediato atravs de uma variedade de


canais para as informaes que eles precisam para fazer seu trabalho.
Ativos de dados so totalmente explorados, atravs de compartilhamento
de dados dentro da organizao e com outros organismos.
A qualidade dos dados da organizao mantido a um nvel aceitvel, e
as informaes utilizadas na negcio preciso, confivel e consistente.
Requisitos legais para manter a privacidade, segurana,confidencialidade
e integridade de dados so observados.
A organizao atinge um nvel elevado de eficincia e eficcia em seus
dados e tratamento da informao atividades.
Um os dados da empresa modelo para definir as entidades mais
importantes e as suas relaes - o que ajuda a evitar redundncias e para
evitar a deteriorao do arquitetura como est mudado ao longo dos
anos.

ITIL V3 - Service Design - Pgina:

325 de 477

5.2.1 Gerenciamento de ativos de dados


Se os dados no so geridos de forma eficaz:

As pessoas a manter e coletar dados que no so necessrios


A organizao pode ter informaes histricas, que no mais usado
A organizao pode conter uma grande quantidade de dados que
inacessvel para os usurios potenciais
A informao pode ser divulgada para mais pessoas do que deveria ser,
ou no a essas pessoas a quem deve ser
A organizao pode usar mtodos ineficientes e fora-de-data para coletar,
analisar, armazenar e recuperar dados
A organizao 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.

Alm disso, se as informaes derivado de dados de boa qualidade uma


pergunta difcil de responder, porque no 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 atualizao procedimentos. Uma vez
que dados incompletos ou imprecisos foram armazenados no sistema de TI,
todos os relatrios produzidos utilizando esses dados refletem essas
imprecises ou lacunas. Tambm pode haver uma falta de coerncia entre
gerado internamente gesto da informao do operacional sistemas, e de outros
internos, sistemas localmente utilizados, criada porque a central de dados no
confivel.
Uma forma de melhorar a qualidade dos dados a utilizao de uma gesto de
dados processo que estabelece poltica e padres, fornece conhecimentos e
torna mais fcil para lidar com os aspectos de dados de novos servios. Este
dever permitir que os dados completos / Gesto de Ativos de Informao para:

Agregar valor ao servios entregues clientes


Reduzir os riscos no negcio
Reduzir os custos dos processos de negcios
Estimular a inovao no interior processo de negcioes.

5.2.2 mbito da Gesto de Dados


Existem quatro reas de gesto includos dentro do escopo de Dados / Gesto
da Informao:

Gesto de recursos de dados: O governo de informaes na


organizao deve assegurar que todos estes recursos so conhecidos e
que as responsabilidades foram atribudas para a sua gesto, incluindo a

ITIL V3 - Service Design - Pgina:

326 de 477

propriedade dos dados e metadados. Este processo normalmente


referido como a administrao de dados e inclui a responsabilidade por:
Definir as necessidades de informao
Construo de um inventrio de dados e um modelo de dados da
empresa
Identificar a duplicao de dados e deficincias
A manuteno de um catlogo / ndice dos dados / informaes de
contedo
Medindo o custar eo valor dos dados da organizao.
Gesto de dados /tecnologia da informao: A gesto da TI, que
sustenta sistemas de informao da organizao, o que inclui processos
tais como o projeto de banco de dados e administrao de banco de
dados. Este aspecto normalmente tratada por especialistas dentro da TI
funo - Veja o Operao de Servio publicao para mais detalhes.
Gesto dos processos de informao:processo de negcioes levar a
De servios de TIs, que inclua um ou outro dos recursos de dados da
organizao. Os processos de criao, coleta, acesso, modificao,
armazenamento, excluso 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 aplicaes.
Gesto de padres de dados e polticas: A organizao ter de definir
normas e polticas para a sua gesto de dados como um elemento de
uma TI estratgia. Polticas ir reger a procedimentos e responsabilidades
para gerenciamento de dados na organizao, e polticas tcnicas,
arquiteturas e as normas que sero aplicadas ao Infra-estrutura de TI que
suporta os sistemas de informao da organizao.

As melhores prticas escopo do processo de gerenciamento de dados inclui a


gesto no-estruturadas de dados que no so mantidos em sistemas de banco
de dados convencionais - por exemplo, usando formatos como texto, imagem e
udio. tambm responsvel 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 publicao ser em seu papel nas necessidades, projeto e
desenvolvimento fases do ciclo de vida de ativos e Servio.
A equipe de apoio ao processo de gerenciamento de dados tambm pode
fornecer uma empresa de servios de suporte de informao. Neste caso, eles
so capazes de responder a perguntas sobre o significado formato, e da
disponibilidade de dados internos organizao, porque gerir os metadados.
Eles tambm so capazes de compreender e explicar o que os dados externos
podem ser necessrios, a fim de realizar processos de negcios necessrios e
ir tomar as medidas necessrias para a fonte disso.
Criticamente, quando da criao ou redesenho de processos e apoio De
servios de TIs, bom prtica considerar re-utilizando dados e metadados em
diferentes reas da organizao. A capacidade de fazer isso pode ser suportado

ITIL V3 - Service Design - Pgina:

327 de 477

por um conjunto de dados corporativos modelo - s vezes conhecido como um


modelo de informao comum - para ajudar a apoiar a reutilizao, muitas
vezes, um grande objetivo para gerenciamento de dados.

5.2.3 Gesto de Dados e do Ciclo de Vida do Servio


Recomenda-se que uma abordagem do ser adoptadas em compreender o uso
de dados em processos de negcios. Questes gerais incluem:

Que dados realizada atualmente e como ele pode ser classificado?


O que os dados precisam ser coletados ou criados pelos processos de
negcio?
Como os dados sero armazenados e mantidos?
Como os dados sero acessados, por quem e de que forma?
Como os dados sero eliminados, e sob que autoridade?
Como ser a qualidade dos dados ser mantida (preciso, consistncia,
moeda, etc)?
Como os dados podem ser mais acessveis / disponveis?

5.2.4 Apoio ao Ciclo de Vida do Servio


Durante requisitos e projeto inicial, Gesto de Dados pode ajudar projeto e
equipes de desenvolvimento com servio de dados especficos modelagem e
dar conselhos sobre a utilizao de vrias tcnicas para os dados do modelo.
Durante o projeto ("fsico") detalhado e desenvolvimento, O gerenciamento de
dados funo de oferecer conhecimentos tcnicos em sistemas de gesto de
banco de dados e de como converter iniciais "lgicos" modelos de dados em
fsica, de produtos especficos, implementaes.
Muitos novos servios falharam porque m qualidade dos dados no foi
abordada durante o desenvolvimento do servio, ou porque um determinado
desenvolvimento criado os seus prprios dados e metadados, sem consulta com
outro proprietrio do servios, ou com gerenciamento de dados.

5.2.5 Valorizao dados


De dados um ativos e tem valor. Claramente em algumas organizaes isso
mais evidente do que em outros. Organizaes que so fornecedores de dados
para outros organizaos - Yell, Dun e Bradstreet, e Reuters - dados de valor
CAN como uma 'sada' em termos de preo que eles esto cobrando
organizaes externas para receb-lo. Tambm possvel pensar de valor em
termos do que os dados internos valeria a pena para outra organizao.
mais comum a dados de valor em termos de que vale a pena para a
organizao proprietrio. H um nmero de maneiras de se fazer isso sugeridos:

ITIL V3 - Service Design - Pgina:

328 de 477

Valorizar dados por disponibilidade: Uma abordagem freqentemente


usada a de considerar que processo de negcioes no seria possvel se
uma determinada pea de dados no estavam disponveis, e como muito
do que no-disponibilidade de dados custaria o negcio.
Valorizando os dados perdidos: Uma outra abordagem que
frequentemente usado pensar sobre os custos de obteno de alguns
dados, se fosse para ser destrudo.
Valorizao 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 so
aposentados, seja atravs de arquivamento ou destruio fsica. Pode ser
que alguns dados so fornecidos a partir de uma fonte externa e, em
seguida, realizada internamente, ou pode ser que os dados tm de ser
criados sistemas internos da organizao. Nestes dois casos, o ciclo de
vida e diferente do processoes que tm lugar durante a captura de
dados ser inteiramente separada. Em ambos os casos, o custars de
refazer esses estgios podem ser avaliados. O mais valorizado os dados,
mais o esforo 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,ttico ou
estratgico:

Dados operacionais: Necessrio para o funcionamento contnuo e de


uma organizao pode ser considerada como a mais baixa, mais
especfico, nvel.
Dados tticos: Geralmente necessria para segunda-line de gesto - ou
superior - e, normalmente preocupados com dados resumidos e dados
histricos, tipicamente ano-a-ano de dados ou dados trimestrais. Muitas
vezes os dados que usada aqui aparece em sistemas de gesto de
informao que requerem dados de resumo de uma srie de sistemas
operacionais, a fim de lidar com uma exigncia de contabilidade, por
exemplo.
Dados estratgicos: Muitas vezes preocupados com tendncias a longo
prazo e com a comparao com o mundo exterior, para fornecer os dados
necessrios para um sistema de apoio estratgico envolve a reunio de
dados operacionais e tticas de muitas reas diferentes, com dados
externos relevantes. Muito mais dados necessria a partir de fontes
externas.

Um mtodo alternativo a utilizao de um segurana classificao de dados e


documentos. Isso normalmente adotado como uma das empresas poltica
dentro de uma organizao.

ITIL V3 - Service Design - Pgina:

329 de 477

Uma classificao ortogonal distingue de toda a organizao de dados,


funcional-rea de dados e servios de dados especficos.

De toda a organizao de dados precisa ser gerenciado centralmente.


O prximo nvel de dados funcional-rea de dados que devem ser
compartilhadas atravs de um negcio completo funo. Isso envolve a
partilha de 'instncias' de dados - por exemplo, cliente individual registros
- e tambm garantir que os metadados consistente em que a rea
funcional, como formatos de endereo padro, esto sendo usados.
O ltimo nvel o servio de TI especfico, onde os dados e metadados
so vlidos por um De servios de TI e no precisa ser compartilhada
com outros servios.

Dados 5.2.7 estabelece normas


Um dos aspectos crticos da administrao de dados garantir que os padres
de metadados esto no local - por exemplo, o que metadados a ser mantido
para diferentes tipos de dados subjacentes . Diferentes detalhes so mantidos
sobre estruturadas dados tabulares do que para outras reas. 'Propriedade'
um item crtico desses metadados, algum tipo de identificador exclusivo outra,
uma descrio em termos de negcios significativos outro, e um formato pode
ser outro. O custodiante ou mordomo, algum no departamento de TI, que
assume a responsabilidade pela gesto do dia-a-dia dos dados, tambm
registrado.
Outro benefcio de um processo de gerenciamento de dados seria no campo de
dados de referncia. Certos tipos de dados, como cdigos postais ou nomes de
pases, pode ser necessrio em uma variedade de sistemas e precisa ser
consistente. parte da responsabilidade de administrao de dados para
gerenciar os dados de referncia, em nome de toda a empresa, e para se
certificar de que os dados de referncia utilizada a mesma em todos os
sistemas da organizao.
Normas para a nomeao devem estar no lugar, por isso, por exemplo, se um
novo tipo de dados requerido num novo servio, Ento no h a necessidade
de utilizar os nomes que correspondam a estas normas. Um exemplo padro
pode ser 'todas as capitais, sem sublinhado e sem abreviaturas.

5.2.8 Propriedade dos dados


Administrao de dados pode ajudar o desenvolvedor do servio, fazendo
responsabilidades seguros para a propriedade dos dados so levadas a srio
pela negcio 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
orientao para a gesto cuidadosa dos dados da organizao, por adeso a

ITIL V3 - Service Design - Pgina:

330 de 477

padres definidos corporativamente. Responsabilidades de um proprietrio de


dados so muitas vezes definidas aqui e podem incluir:

Concordando uma descrio do negcio e um propsito para os dados


Definir quem pode criar, alterar, ler e apagar os dados de ocorrncias de
Alteraes oramentais na forma como os dados so capturados ou
derivados
Aprovar quaisquer faixas de domnio, formato e valor
Aprovar a nvel relevante de segurana, Inclusive certificando-se de que
os requisitos legais e polticas internas sobre a segurana de dados so
respeitados.

5.2.9 A migrao de dados


A migrao de dados um problema em um novo servio est substituindo uma
srie de (possivelmente apenas um) dos servios existentes, e necessria a
realizao de dimetro, para o novo servio, boa qualidade de dados dos
sistemas e servios existentes. Existem dois tipos de migrao de dados de
interesse para projetos aqui: uma a migrao de dados em data warehouses,
etc, para inteligncia de negcios / fins de anlise, a outra a migrao de
dados para um novo transaoal, operacional servio. Em ambos os casos, ser
benfica se os padres de migrao de dados, procedimentos e os processos
so estabelecidas pela Administrao de Dados. Ferramentas de migrao de
dados j pode ter sido adquirido em nome da organizao, a equipe de
gerenciamento de dados. Sem este apoio, muito fcil subestimar a quantidade
de esforo que necessrio, especialmente se consolidao de dados e limpeza
tem de ter lugar entre os sistemas de mltiplas fontes, eo qualidade dos dados
dos servios existentes " conhecido por ser questionvel.

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 implicaes de custos associados a este. A principal razo
para a compreenso dos desenvolvimentos nesta rea que eles tornam
possveis muitos tipos de reas de gerenciamento de dados que foram
considerados demasiado caro antes. Por exemplo, para armazenar vdeo em
tempo real, que utiliza uma largura de banda grande, tem, at que os ltimos
dois ou trs anos, sido considerado demasiado caro. O mesmo verdade para a
digitalizao de um grande nmero de documentos em papel, especialmente
quando esses documentos no so baseados em texto, mas contm diagramas
detalhados ou imagens. Compreender desenvolvimentos tecnolgicos no que
diz respeito ao armazenamento eletrnico de dados fundamental para a
compreenso das oportunidades para o negcio para explorar a informao
recurso efetivamente, fazendo o melhor uso de novas tecnologias.

ITIL V3 - Service Design - Pgina:

331 de 477

5.2.11 A captura de dados


Tambm muito importante trabalhar com gerenciamento de dados sobre
medidas eficazes para a captura de dados. O objetivo aqui capturar dados
mais rpida e precisa possvel. Existe uma necessidade de assegurar que os
processos de captura de dados requer o mnimo de codificao, e explorar as
vantagens que grficas usurio interfaces fornecem, em termos de minimizar o
nmero de batidas de tecla necessrios, diminuindo tambm a possibilidade de
erros durante a captura de dados. razovel esperar que a gesto de dados
processo tem padres para, e pode fornecer conhecimentos sobre os mtodos
eficazes de captura de dados em vrios ambientes, incluindo "no-estruturados"
de captura de dados utilizando mecanismos como a digitalizao.

5.2.12 recuperao de dados e uso


Uma vez que os dados tenham sido captado e armazenado, o prximo aspecto
a ser considerado a recuperao da informao a partir dos dados. Servios
para permitir o acesso fcil a dados estruturados atravs de ferramentas de
consulta de vrios nveis de sofisticao so necessrios a todas as
organizaes, e gerar as suas prprias exigncias arquitetnicas.
Toda a rea de pesquisa dentro do texto digitalizado e outros no-estruturadas
de dados, tais como vdeo, imagens ou som ainda uma importante rea de
expanso. Tcnicas como a indexao automtica, e a utilizao de motores de
busca para dar um acesso eficiente por meio de palavras-chave para as peas
relevantes de uma documento, So as tecnologias essenciais que tm sido
amplamente implementadas, principalmente na internet. Experincia na
utilizao de dados ou de contedo dentro de sites devem existir dentro da
Gesto de Dados, bem como gerenciamento de contedo - normas e
procedimentos que so vitais para websites.

5.2.13 A integridade de dados e questes relacionadas


Ao definir os requisitos para De servios de TIs, vital que a gesto operacional
e requisitos relacionados com dados serem considerados. Em particular, as
seguintes reas devem ser abordadas:

Recuperao de dados perdidos ou corrompidos


Acesso controlado aos dados
Implementao de polticas de arquivamento de dados, incluindo
observncia com perodos de reteno de regulamentao
Dados peridicos integridade cheques.

A integridade dos dados est preocupado com a garantia de que os dados so


de alta qualidade e no corrompido. tambm sobre a preveno da duplicao
de dados sem controle, e, portanto, evitando qualquer confuso sobre o que o

ITIL V3 - Service Design - Pgina:

332 de 477

vlido verso dos dados. H vrias abordagens que podem ajudar com isso.
Vrios dispositivos de tecnologia, tais como "bloqueio de banco de dados 'so
usados para evitar mltipla, inconsistente, atualizao de dados. Alm disso, a
preveno de actualizao ilegal pode ser conseguido atravs de mecanismos
de controlo de acesso.

ITIL V3 - Service Design - Pgina:

333 de 477

5,3 Gerenciamento de Aplicativos


Um aplicao aqui definido como o programa de software (s) que
desempenhar as funes especficas que apiam diretamente a execuo de
processo de negcioes e / ou procedimentos.
Aplicaes, 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 servio de TI. O aplicativo em si apenas um
componente, embora importante do servio. Por isso, importante que a
aplicao entregue corresponde aos requisitos acordados da negcio. No
entanto, muitos organizaos gastar muito tempo focando os requisitos
funcionais do novo servio e aplicao, e tempo insuficiente gasto para
projetar a gesto e operacional requisitos (no-funcionais) do servio. Isto
significa que quando o servio estiver operacional, atende a todas as
funcionalidades necessrias, mas totalmente no atender a expectativa do
negcio e da clientes em termos da sua qualidade e atuaoE, portanto, tornase inutilizvel.
Duas abordagens alternativas so necessrias para implementar integralmente
Aplicao de Gesto de. Uma abordagem emprega um longo servio
Development Lifecycle (SDLC) para apoiar a desenvolvimento de um servio de
TI. SDLC uma abordagem sistemtica para a resoluo de problemas e
composto das seguintes etapas:

Estudo de viabilidade
Anlise
Projeto
Teste
Implementao
Avaliao
Manuteno.

A outra abordagem tem uma viso global de todos os servios para garantir a
contnua manuteno e gerenciamento da aplicaos:

Todas as aplicaes so descritos de uma forma consistente, atravs de


um Application Portfolio que gerido e mantido para permitir alinhamento
com as necessidades dinmicas dos negcios.
Consistncia da abordagem do desenvolvimento aplicada atravs de
um nmero limitado de estruturas de aplicativos e padres de projeto e
atravs da filosofia primeira a 'reutilizao'.
Componentes de software comuns, geralmente, para suprir as
necessidades operacionais e de gesto, so criados ou adquiridos em um
nvel "organizacional" e utilizados por sistemas individuais como eles so
projetados e construdos.

ITIL V3 - Service Design - Pgina:

334 de 477

5.3.1 O portflio de aplicativos


Isto simplesmente um completo registro de todos aplicaos dentro da
organizao e dinmico em seu contedo.
Nome do aplicativo

Operaes de TI proprietrio

Novo desenvolvimento
custar

Identificador da
aplicao

TI proprietrio
desenvolvimento

Anual custo
operacionals

Descrio da
aplicao

Contatos de suporte

Custo de suporte anual

Processo de negcio
suportada

Tecnologias de banco de
dados

Custos anuais de
manuteno

Servios de TI
apoiada

Aplicativos dependentes

Terceirizado
componentes

Patrocinador
executivo

Sistemas de TI apoiada

Terceirizar parceiros

Geografias suportado

Interfaces de usurio

Produo mtricos

Importncia do
negcio

Arquitetura de TI, incluindo a


topologia de rede

Ligao OLA

SLA link

Tecnologias de aplicao
utilizada

Mtricas de apoio

Proprietrio da
empresa

Nmero de usurios

Tabela Application Portfolio 5,5 atribui exemplo

5.3.2 Vinculao portflios de aplicativos e servio


Alguns organizaos manter um separado Application Portfolio com separado
atributos, enquanto que em outras organizaes Carteira de aplicao
armazenado dentro da CMS, juntamente com a apropriada relaos. Outras
organizaes combinar o portflio de aplicativos em conjunto com o Portflio de
Servios. Cabe a cada organizao decidir o mais adequado estratgia para
suas prprias necessidades. O que est claro que deve haver relaes muito
estreitas e as ligaes entre o aplicaos e os servios que eles suportam e os
componentes de infra-estrutura utilizada.

ITIL V3 - Service Design - Pgina:

335 de 477

5.3.3 frameworks de aplicao


O conceito de uma estrutura de aplicativo muito poderoso. A estrutura do
aplicativo cobre toda a gesto e operacional aspectos e, na verdade, oferece
solues para todas as necessidades de gesto e operacionais que cercam uma
aplicao.
Implcita no uso de frameworks de aplicao o conceito de padronizao. Se
uma organizao usa e tem de manter uma estrutura de aplicativo para cada
nica aplicao, No haver muitos benefcios da utilizao de uma estrutura de
aplicao.
Uma organizao que pretende desenvolver e manter estruturas de aplicativos,
e para assegurar que os frameworks de aplicao em conformidade com as
necessidades dos desenvolvedores de aplicativos, deve investir em faz-lo.
essencial que as arquiteturas de Aplicativos no so desenvolvidas de forma
isolada, mas esto intimamente relacionadas e integradas com todos os outro
quadro e actividades de arquitectura. As arquiteturas de servios, de Infraestrutura, Meio Ambiente e dados devem ser todos em estreita integrao com a
arquitetura do aplicativo e um quadro.
Estruturas de arquitetura, aplicao e padres
Arquitetura atividades relacionadas devem ser planejados e gerenciados
separadamente do software baseado no sistema indivduo projetos. Tambm
importante que a arquitectura actividades relacionadas com o ser realizada para
o benefcio de mais do que apenas um aplicao. Os desenvolvedores de
aplicativos deve se concentrar em uma nica aplicao, enquanto os
desenvolvedores de aplicativos quadro deve se concentrar em mais de um
aplicativo, e sobre as caractersticas comuns desses aplicativos, em particular.
Um comum prtica distinguir entre vrios tipos de aplicaes. Por exemplo,
nem todas as aplicaes podem ser construdas 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 vrios
tipos de aplicaes pode ser considerada como famlias de aplicao. Todos os
aplicativos da mesma famlia so baseados no quadro do mesmo aplicativo.
Utilizando o conceito de uma estrutura de aplicao, o primeiro passo da fase de
design da aplicao identificar a estrutura de aplicao apropriada. Se o
quadro de aplicao maduro, um grande nmero de decises de projeto so
dadas. Se ele no est madura, e todos os requisitos de gesto e operacionais
no podem ser cumpridas em cima de uma estrutura de aplicativo existente, o
preferido estratgia coletar e analisar os requisitos que no podem ser
tratadas na atual verso da estrutura do aplicativo. Com base nos requisitos de
aplicao, novos requisitos podem ser definidos para a estrutura do aplicativo.

ITIL V3 - Service Design - Pgina:

336 de 477

Em seguida, o quadro de aplicao pode ser modificado para que possa lidar
com as necessidades de aplicao. De facto, toda a famlia de aplicaos, que
corresponde estrutura de aplicativos podem usar os recursos de estrutura
recm-adicionados ou alterados.
Desenvolvimento e manuteno 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 aplicao
podem ser adquiridos de terceiros.

5.3.4 A necessidade de ferramentas CASE e repositrios


Um aspecto importante do que o alinhamento global a necessidade de alinhar
aplicaos com as suas estruturas de apoio subjacentes. Aplicao ambiente de
desenvolvimentos tradicionalmente tm seu prprio 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 aplicaes completas, ou
esqueletos quase completos de aplicao, quase pronto para ser implantado.
Estes ambientes tambm fornecer um local central para armazenar e gerenciar
todos os elementos que so criados durante o desenvolvimento de aplicativos,
geralmente chamado de repositrio. Funcionalidade inclui repositrio verso
controle e verificao de coerncia entre as diferentes modelos. A abordagem
atual usar metacase-ferramentas para modelar linguagens especficas de
domnio e us-los para fazer o caso mais trabalho alinhado s necessidades do
negcio.

5.3.5 Design de aplicaes especficas


A fase de requisitos do ciclo de vida foi abordado anteriormente na seo de
engenharia de requisitos. A fase de projeto uma das fases mais importantes
dentro do ciclo de vida da aplicao. Assegura-se que um aplicao concebido
com operacionalidade e Aplicao de Gesto de em mente. Esta fase tem as
sadas a partir da fase de requisitos e transforma-os em a especificao que iro
ser utilizados para desenvolver a aplicao.
A meta para projetos deve ser satisfazer os requisitos da organizao. Projeto
inclui a projeto da aplicao em si, eo projeto de infra-estrutura e ambiente
dentro da qual a aplicao opera. Consideraes de arquitetura so o aspecto
mais importante desta fase, uma vez que podem ter impacto sobre a estrutura
eo contedo de ambos aplicao e modelo operacional. Consideraes de
arquitetura para a aplicao (desenho da arquitetura de aplicaes) e
consideraes de arquitetura para o ambiente (desenho da arquitetura de TI)
esto fortemente relacionados e precisam ser alinhados. Arquitetura e design de
aplicao no deve ser considerada isoladamente, mas devem formar um
componente global e integrada da arquitetura de servio e design.

ITIL V3 - Service Design - Pgina:

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 so
adicionados. Os novos modelos incluem o arquitetura modelos, em que a
maneira pela qual o funcionais diferentes componentes so mapeados para os
componentes fsicos (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 necessria.
Outro aspecto importante do modelo de arquitectura a incorporao do
aplicao no ambiente existente. Que partes da infra-estrutura existente ser
utilizado para apoiar as funes necessrias novas? Pode servidores existentes
ou redes de ser usado? Com que impacto? So necessrias funes disponveis
em aplicaes j existentes que podem ser utilizados? No existem pacotes que
oferecem a funcionalidade necessria ou se as funes de ser construdo a
partir do zero?
O projeto fase tem todos os requisitos em considerao e comea a mont-los
em um projeto inicial para a soluo. Fazer isso no s d aos desenvolvedores
uma base para comear a trabalhar: tambm provvel para trazer perguntas
que precisam ser feitas da clientes /usurios. Se possvel, frameworks de
aplicao deve ser aplicado como um ponto de partida.
Nem sempre possvel prever todos os aspectos do design de uma soluo
antes do tempo. Como uma soluo seja desenvolvida, coisas novas sero
aprendidas sobre como fazer as coisas e tambm como no.
A chave criar um projeto flexvel, de modo que fazer uma mudar no enviar os
desenvolvedores de todo o caminho de volta para o incio da fase de projeto. H
uma srie de abordagens que podem minimizar a chance de que isso acontea,
incluindo:

Projetando para requisitos de gesto e operacionais


Gerenciando trade-offs
Usando independente de aplicao de design diretrizs, utilizando
frameworks de aplicao
Empregando um processo estruturado o modelo da lista / gerenciamento.

Projeto de gesto e requisitos operacionais significa dar requisitos de gesto e


operacionais de um nvel de importncia similar ao dos requisitos funcionais, e
inclu-los como parte obrigatria da fase de projeto. Isto inclui um nmero de
gesto e os requisitos operacionais, tais como
disponibilidade,capacidade,manuteno,confiana e segurana. Agora,
inconcebvel em projetos de desenvolvimento de aplicativos modernos que
usurio design de interface (usabilidade requisitos) seria omitido como um
projeto-chave atividade. No entanto, muitos organizaos ignorar ou esquecer

ITIL V3 - Service Design - Pgina:

338 de 477

de gerenciamento. Detalhes da gesto necessria e requisitos operacionais


esto contidas dentro do SDP e SAC nos apndices A e B.

5.3.6 Gerente trade-offs


Gerenciando trade-off decises foca equilibrando a relao entre os recursos, o
cronograma do projeto, e os recursos que precisam ser includos no aplicao
por causa da qualidade.
Quando as equipes de desenvolvimento de tentar completar este equilbrio,
muitas vezes em detrimento da gesto e operacional requisitos. Uma forma de
evitar isso para incluir a gesto e os requisitos operacionais nas orientaes
aplicao independente de concepo - por exemplo, sob a forma de uma
estrutura de aplicao. Operacionalidade e capacidade de gesto efetivamente
se tornar padro componentes de todo o projeto processoes - por exemplo, sob
a forma de uma estrutura de aplicao - e ficar encaixado no trabalho prticas e
cultura da organizao de desenvolvimento.

5.3.7 tpicas sadas de projeto


Os seguintes so exemplos das sadas a partir de uma pea de design
aplicaes formao do conjunto Design de Servios:

De entrada e sada de projeto, incluindo formulrios e relatrios


A utilizvel usurio design de interface (interao homem-computador)
Um dado adequado / objeto modelo
Um fluxo de processo ou fluxo de trabalho modelo
Detalhado especificaos para atualizao e somente leitura processos
Mecanismos para alcanar os controles de auditoria,
segurana,confidencialidade e privacidade
A tecnologia especfica projeto "fsico"
Scripts para testar o projeto de sistemas
Interfaces e dependncias de outras aplicaes.

Tem diretrizs e estruturas que podem ser adotadas para determinar e definir as
sadas de projeto dentro do Gerenciamento de Aplicativos, como Capability
Maturity Model Integration (CMMI).

5.3.8 Os padres de design


Um padro de projeto uma soluo, em geral repetitivo para um problema
comumente ocorrem em design de software. Padres de design orientado a
objeto normalmente mostrar as relaes e interaes entre classes ou objetos,
sem especificar as classes de aplicaes finais ou objetos que esto envolvidos.
Padres de projeto descrevem tanto um problema e uma soluo para
problemas comuns encontrados no desenvolvimento do aplicativo.

ITIL V3 - Service Design - Pgina:

339 de 477

Um importante projeto princpio usado como a base para um grande nmero de


padres de design encontrados em literatura recente o de separao de
preocupao. Separao de preocupaes vai conduzir a aplicaes divididas
em componentes, com uma forte coeso e acoplamento mnimo entre
componentes. A vantagem de uma tal aplicao que a modificao pode ser
feita para os componentes individuais com pouco ou nenhum impacto sobre as
outras componentes.
No desenvolvimento de aplicaes tpicas projetos, mais de 70% do esforo
gasto na concepo e desenvolvimento de funes genricas e em satisfazer as
necessidades de gesto e operacional. Isso porque cada aplicao precisa
fornecer uma soluo para tais caractersticas genricas como a impresso, erro
manuseamento e segurana.
Entre outros, o Object Management Group (OMG, www.omg.com) definiu um
grande nmero de servios que so necessrios em todos os aplicao.
Arquitetura da OMG (Object Management OMA) distingue claramente entre os
aspectos funcionais e de gesto e operacionais de uma aplicao. Ela se baseia
no conceito de proporcionar um tempo de execuo ambiente que oferece todos
os tipos de instalaes para um aplicativo.
Neste conceito, a aplicao abrange os aspectos funcionais, e ao meio ambiente
abrange todos os aspectos de gesto e operacional. Os desenvolvedores de
aplicativos deve, por definio, o foco sobre os aspectos funcionais de uma
aplicao, enquanto outros podem se concentrar na criao de um ambiente que
oferece a gesto necessria e servios operacionais. Isto significa que os
programadores de aplicaes focar os requisitos da negcio, Enquanto que o
arquitetura desenvolvedores ou programadores Application Framework focar as
necessidades dos desenvolvedores de aplicativos.

5.3.9 Desenvolvimento de aplicaes individuais


Uma vez que a fase de projeto estiver concludo, a equipe de desenvolvimento
do aplicativo levar os projetos que tenham sido produzidos e passar para o
desenvolvimento do aplicao. O aplicativo e ambiente relacionados esto
prontas para desenvolvimento. Componentes de aplicao so codificados ou
adquirida, integrado e testado.
Para garantir que o aplicativo desenvolvido com a gesto no ncleo, a equipe
de desenvolvimento tem de se concentrar em garantir que a fase de
desenvolvimento continua a enderear corretamente a gesto e operacional
aspectos da projeto (E.g. capacidade de resposta,disponibilidade,segurana).
O desenvolvimento orientao fase abrange os seguintes tpicos:

Consistentes convenes de codificao

ITIL V3 - Service Design - Pgina:

340 de 477

Aplicao independentes diretrizes de construo


Testes de operacionalidade
Lista de verificao de Gesto para a fase de construo
Organizao da equipe de construo papels.

5.3.10 consistentes convenes de codificao


A principal razo para a utilizao de um conjunto consistente de design e
convenes de codificao padronizar a estrutura e estilo de codificao de
um aplicao para que todos possam facilmente ler, entender e gerenciar o
desenvolvimento de aplicaes processo. Um bom design e codificao
resultado convenes no cdigo fonte precisa, legvel e inequvoca de que
consistente com a codificao de organizao e normas de gesto e to
intuitivo para seguir possvel. Adicionando operacionalidade aplicativo para esta
conveno garante que todas as aplicaes so construdas de uma maneira
que garante que eles podem ser totalmente gerenciado por todo o caminho
atravs de seu ciclo de vidas.
Uma conveno de codificao em si pode ser uma ajuda significativa gesto
da aplicao, como consistncia permite que as ferramentas de gerenciamento
de interagir com a aplicao de uma forma conhecida. melhor introduzir um
conjunto mnimo de convenes que todos vo seguir, em vez de criar um
conjunto muito complexo que engloba todos os aspectos, mas no seguido ou
usado de forma consistente em todo o organizao.

5.3.11 modelos e gerao de cdigo


Uma srie de ferramentas de desenvolvimento fornecem uma variedade de
modelos para a criao de componentes de aplicativos comuns. Em vez de criar
todas as peas de uma aplicao a partir do zero, os desenvolvedores podem
personalizar um modelo existente. Eles tambm podem reutilizar personalizado
componentes em mltiplas aplicaos, criando seus prprios modelos. Outras
ferramentas de desenvolvimento ir gerar grandes pedaos de cdigo
(esqueletos), baseado no desenho modelos e convenes de codificao. O
cdigo pode incluir ganchos nas peas de cdigo que tm de ser adicionados.
A este respeito, modelos e estruturas de aplicativos de TI deve ser considerada
ativoss. Esses ativos no apenas orientar o desenvolvimento de aplicaes, mas
tambm incorporar as lies aprendidas ou capital intelectual de esforos para o
desenvolvimento de aplicaes anteriores. Quanto mais os componentes
normais so concebidos para a soluo, as aplicaes mais rpidas podem ser
desenvolvidos, contra menor custars, a longo prazo (no ignorando o fato de
que o desenvolvimento de modelos, geradores de cdigo e estruturas de
aplicao requer um investimento significativo).

ITIL V3 - Service Design - Pgina:

341 de 477

5.3.12 instrumentao aplicativo embutido


O desenvolvimento ofertas de fase com a incorporao de instrumentao no
tecido do aplicao. Desenvolvedores precisam de uma maneira consistente
para fornecer instrumentao para os motoristas de aplicao /middleware
componentes (por exemplo, motoristas de banco de dados) e aplicaes que
eficiente e fcil de implementar. Para manter os desenvolvedores de aplicativos
de reinventar a roda a cada nova aplicao que se desenvolvem, a indstria de
computadores fornece mtodos e tecnologias para simplificar e facilitar o
processo de instrumentao.
Estes incluem:

Aplicao Medio 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 configurao, estado e aspectos operacionais da aplicaos e
servios. Estes so fornecidos atravs de interfaces de programao de
aplicativos (APIs Programa) que o desenvolvedor incorpora em uma aplicao,
normalmente atravs da utilizao de modelos de programao padro.
importante assegurar que todas as aplicaes so construdos para estar em
conformidade com um certo nvel de observncia para a aplicao de
instrumentao. Maneiras de fazer isso podem incluir:

Proporcionar o acesso a dados de gesto por meio da API de


instrumentao
Publicar dados de gesto para outros sistema de gestos, de novo
atravs do API instrumentao
Fornecer aplicaes evento manipulao
Fornecer um gancho de diagnstico.

5.3.13 ganchos de diagnstico


Ganchos de diagnstico so de maior valor durante o teste e, quando um erro
Foi descoberto no servio de produo. Ganchos de diagnstico, principalmente,
fornecer as informaes necessrias para resolver problemas e erros de
aplicao rpida e restaurar servio. Eles tambm podem ser usados para
fornecer a medio e gesto da informao de aplicaes.

ITIL V3 - Service Design - Pgina:

342 de 477

As trs categorias principais so:

Nvel de sistema informaes fornecidas pelo sistema operacional e de


hardware
Software nvel de informaes fornecidas pela infra-estrutura de aplicao
componentes, tais como web banco de dados, servidor ou sistemas de
mensagens
Informao personalizada fornecida pela aplicaos
Informaes sobre o componente e servio atuao.

5.3.14 Principais sadas de servio de desenvolvimento


As sadas importantes a partir da fase de desenvolvimento so os seguintes:

Scripts para ser executado antes ou depois desenvolvimento


Scripts para iniciar ou parar a aplicao
Scripts para verificar configuraes de hardware e software de ambientesalvo antes da implantao ou instalao
Especificao de mtricos e eventos que podem ser obtidos a partir da
aplicao e que indicam o desempenho estado do aplicao
Scripts personalizados iniciadas por Operao de Servio equipe para
gerenciar a aplicao (incluindo a manipulao de atualizaes de
aplicativos)
Especificao das informaes de controle de acesso para o sistema
recursos usado por um aplicativo
Especificao dos detalhes necessrios para controlar um aplicativo de
grande transaos
Metas de SLA e requisitos
Operacional requisitos e documentao
Necessidades de apoio
Aplicao recuperao e apoios
Outros requisitos de TI SM e metas.

ITIL V3 - Service Design - Pgina:

343 de 477

6 Organizador para Design de Servios


Para Design de Servios para ser bem sucedido, essencial para definir o
papels e responsabilidades dentro da organizao das vrias actividades.
Ao projetar um servio ou um processo, imperativo que todas as funes
esto claramente definidas. A marca de alto desempenho organizaos a
capacidade de tomar as decises certas rapidamente e execut-los de forma
eficaz. Se a deciso envolve estratgico escolha ou uma crtica operao, Ser
claro sobre quem tem de entrada, quem decide e quem toma a ao vai permitir
empresa a avanar rapidamente.
O RACI modelo ser benfico para permitir que as decises sejam tomadas com
ritmo e confiana. RACI um acrnimo para as quatro principais funes:

Responsvel - A pessoa ou as pessoas responsveis por fazer o


trabalho
Responsvel - S uma pessoa pode ser responsvel por cada tarefa
Consultado - As pessoas que so consultados e cujas opinies so
procurados
Informado - As pessoas que so mantidos up-to-date em andamento.

Ocasionalmente, um expandida verso de RACI usado chamado RACI-VS,


com dua