Itil v3 Design de Serviços

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.
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
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.2 mbito .................................................................................................................. 117
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.1 processo entradas SLM ............................................................................................ 135
4.2.6.2 sadas processo SLM................................................................................................ 135

4.2.7.1 KPIs.......................................................................................................................... 138
4.2.8 Gesto da Informao .......................................................................................... 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
4 de 477

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.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.1 Entradas ................................................................................................................... 169
4.3.6.2 Sadas ...................................................................................................................... 170

4.3.8.1 Capacidade do Sistema de Informao de Gesto .................................................... 173
4.4 Gerenciamento de Disponibilidade ...................................................................... 177

4.4.2 mbito .................................................................................................................. 177
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.1 Entradas ................................................................................................................... 222
4.4.6.2 Sadas ...................................................................................................................... 223

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

4.5.2 mbito .................................................................................................................. 230
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.1 Entradas ................................................................................................................... 255
4.5.6.2 Sadas ...................................................................................................................... 256

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

4.6.2 mbito .................................................................................................................. 260
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.1 Os controles de segurana........................................................................................ 267
4.6.5.2 Gesto de violaes de segurana e incidentes ........................................................ 269

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

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

4.7.2 mbito .................................................................................................................. 277
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.1 Entradas ................................................................................................................... 301
4.7.6.2 Sadas ...................................................................................................................... 302

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
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
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
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
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
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
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.
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
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
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
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
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
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.
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).
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.
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.
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.
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.
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 /
24 de 477
IEC 20000, estabelecido e capaz de receber entradas para a mudana de

qualquer perspectiva de planejamento.
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
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
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.
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
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
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
31 de 477
perspectiva de controle pode revelar padres que podem no ser evidentes a

partir do outro.
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.
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
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
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.
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
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
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.
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
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
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.
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:
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.
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
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.
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.
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.
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
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.
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.
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.
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
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
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
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
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.
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
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.
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
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
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
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
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.
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
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
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.
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.
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.
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.
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
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
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.
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
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
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.
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:
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
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.
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
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
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.
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
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
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.
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.
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
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.
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.
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.
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.
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.
92 de 477
Figura 3.15 O contnuo de gesto de TI
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.
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
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
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.
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

empresas
Perda de conhecimento do
negcio
Perda de relao com o negcio
Prestao de Servios
de Aplicativos
O acesso a solues caras e

complexas
Suporte e atualizaes includo
Segurana e opes ITSCM
includo

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

empresas
Perda de competncias internas
Perda da relao com o negcio
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"
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.
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
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
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:
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.
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.
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.
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
107 de 477
4.1 Gesto Catlogo de Servios

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.
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
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:
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
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
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.
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.
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.
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.

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
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.
117 de 477

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.
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:
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.
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
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
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
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
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.
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.
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.
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.
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.
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.
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.
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
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,
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.
134 de 477

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:
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
SLR para cada novo servio proposto ou alterados
Acordo de Nvel Operacionals (ANO): um conjunto de metas e
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.

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
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
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)
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.

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
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.
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
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.
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
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:
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,
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
146 de 477
planejamento de capacidade, identificando o tempo para aquisio e

implementao de novas tecnologias, hardware e software.

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.

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
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
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.
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.
150 de 477

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.
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.
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
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
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
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.
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.
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
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.
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.
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:
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
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.
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,
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
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
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
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
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.

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.
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
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.

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)
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.

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
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
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
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.

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.
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.
176 de 477
4.4 Gerenciamento de Disponibilidade

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
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
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
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
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.

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.
179 de 477

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
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.
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
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%
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.
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:
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.

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.
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:
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.
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
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
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
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.
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
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.
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.
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
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
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.
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
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
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.
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
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.
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
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.
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:
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
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
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:
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:
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
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.
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.
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.
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.
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
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
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
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
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
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-
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

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
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:
222 de 477

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,
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
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.

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).
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.

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
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
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.

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
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
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.
228 de 477
4,5 Gerenciamento de Continuidade do Servio

'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
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
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.
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.
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.

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.

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.
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.
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.

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
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
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
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
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
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
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.
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.
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
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
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
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-
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
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,
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
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
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.
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:
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:

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,
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.
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.

Muitos eventos podem desencadear atividade GCSTI. Estes incluem:

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
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.
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
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.

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
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.

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.

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.
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
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.
258 de 477
4.6 Gesto de Segurana da Informao

"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
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.
260 de 477

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.

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
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
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.
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

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.
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.
265 de 477

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.
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.
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
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
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.

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

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
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.

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:
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.

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.
273 de 477

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
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
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
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
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.
276 de 477
4,7 Gesto de Fornecedores

"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
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.
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.

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.

O Gesto de Fornecedores tentativas processo para garantir que os
fornecedores cumpram os termos, condies e metas do seu contratos e
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:
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.

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:
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
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.
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
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.
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
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,
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.
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).
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,
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
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
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.
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
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:
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.
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
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
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:
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.

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
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.
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

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
detalhes dos servios da Portflio de Servios e a Catlogo de
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.

Muitos KPIs e mtricos pode ser usada para avaliar a eficcia e eficincia do
Gesto de Fornecedores processos e atividades. Essas mtricas precisam ser
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.

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

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
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:
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.
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.
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
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
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
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
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,
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.
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
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
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:
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
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
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
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.
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
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'.
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
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
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.
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.
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
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
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:
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.
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
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.
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
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.
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.
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.
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.
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.
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
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.
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
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).
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.
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.
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 duas funes adicionais, como segue:
Verifica - A pessoa ou grupo que verifica se os critrios de aceitao

foram atendidos
Sinais fora - A pessoa que aprova a deciso V e autoriza o produto handoff. Esta poderia ser a pessoa A.
Uma terceira variao do modelo RACI RASCI, onde o S representa de

suporte. Este papel oferece recursos adicionais para realizar o trabalho, ou tem
um apoio papel na implementao, por exemplo. Isto pode ser benfico para De
servios de TI implementao.
Diretor do Servio de
Gerenciamento
Gerente de
Nvel de
Servio
Gerente de
problema
Security
Manager
Gerente de
Compras
Atividade
1
AR
Eu
Eu
Atividade
2
Atividade
Eu
Eu
344 de 477
3
Atividade
4
Eu
Eu
Atividade
5
Eu
Eu
Eu
Tabela 6.1 Exemplo de matriz RACI
O grfico RACI na Tabela 6.1 mostra a estrutura e do poder de RACI

modelagem com as atividades abaixo o lado esquerdo, incluindo as aes que
precisam ser tomadas e as decises que devem ser feitas. Na parte superior, a
tabela lista os papis funcionais responsveis pela realizao da iniciativa ou a
desempenhar um papel na tomada de decises.
Se RACI ou alguma outra ferramenta ou modelo usado, o importante no
deixar a atribuio de responsabilidades ao acaso ou deixar para o ltimo minuto
para decidir. Os conflitos podem ser evitados e as decises podem ser tomadas
rapidamente se os papis so distribudos com antecedncia.
Para construir um grfico RACI os seguintes passos so necessrios:
Identificar as atividades /processoes

Identificar / definir os papis funcionais
Realizar reunies e atribuir os cdigos RACI
Identificar eventuais lacunas ou sobreposies - por exemplo, onde
existem duas RS ou no RS (ver anlise abaixo)
Distribua o grfico e incorporar o feedback
Certifique-se que as atribuies esto sendo seguidos.
345 de 477
6.1 Anlise Funcional papis
Muitos Como: so deveres segregados corretamente? Caso algum

ser responsvel por algumas dessas atividades? este causando um
gargalo em algumas reas que iro atrasar decises?
Rs muitos: Isso demais para um funo?
Sem espaos vazios: Ser que isso papel precisam estar envolvidos
em tantas tarefas?
Alm disso, o tipo ou o grau de participao caber qualificaes este
papel de?
6.2 Anlise de Atividade
Mais do que um A: apenas um papel pode ser responsvel.

Como no: pelo menos um A, deve ser atribudo a cada atividade.
Mais de um R: tambm muitos papis responsveis, muitas vezes
significa que ningum assume a responsabilidade. A responsabilidade
pode ser compartilhada, mas somente se os papis so claros.
No Rs: pelo menos uma pessoa deve ser responsvel.
Muitos Cs: Existe uma exigncia de consulta com tantos papis?
Quais so os benefcios e pode o tempo extra pode ser justificada?
Cs e no : so os canais de comunicao abertos para permitir que
as pessoas e departamentos para falar uns com os outros e manter-se
mutuamente up-to-date?
346 de 477
6,3 habilidades e atributos

As funes especficas dentro de ITIL Servio de Gesto de todos exigem
habilidades especficas, atributos e competncias das pessoas envolvidas para
que possam trabalhar de forma eficaz e eficiente. No entanto, qualquer que seja
o papel, imperativo que a pessoa realizar essa funo tem os seguintes
atributos:
A conscincia das prioridades da empresa, objetivos e drivers de negcio

Conscincia do papel que desempenha em permitir que o objetivo de
negcios a serem cumpridas
Servio ao cliente habilidades
Conscincia do que TI pode entregar ao negcio, Incluindo as mais
recentes capacidades
A competncia, conhecimento e informaes necessrias para concluir o
seu papel
A capacidade de usar, entender e interpretar o melhores prticas,
Polticas e procedimentos para garantir a adeso.
Os seguintes so exemplos de atributos necessrios em muitas das funes,

dependendo da organizao e da funo especfica:
Competncias de gesto - Quer a partir de uma perspectiva de gesto

de pessoas e para o controlo global de processo
Habilidades de reunio - Organizar, documento cadeira, e garantir as
aes so acompanhadas
Comunicaes - Um elemento importante de todas as funes a
sensibilizao dos processos para garantir o buy-in e conformidade. A
capacidade de comunicar em todos os nveis dentro da organizao ser
imperativo
Articular - Tanto escrita, por relatrios, etc, e verbal
Negociao - Necessrio para vrios aspectos, tais como a aquisio e
contratos
Analtico - Analisar mtricos produzidos a partir da actividade.
Mais informaes sobre as habilidades e competncias desses papis pode ser

encontrada no mbito do Quadro de Competncias para a Informao Idade
(SFIA - www.sfia.org.uk).
347 de 477
6,4 Funes e responsabilidades

O documento seces seguintes da papis e responsabilidades dos vrios
papis dentro Design de Servios. Em alguns organizaos pode ser um
indivduo em tempo integral e nos outros pode ser vrias pessoas, ou pode ser
um papel de meio perodo. Em organizaes menores muitas destas funes
podem ser desempenhadas por uma nica pessoa. Isso vai depender do
tamanho e da volatilidade da organizao. As funes ou cargos geralmente
variam entre organizaes. No entanto, o que importante que os papis,
responsabilidades, processos, dependncias e interfaces so claramente
definidos e escopod para cada organizao. (Veja o Apndice C para um
modelo de documento exemplo processo.)
A seguir, so ilustraes das principais atividades dentro de cada uma das
funes de design de servio.
6.4.1 Processo de proprietrio

Aproprietrio do processo responsvel por assegurar que o seu processo est
sendo realizado de acordo com o processo acordado e documentado e est a
cumprir os objectivos da definio do processo. Isso inclui tarefas tais como:
Documentar e divulgar o processo de

Definindo o Key Performance Indicators (KPI) para avaliar a eficcia e
eficincia do processo
Revendo KPIs e tomar medidas necessrias aps a anlise
Ajudar com e ser o responsvel pelo projeto do processo
Melhorar a eficcia e eficincia do processo de
Anlise de todas as melhorias propostas para o processo
Fornecendo a entrada para o curso Plano de Melhoria de Servio
Enfrentar os problemas com o funcionamento do processo de
Assegurar todo o pessoal relevante tem a formao exigida no processo e
esto conscientes de sua papel no processo
Garante que os processos, funes, responsabilidades e documentao
so regularmente revisados e auditados
Interfaces com a gesto da linha, garantindo que o processo recebe os
recursos humanos necessrios. (Gesto da linha e proprietrio do
processos tm tarefas complementares - eles precisam trabalhar juntos
para garantir que os processos eficientes e eficazes. Muitas vezes a
tarefa de gesto de linha para garantir a formao necessria do
pessoal.)
6.4.2 Gerente de Service Design

O papel-chave e responsabilidades do Gerente de Service Design so cobertos
ao longo desta publicao e so responsveis pela coordenao geral e
348 de 477
desenvolvimento de projetos de qualidade de solues para servios e

processos. Responsabilidades do papel alm e acima das de gerenciamento de
linha de todas as pessoas envolvidas em papis de design de servios incluem:
Tomando as Estratgias de servio global e assegurar que eles so

refletidos no Design de Servios prtica e os projetos de servio que so
produzidos para atender e satisfazer os requisitos de negcios
documentados
Projetando os aspectos funcionais dos servios, bem como a infraestrutura, ambiente aplicaes e gerenciamento de dados
Produtor qualidade, Desenhos de seguro e resiliente para servios novos
ou melhorados, arquitetura tecnolgica, processos ou sistemas de
medio que satisfaam todos os acordadas atuais e futuros requisitos de
TI da organizao
Produo e manuteno de toda a documentao do projeto, incluindo
desenhos, planos, arquiteturae as polticas
Produo e manuteno de todos os SDPs necessrias
Medindo o eficcia e eficincia do Design de Servios processo.
6.4.3 Planner TI
Um planejador de TI responsvel pela produo e coordenao de planos de
TI. Os principais objectivos do papel so os seguintes:
Desenvolver planos de TI que se encontram e continuam a cumprir os

requisitos de TI da empresa.
Coordenar, avaliar e rever o progresso da implementao de todas as
estratgias de TI e planos.
Produzir e manter o conjunto global de TI normas, polticas, planos e
estratgias, abrangendo todos os aspectos de TI necessrios para
suportar o negcio de uma organizao estratgia. TI planejamento inclui
a participao na criao de SLAs e planejamento de todos os aspectos
de infra-estrutura - interna e externa, pblica ou privada, internet e
intranet - necessrias para garantir que o proviso de De servios de TIs
satisfaz negcio.
Assumir a responsabilidade por todos os aspectos de padres de TI,
poltica e implementao da estratgia de TI como um todo e para a
significativa projetos ou nova e importante estratgico aplicaes.
Recomendar polticas para o uso eficaz de TI em todo o organizao e
trabalhar com TI Designers para garantir que os planos e estratgias
gerais so desenvolvidas em conjunto com TI projeto para todas as reas
de TI.
Comente TI custars contra oramentos e novos desenvolvimentos, novas
propostas para alter-la iniciando planos e estratgias quando
necessrio, em conjunto com Gesto Financeira.
349 de 477
Assumir a responsabilidade total para o planejamento, gesto e

coordenao de sistemas de TI e servios, incluindo a investigao,
anlise, especificao, Design, desenvolvimento, Testes, manuteno de
atualizao, transio e operao. essencial que durante a realizao
dessas actividades, a negcio, Gesto de TI e todos os Servio de
Gesto de processos so mantidos atualizados com o andamento dos
projetos.
Obter e avaliar propostas de fornecedors de equipamentos, servios de
software, transmisso e outros servios, assegurando que todos os
requisitos de negcio e de TI esto satisfeitos.
Identificar internos e externos que influenciam fatores necessidades
futuras, previso e definir planos para o uso eficaz da TI dentro da
organizao.
Patrocinar e monitorar a pesquisa, desenvolvimento e planejamento de
longo prazo para o profissionalviso e uso de arquiteturas de TI, produtos
e servios
Comente TI atuao com todas as outras reas e iniciar as melhorias na
organizao para garantir que nvel de servios e as metas continuam a
ser respeitados em todas as reas.
Assumir a responsabilidade final para priorizar e programar a
implementao de servios novos ou alterados dentro de TI.
Trabalhar com a administrao snior e outros especialistas seniores e
planejadores na elaborao de planos e tomar decises de contratao
pblica aplicveis a todas as reas de TI.
Reconhecer os drivers de negcio principais e as reas de necessidade
de negcio que no so devidamente apoiados por atuais e planejadas
servios de TI, desenvolvimento de planos de TI e resposta s
necessidades do negcio.
Identificar adequado aplicaos, servios e produtos, em conjunto com os
seus ambientes, para atender as necessidades do negcio dentro do
prazo exigido. planejamento
Desenvolver os planos iniciais para a implementao de novos
autorizados servios de TI, aplicaes e infra-estrutura de apoio,
identificando restries oramentais, tcnicos e de pessoal e custos
claramente anncio e os benefcios esperados.
Monitorar o existente planos de TI em relao s necessidades de
negcio e de TI estratgia para determinar oportunidades de melhoria
processo de negcioes por meio do uso de novas tecnologias, e
identificar os riscos imprevistos para a realizao do benefcio do negcio
de previso.
Investigue principais opes para a prestao de De servios de TIs
forma eficaz e eficiente e recomendar solues inovadoras, com base em
novas abordagens para processoes, proviso, Recrutamento e reteno,
e oferta global contratos.
Produzir estudos de viabilidade de negcios, modelos, modelos de TI,
caso de negcios, Sors e ITTs para recomendadas novos sistemas de TI,
350 de 477
identificando o negcio impacto, A probabilidade de satisfazer as

necessidades do negcio, os benefcios esperados de negcios e os
riscos e conseqncias de falha.
Supervisionar e coordenar o programa de implementaes de TI
planejadas do projeto e mudars, tomar as medidas adequadas para
identificar e superar problemas e resolver conflitos.
Realizar revises ps-implementao (PIRs) em conjunto com a Gesto
de Mudana desses sistemas de informao utilizados na prossecuo
dos planos, para avaliar at que ponto os benefcios comerciais
esperados foram realizados.
A ligao com Estratgia,Transio e Operaes de equipes e processos
para planejar as suas necessidades imediatas e futuras.
Prestar assessoria e orientao sobre autoritrio nacionais e
internacionais relevantes normas, regulamentos, protocolos e tarifas.
Documentar todo o trabalho usando padres exigidos, mtodos e
ferramentas.
Garantir que todos os processos de planejamento de TI, papels,
responsabilidades e documentao so regularmente revisados e
auditados por eficincia,eficcia e observncia.
Manter um bom conhecimento geral de todos os recursos de produtos de
TI e os quadros tcnicos em que eles operar.
Caso seja necessrio, avaliar mudars para a sua conformidade com as
estratgias de projeto, incluindo a participao em reunies de cabina, se
apropriado.
6.4.4 TI Designer / Arquiteto

Um Designer de TI / Arquiteto responsvel pela coordenao geral e projeto
da tecnologia necessria. Muitas vezes, os designers e arquitetos dentro de
grandes organizaes que se especializam em um dos cinco aspectos do
projeto (ver seo 3). No entanto, uma abordagem integrada do projeto deve
sempre ser adotado, portanto, Designers e Arquitetos precisam trabalhar juntos
dentro de um mtodo formal e estrutura para garantir projetos consistentes e
compatveis so produzidos. Em organizaes menores, alguns ou todos os
papels geralmente so combinados, e este um problema menor, embora uma
abordagem formal ainda deve ser usada. Sempre que os projetos so
produzidos, eles devem sempre adotar uma abordagem integrada, que abranja
todas as reas, e deve ser aceito e assinado por todas as reas. Todos os
designers precisam entender como arquiteturas, estratgias, projetos e planos
se encaixam e todos os principais aspectos do projeto.
Designer / Arquiteto deve produzir um mapa detalhado processo que documenta
todos os processos e suas interfaces de alto nvel. Isso garante que a estrutura
global no desnecessariamente complexa, que interfaces centrais do processo
fazem parte do desenho, e apresenta um resumo de todos na forma como o
cliente e todos os outros das partes interessadass interagir com os processos.
351 de 477
Para desempenhar o papel de designer ou arquiteto, necessrio para a equipe

ter um bom conhecimento e experincia prtica de filosofias de design e
planejamento, incluindo Projeto de Programa, e Servio de Gesto de, Mtodos
e princpios. O principal objetivos do Designer IT / Architect so os seguintes:
Produzir e analisar os projetos de todos os servios novos ou alterados,

SLAs, Olas e contratos.
Produzir um mapa de processo de todos os processos e as suas
interfaces de alto nvel, para garantir a consistncia, integrao e
continuidade atravs de todos os processos.
Projetar arquiteturas de tecnologias seguras e resistentes que atendem
todo o futuro atual e previsto requisitos de TI da organizao.
Garantir que o projeto de todos os processos, papis, Responsabilidades
e documentao so regularmente analisados e auditados para a
eficcia, eficincia e conformidade.
Projetar um e adequado Portflio de Servios, Suportando todas as
atividades dentro do Ciclo de Vida do Servio completo.
Projeto de sistemas de medio e tcnicas para apoio melhoria
contnua do servio proviso e todos os processos de apoio.
Produzir e manter-se atualizado todo o projeto de TI, arquitetura, poltica
e especificao documentao.
Produzir e manter todos os aspectos da TI especificao, incluindo os
projetos globais, arquiteturas, topologias e configuraes de infraestrutura, ambiente,aplicaos e dados, bem como a documentao de
design de todos os sistemas de TI. Isto deve incluir no apenas a
tecnologia, mas tambm o sistema de gestos, processos, fluxos de
informao e servios externos.
Recomendar proativas e inovadoras solues de TI para a melhoria do
design e TI operao quando e onde for possvel.
Traduzir projetos lgicos em projetos fsicos, tendo em conta os requisitos
de negcios, ambientes-alvo, processos, atuao requisitos, sistemas e
servios existentes, e quaisquer potenciais relacionados com a segurana
aspectos.
Criar e manter polticas de TI do projeto, filosofias e critrios, que
abrangem todas as reas, incluindo conectividade, capacidade,
Interfaces, segurana, Resilincia, recuperao, Acesso e acesso remoto,
e garantir que todos os novos servios satisfazer as suas nvel de
servios e metas.
Trabalhar com Gerenciamento da Capacidade e rever os volumes de
trfego e requisitos de TI, identificao de tendncias nos fluxos de
trfego e nveis de servio.
Propor melhorias de projeto Infra-estrutura de TI, Mudanas de
capacidade, continuidade, apoio e recuperao, conforme necessrio, e
estar ciente de operacional requisitos, especialmente em termos de nveis
de servio, disponibilidade,tempo de respostas, segurana e reparar
352 de 477
vezes. Todas essas atividades so realizadas em articulao com todos

os Servio de Gesto de processos.
Comente TI custars contra prestador de servios externos, novidades e
novos servios, propostas para mudar de TI iniciam projeto onde as
redues de custos adequadas e benefcios podem ser alcanados, em
consulta com Gesto Financeira.
Fornecer aconselhamento e orientao para a gesto da projeto e
planejamento fases de sistemas de TI, para garantir que os requisitos
(nomeadamente a capacidade, a recuperao, desempenho e segurana
necessidades) so refletidas no geral especificaos.
Fornecer aconselhamento e orientao a todas as reas de TI e gesto
de negcios, analistas, planejadores, projetistas e desenvolvedores de
todos os aspectos de TI de design e tecnologia.
Interface com os desenhistas e projetistas de externa fornecedors e
provedor de servioss, garantindo todos externo De servios de TIs so
projetados para atender a sua concordou nvel de servios e metas.
Desempenhar um importante papel na seleo de qualquer infra-estrutura
de TI novo ou solues de tecnologia.
Assumir a responsabilidade tcnica de TI padres poltica, e design para
todos significativos projetos ou principais reas de aplicao, ajudando
com a avaliao de impacto e avaliao de grandes novas opes de
design de TI.
Prestar assessoria tcnica e orientao sobre nacionais e internacionais
relevantes normas, regulamentos, protocolos e tarifas.
Assumir total responsabilidade pelos aspectos de design de todas as
fases do ciclo de vida de sistemas de TI, incluindo a investigao, anlise,
especificao, Projeto, desenvolvimento, construo, testes, manuteno
de atualizao, transio, Operao e melhoria.
Trabalhar com TI colegas quando necessrio, produzindo ou atualizao
de TI e documentao de projeto corporativo e modelos.
Atualizar ou fornecer informaes para anlises custo-benefcio, anlises
de risco, casos de negcios, Sors e ITTs e planos de desenvolvimento,
para ter em conta as decises de design.
Obter e ajudar com a avaliao e seleco de propostas e solues de
fornecedors de equipamentos, softwares e outros servios de TI e
fornecedores de produtos.
Construir, interpretar e monitorar o teste planos para verificar correta
operao de sistemas completos contra seus objetivos de projeto.
Documentar todo o trabalho usando padres exigidos, mtodos e
ferramentas.
Manter um bom conhecimento tcnico de todos os recursos de produtos
de TI e os quadros tcnicos em que eles operar.
Caso seja necessrio, avaliar mudars para a sua conformidade com os
princpios de design, incluindo a participao em reunies CAB se for o
caso.
353 de 477
Nota: Muitas vezes os designers e arquitetos dentro de grandes organizaes

que se especializam em um dos cinco aspectos do projeto (ver sees 3 e 4
para mais detalhes). No entanto, uma abordagem integrada do projeto deve
sempre ser adotado, portanto, Designers e Arquitetos precisam trabalhar juntos
dentro de um mtodo formal e estrutura para garantir projetos consistentes e
compatveis so produzidos. Em organizaes menores, alguns ou todos os
papels geralmente so combinados, e este um problema menor, embora uma
abordagem formal ainda deve ser usada. Sempre que os projetos so
produzidos, eles devem sempre adotar uma abordagem holstica, abrangendo
todas as reas, e deve ser aceito e assinado por todas as reas. Todos os
designers precisam entender como arquiteturas, estratgias, projetos e planos
se encaixam.
6.4.5 Gerente de Catlogo de Servio

O Catlogo de Servios Gestor tem a responsabilidade de produzir e manter o
Catlogo de Servios. Isto inclui responsabilidades tais como:
Garantir que todos operacional servios e todos os servios que esto

sendo preparados para a gesto operacional so registrados dentro do
Catlogo de Servio
Assegurar que todas as informaes dentro do Catlogo de Servio
preciso e up-to-date
Assegurar que todas as informaes dentro do Catlogo de Servio
consistente com a informao dentro do Portflio de Servios
Assegurar que a informao dentro do Catlogo de Servio est
devidamente protegido e apoiado.
6.4.6 Gerente de Nvel de Servio

O Gerente de Nvel de Servio tem a responsabilidade de garantir que os
objectivos da Gerenciamento de Nvel de Servio so atendidas. Isto inclui
responsabilidades tais como:
Mantendo consciente de novas necessidades de negcio

Garantir que o atual e futuro servio requisitos clientes so identificados,
entendido e documentado em SLA e documentos SLR
Negociar e concordar nveis de servio a ser entregues com o cliente
(interno ou externo); formalmente documentar esses nveis de servio,
SLAs
Negociar e concordar OLAs e, em alguns casos, outros SLAs e os
acordos que sustentam os SLAs com os clientes do servio
Ajudar na produo e manuteno de um preciso Portflio de
Servios,Catlogo de Servios,Application Portfolio e a manuteno
correspondente procedimentos
354 de 477
Garantir que as metas acordadas no mbito subjacente contratos esto

alinhados com SLA e metas SLR
Assegurar que os relatrios de servios so produzidos para cada servio
ao cliente e que as violaes de SLA alvos so destaque, investigado e
as medidas tomadas para prevenir sua repetio
A garantia de que o servio atuao opinies esto programadas,
realizadas com clientes regularmente e so documentados com aes
acordadas progrediu
Assegurar que as iniciativas de melhoria identificadas no servio de
opinies so aproveitados e os relatrios de progresso so fornecidas aos
clientes
Revendo servio escopo, SLA, OLA e outros acordos em uma base
regular, de preferncia pelo menos anualmente
Garantir que todos mudars so avaliados quanto sua impacto em nvel
de servios, incluindo SLAs, e OLAs subjacente contratoassiduidade,
inclusive em reunies CAB se for o caso
Identificar todas as principais das partes interessadass e clientes
Em desenvolvimento relaos e comunicao com as partes
interessadas, os clientes e os principais usurios
A definio e adopo de queixas e sua gravao, gesto, escalada, Se
necessrio, e resoluo
Gravao em definio e comunicao de todas as reclamaes
Medir, registrar, analisar e melhorar a satisfao do cliente.
6.4.7 Availability Manager

Um Gerente de Disponibilidade tem a responsabilidade de garantir que os
objectivos da Gerenciamento de Disponibilidade so atendidas. Isto inclui
Assegurar que todos os servios existentes entregar os nveis de

disponibilidade acordado com o negcio em SLAs
Assegurar que todos os novos servios so projetados para oferecer os
nveis de disponibilidade exigidos pelo negcio, e validao do projeto
final para atender os nveis mnimos de disponibilidade, conforme
acordado pela empresa para De servios de TIs
Ajudar na investigao e diagnstico de todos os incidentes e problemas
que causam problemas de disponibilidade ou indisponibilidade de
servios ou componentes
Participar da Infra-estrutura de TI projeto, incluindo a especificao dos
requisitos de disponibilidade de hardware e software
Especificando os requisitos para novos ou aprimorados gesto de
eventos para sistemas automticos monitoramento de disponibilidade de
TI componentes
Especificando o confiana,manuteno e manuteno requisitos para
componentes fornecidos pelo interno e externo fornecedors
355 de 477
Ser responsvel por monitorar a disponibilidade de TI real alcanado em

relao s metas de SLA, e oferecendo uma gama de TI relatrios
disponibilidade para assegurar que concordou nveis de confiabilidade,
disponibilidade e facilidade de manuteno so medidos e monitorados
em uma base contnua
Proativamente melhorar a disponibilidade do servio, sempre que
possvel, e otimizando a disponibilidade da infra-estrutura de TI para
entregar custo-efetivas melhorias que proporcionam benefcios tangveis
para o negcio
Criar, manter e rever regularmente um AMIS e uma viso de futuro Plano
de disponibilidade, Que visa melhorar a disponibilidade global de servios
de TI e infra-estrutura componentes, para garantir que os requisitos de
disponibilidade existentes e futuros negcios podem ser atendidas
Assegurar que o Gerenciamento de Disponibilidade processo, suas
tcnicas e mtodos associados so regularmente revisados e auditados,
e que todos estes esto sujeitos melhoria contnua e permanecem apto
para o efeito
Criando disponibilidade e recuperao critrios de desenho a ser aplicado
a nova infra-estrutura ou desenho melhorado
Trabalhando com Gesto Financeira, Garantindo os nveis de
disponibilidade exigido TI so custo-justificado
Manuteno e preenchimento de um cronograma de testes a
disponibilidade de mecanismos de disponibilidade
Garantir que todos os testes disponibilidade e planos so testados aps
cada mudana grande negcio
Assistir Segurana e Gerenciamento da Continuidade do Servio com a
avaliao e gesto de risco
Avaliando mudars para a sua impacto sobre todos os aspectos de
disponibilidade, incluindo a disponibilidade geral do servio e do Plano de
Disponibilidade
Participar de reunies do CAB, quando apropriado.
6.4.8 Gestor de Continuidade de Servios de TI

O Gerente de Continuidade de Servios de TI responsvel por garantir que os
objectivos de TI Gesto da Continuidade do Servio so atendidas. Isso inclui
tarefas e responsabilidades tais como:
Realizar anlises de impacto de negcios para todos os servios

existentes e novos
Implementao e manuteno do ITSCM processo, Em conformidade
com os requisitos globais do da organizao Gesto de Continuidade de
Negcios processo, e representando os servios de TI funo dentro do
processo de Gesto de Continuidade de Negcios
Garantir que todos os planos ITSCM, riscos e atividades de sustentar e
alinhar com todos os planos de GCN, riscos e atividades, e so capazes
356 de 477
de cumprir as metas acordadas e documentadas em qualquer

circunstncia
Executando avaliao de risco e gesto de risco de preveno de
desastres, onde o custo-justificvel e sempre que possvel
Desenvolvimento e manuteno do organizao'S continuidade estratgia
Avaliar o potencial servio questes de continuidade e invocando o Plano
de Continuidade do Servio, se necessrio
Gerenciando o Plano de Continuidade de Servio enquanto ele estiver em
operao, incluindo failover para um local secundrio e restaurao para
o local principal
Realizar revises post mortem de testes de servios de continuidade e
invocaes, e instigar aes corretivas quando necessrio
Desenvolvimento e gesto da ITSCM planos para garantir que, em todos
os momentos, a recuperao objetivos da negcio pode ser conseguida
Garantir que todas as reas de servios de TI so preparados e capazes
de responder a uma invocao dos planos de continuidade
A manuteno de um cronograma de testes abrangentes de TI, incluindo
testar todos os planos de continuidade, de acordo com os requisitos de
negcios e depois de cada mudana grande negcio
Proceder a revises de qualidade de todos os procedimentos e assegurar
que estes so incorporados no programa de testes
Comunicar e manter a conscincia dos objectivos ITSCM dentro das
reas de negcio e reas de suporte de servios de TI
Proceder a revises regulares, pelo menos anualmente, da Continuidade
planos com as reas de negcio para garantir que refletem com preciso
as necessidades do negcio
Negociao e gesto contratos com fornecedores de terceiros
recuperao servios
Avaliando mudars por seu impacto sobre Continuidade de Servio e
Planos de Continuidade
Participar de reunies do CAB, quando apropriado.
6.4.9 Capacity Manager

A Capacity Manager tem a responsabilidade de garantir que os objectivos da
Gerenciamento da Capacidade so atendidas. Isso inclui tarefas tais como:
Garantindo que no adequada TI capacidade para atender aos nveis

exigidos de servioE que a gesto de TI snior est corretamente
informado sobre como combinar a capacidade ea demanda e para
garantir que o uso da capacidade existente otimizard
Identificar, com o Gerente de Nvel de Servio, os requisitos de
capacidade atravs de discusses com o negcio usurios
Compreender o uso atual da infra-estrutura e servios de TI, ea
capacidade mxima de cada componente
357 de 477
Realizando dimensionamento em todos os servios propostos e novos

sistemas, possivelmente usando modelagem tcnicas, requisitos de
capacidade para averiguar
Previso das necessidades futuras de capacidade com base em planos
de negcios, tendncias de uso, dimensionamento de novos servios, etc
Anlise de produo, regular e reviso do Plano de capacidade, Em linha
com o negcio da organizao planejamento ciclo, identificar o uso atual
e as necessidades previsveis durante o perodo coberto pelo plano
Garantir que os nveis adequados de monitoramento de recursos e
sistema atuao so definidos
Anlise de dados de uso e desempenho, e elaborao de relatrios sobre
o desempenho em relao s metas contidas no SLAs
Aumentar incidentes e problema quando as violaes de capacidade ou
desempenho limiars so detectados, e ajudar com a investigao e
diagnstico da capacidade de incidentes relacionados e problemas
Identificao e de iniciar qualquer afinao a efectuar a optimizar e
melhorar a capacidade ou o desempenho
Identificar e implementar iniciativas para melhorar o uso de recursos - por
exemplo, gesto da procura tcnicas
Avaliar novas tecnologias e sua relevncia para o organizao em termos
de desempenho e custar
Estar familiarizado com a demanda futura potencial de servios de TI e
avaliando este desempenho em nvel de servios
Garantir que todos mudars so avaliados quanto sua impacto na
capacidade e desempenho e reunies CAB presentes quando apropriado
Produzir relatrios regulares de gesto que incluem o uso atual de
recursos, tendncias e previses
Dimensionamento de todos os servios propostos e novos sistemas para
determinar os recursos do computador e rede necessrios, para
determinar a utilizao de hardware de desempenho, nvel de servios e
implicaes de custo
Avaliar novas tcnicas e produtos de hardware e software para uso pelo
Gerenciamento da Capacidade que pode melhorar a eficincia e eficcia
do processo
O teste de desempenho de novos servios e sistemas
Relatrios sobre servio e componente desempenho em relao s metas
contidas no SLAs
A manuteno de um conhecimento da demanda futura de servios de TI
e prever os efeitos da demanda sobre os nveis de desempenho
Determinar o desempenho nvel de servios que so de fcil manuteno
e custo-justificado
Recomendando afinao de servios e sistemas, e fazer recomendaes
para a gesto de TI na projeto e utilizao de sistemas para ajudar a
garantir uma utilizao ptima de todos os recursos de hardware e
software de sistema operacional
Atuando como um ponto focal para todos capacidade e atuao questes.
358 de 477
6.4.10 Security Manager

O Gerente de Segurana responsvel por garantir que os objectivos da Gesto
de Segurana da Informao so atendidas. Isso inclui tarefas e
Desenvolvimento e manuteno do Poltica de Segurana da Informao

e um conjunto de polticas especficas de apoio, garantindo a devida
autorizao, empenho e apoio da gerncia snior de TI e de negcios
Comunicao e divulgao da Poltica de Segurana da Informao a
todas as partes apropriadas
Garantir que a Poltica de Segurana da Informao aplicada e
respeitada
Identificao e classificao de TI e informaes ativoss (Item de
Configuraos) e do nvel de controlar e proteco exigido
Ajudar com anlises de impacto nos negcios
Execuo de Anlise de Risco de Segurana e gesto de risco em
conjunto com disponibilidade e Gerenciamento da Continuidade do
Servio
Desenho segurana controles e planos de segurana em
desenvolvimento
Desenvolver e documentar procedimentos para a operao e manuteno
dos controles de segurana
Monitoramento e gerenciamento de todas as violaes de segurana e
tratar incidentes de segurana, tomando aes corretivas para evitar a
recorrncia, sempre que possvel
Relatar, analisar e reduzindo o impacto e volumes de todos os incidentes
de segurana em conjunto com Gerenciamento de Problemas
Promoo da educao e conscientizao de segurana
A manuteno de um conjunto de controles de segurana e de
documentao, e rever regularmente e auditoria todos os controles e
procedimentos de segurana
Assegurar todas as alteraes so avaliados para o impacto em todos os
aspectos de segurana, incluindo a Poltica de Segurana da Informao
e controles de segurana, e participao em reunies CAB quando
apropriado
Realizao de testes de segurana
Participar em quaisquer revises de segurana decorrentes de violaes
de segurana e instigar aes corretivas
Assegurar que o confidencialidade,integridade e disponibilidade dos
servios so mantidos os nveis acordados no SLAs e que estejam em
conformidade com todos os requisitos legais aplicveis
Garantir que todo o acesso a servios de parceiros e fornecedores
externos est sujeita a acordos contratuais e responsabilidades
Atuando como um ponto focal para todos segurana questes.
359 de 477
6.4.11 Gerente de Fornecedor

O Gerente de fornecedor tem a responsabilidade de garantir que os objectivos
da Gesto de Fornecedores so atendidas. Isto inclui as tarefas, tais como:
Prestao de assistncia na desenvolvimento e reviso de SLAs,

contratos, acordos ou quaisquer outros documentos para fornecedores
terceiros
Garantir que valor para o dinheiro obtido a partir de todos os
fornecedores de TI e contratos
Garantir que todos os processos de TI so consistentes fornecedor e
interface para todas as estratgias de fornecedores de empresas,
processos e termos e condies padro
Manuteno e reviso de um Fornecedor e Contratos Banco de Dados
(SCD)
Reviso e Anlise de Risco de todos os fornecedores e contratos em uma
base regular
Garantir que qualquer subjacente contratos, acordos ou SLAs
desenvolvidos esto alinhados com os da negcio
Garantir que todos servios de apoios so escopo e documentada e que
as interfaces e dependncias entre fornecedores, servios de apoio e
processos de fornecedores esto acordadas e documentadas
Garantir que todos papels e relaos entre chumbo e quaisquer
fornecedores terceirizados esto documentadas, mantidas e sujeita ao
acordo contratual
Reviso de processos fornecedores de chumbo "para garantir que todos
os fornecedores terceirizados esto cumprindo suas obrigaes
contratuais
Realizar revises contratuais ou SLA pelo menos anualmente, e garantir
que todos contratos so consistentes com os requisitos organizacionais e
termos e condies padro, sempre que possvel
Atualizando contratos ou SLAs, quando necessrio, garantindo que o
processo de Gerenciamento de Mudana seguido
A manuteno de um processo para lidar com disputas contratuais, e
garantir que todos os litgios so tratados de uma maneira eficiente e
eficaz
A manuteno de um processo para lidar com o fim esperado, fim
precoce ou transferncia de um servio
Comunicao, monitoramento e reviso regular fornecedor atuao
contra alvos, identificando aes de melhoria conforme o caso e garantir
que estas aes so implementadas
Garantir mudars so avaliados quanto sua impacto em fornecedores,
servios de apoio e contratos e reunies CAB presentes quando
apropriado
360 de 477
Coordenar e apoiar todo indivduo de TI fornecedor e gestores de

contrato, garantindo que cada fornecedor / contrato tem um proprietrio
designado no provedor de servios organizao.
361 de 477
7 consideraes de tecnologia
geralmente reconhecido que o uso de Servio de Gesto de ferramentas
essencial para o sucesso de todo o processo, mas as implementaes mais
pequenas muito. No entanto, importante que a ferramenta de suporte a ser
utilizado o processoes - e no o contrrio. Como regra geral, no modificam os
processos para ajustar a ferramenta. No entanto, com o uso de ferramentas para
apoiar os processos, existe uma necessidade de ser pragmticos e reconhecer
que pode no haver uma ferramenta que suporta o processo desenvolvido
totalmente, de modo que um elemento de um processo de re-concepo pode
ser necessrio. No limitar os requisitos de funcionalidade: considerar a
capacidade do produto de executar, ampliar o tamanho das bases de dados,
recuperao de falha e manter a integridade dos dados. Ser que o produto em
conformidade com as normas internacionais? eficiente o suficiente para que
voc possa atender s suas necessidades de Gerenciamento de Servio?
Muitas vezes, as organizaes acreditam que atravs da compra ou o
desenvolvimento de uma ferramenta de todos os seus problemas sero
resolvidos, e fcil esquecer que ainda estamos dependentes do processo, o
funo e, mais importante, as pessoas. Lembre-se:
"Um tolo com uma ferramenta ainda um tolo"
362 de 477
7,1 projeto Ferramentas de servio

Existem muitas ferramentas e tcnicas que podem ser usadas para ajudar na
projeto de servios e de seus associados componentes. Estas ferramentas e
tcnicas permitem:
Design de hardware
Design de software
Projeto ambiental
Projeto de processos
Design de dados.
As ferramentas e tcnicas so muitas e variadas, incluindo tanto o proprietrio e

no-proprietrio, e so teis em:
Acelerar o processo de design

Garantir que as normas e convenes so seguidas
Oferecendo prototipagem, modelagem e instalaes de simulao
Habilitando 'E se?' Cenrios a serem analisados
Interfaces de Habilitao e dependncias para verificar e correlacionados
Validar projetos antes que eles sejam desenvolvidos e implementados
para garantir que eles satisfazer e cumprir os seus requisitos pretendidos.
Em desenvolvimento Design de Servioss pode ser facilitada pela utilizao de

ferramentas que fornecem vistas grficas do servio e dos seus componentes
constituintes, a partir do processo de negcioes, atravs do servio e SLA
infra-estrutura, ambiente, Dados e aplicaos, processoes, Olas, equipes,
contratos e fornecedors. Alguns Gerenciamento da Configurao ferramentas
fornecem tais instalaes, e so por vezes referido como um elemento de
Business Service Management (BSM) ferramentas. Eles podem conter ou ser
ligada a ferramentas de "auto-descoberta" e mecanismos e permitir que as
relaes entre todos esses elementos a serem representados graficamente,
fornecendo a capacidade de drill down dentro de cada componente e obter
informaes detalhadas, se necessrio.
Se este tipo de ferramenta tambm conter informao financeira, e so ento
ligados ao KPIs fornecem uma "rvore Mtricas 'e mtricos dos vrios aspectos
do servio, o servio pode ser monitorado e controlado atravs de todas as
fases da sua ciclo de vida. Compartilhar este conjunto nico e centralizado de
informaes sobre o servio permite que todos na provedor de servios
organizao e do negcio para acessar uma viso nica, consistente, "mundo
real" do servio e seu desempenho, e fornece uma base slida para o
desenvolvimento de boas relaes e parcerias entre o prestador de servio e
seu clientes.
363 de 477
Estes tipos de ferramentas no s facilitar os processos de design, mas tambm

muito apoiar e ajudar todos os estgios no ciclo de vida do servio, incluindo:
Gesto de todas as fases do ciclo de vida de servio

Todos os aspectos do servio e de suas atuao
Realizao de servios, SLA, OLA, contratual e fornecedor relatrios,
medio e gesto
Mtricas consolidadas e rvores mtricas, com pontos de vista de gesto
painel de instrumentoss at detalhada desempenho dos componentes,
informaes e culpa anlise e identificao
Visualizaes consistentes e consolidadas em todos os processos,
sistemas, tecnologias e grupos
Relaes e integrao do negcio e seus processos com De servios de
TIs, sistemas e processos
Um conjunto abrangente de recursos de pesquisa e relatrios, permitindo
que informaes precisas e anlise para tomada de deciso informada
Gesto de servio custars
Gesto de relaos, interfaces e inter-dependncias
Gesto do Portflio de Servios e Catlogo de Servios
A Sistema de Gerenciamento da Configurao (CMS)
Um Sistema de Gerenciamento do Conhecimento (SKMS).
As seguintes atividades genricos sero necessrios para implementar essa

abordagem:
Estabelecer o genrico ciclo de vida para ativos de TI (Requisitos, Projeto

e desenvolver, Construir, Testar, implantar Operar e Otimizar, Dispose) e
definir o principal processoes, polticas, atividades e tecnologias em cada
fase do ciclo de vida para cada tipo de ativo
Formalizar as relaes entre os diferentes tipos de TI ativos, Ea relao
entre TI e gesto de aquisio de ativos e de outras disciplinas de TI
Definir todos os papis e as responsabilidades envolvidas em atividades
de TI de ativos
Estabelecer medidas para a compreenso do Custo (total) de
propriedade de um servio de TI
Estabelecer polticas para a reutilizao de ativos de TI atravs de
servios, por exemplo, em nvel corporativo
Definir um estratgia para a aquisio e gesto de ativos de TI, incluindo
a forma como deve ser alinhado com a TI e outras estratgias de negcio.
Para o tipo de ativo aplicaes, adicionalmente:
Definir um estratgia para a aquisio e gesto de TI ativoss, incluindo

como ele deve estar alinhado com a TI e outras estratgias de negcios
364 de 477
Documentar o papel desempenhado pela aplicaos na entrega de De

servios de TIs para o negcio
Verifique se o ciclo de vida de ativos de TI genrico modelo adaptada a
um ciclo de vida de aplicaes, adaptados para diferentes tipos de
aplicao
Estabelecer normas para o uso de diferentes abordagens para o
desenvolvimento de aplicaos, e reconhecer o papel das metodologias
de desenvolvimento, incluindo os baseados em 'reutilizao' (ver a seo
sobre Design e Desenvolvimento para discusso)
Certifique-se que procedimentos esto no local para considerar todos os
tipos de requisitos (como servio de operacionalidade,
atuao,manuteno,segurana) Nas fases iniciais de desenvolvimento
da aplicao
Definir normas para decidir sobre a entrega ideal de aplicaos para o
organizao, Tais como o uso de Provedores de Servios de Aplicao,
Desenvolvimentos personalizados, COTS e personalizao do pacote.
Para o tipo de ativo de dados / informaes, adicionalmente:
Estabelecer como os princpios gerais de TI e gesto de aquisio de

ativos pode ajudar a gerenciar os dados / informaes recursos de uma
organizao.
Garantir que os projetos de dados so realizados luz de:
A importncia dos metadados padronizados e reutilizveis

A necessidade de qualidade de dados
O valor dos dados para uma organizao
A necessidade de administrao de dados e habilidades de
administrao de banco de dados
Compreender o 'corporate (ou comum / cooperativa) rea de assunto e
individual servio ("Sistema") exibies de dados
A necessidade de gerenciar dados de tipos de dados no tradicionais, tais
como texto, imagens digitalizadas, vdeo e udio
A conscincia do armazenamento principal, segurana e questes legais
para dados
Especificar como o modelo de ciclo de vida genrico ativos de TI pode ser
adaptado para o tipo de ativo de dados.
Para o Infra-estrutura de TI e tipo de ativo ambiental, adicionalmente:
Estabelecer normas para aquisio e gesto do equipamento de infraestrutura de TI e ambientais (incluindo hardware, software poder, O / S,
dbms software, middleware e redes), e garantir que eles fornecem uma
365 de 477
base estvel ainda adaptvel que sustenta o prviso de servios de TI

para o negcio
Estabelecer como o ciclo de vida de ativos de TI genrico modelo deve
ser adaptado para um ciclo de vida de infra-estrutura de TI especficas
Estabelecer atividades para otimizar o uso da infraestrutura de TI ativoss
atravs da sua reutilizao
Especificar a necessidade de ferramentas e descrever como a sua
utilizao global e integrao auxilia na gesto de uma infra-estrutura de
TI eficaz e servios relacionados.
Para as habilidades, competncias (pessoas), adicionalmente:
Formalizar como as competncias dos indivduos responsveis pelos

ativos de TI e servios relacionados podem ser considerados como um
ativo dentro da organizao e so gerenciados como tal
Especificar como o ativo de TI ciclo de vida aplica-se a pessoas ativos,
particularmente em termos de competncias mensurveis, como a
habilidade, conhecimento, entendimento, qualificaes, experincia,
atitude e comportamento
Garantir a documentao das competncias actualmente em vigor e
especificar como estes podem ser reutilizados ou reforada
Garantir padres de organizao so compatveis com os actuais quadros
de competncia padro para o setor de TI, tais como SFIA + (habilidades
para a Era da Informao) aptides e competncias so incorporados em
papis e responsabilidades.
Alm disso, a fim de estabelecer interfaces eficazes e dependncias:
Definir as interfaces que a TI aquisio de ativos e gesto tem com ele

habilitado Mudana de Negcios, IT Project Gesto e TI Segurana
Formalizar as interfaces que a TI aquisio de ativos e gesto tem com
funes e processoes fora de TI
Finalmente formalizar medio e relatrio nesta rea:
o Identificao adequada mtricos e os relatrios sobre TI ativoss
para a distribuio em toda a organizao, conforme apropriado
o Formalizao de controle de qualidade e medio na aquisio e
gesto de ativos de TI.
366 de 477
7,2 Ferramentas de Gesto de Servio

Ferramentas ir permitir o Design de Servios processos para trabalhar de forma
mais eficaz. Ferramentas aumentar eficincia e eficciaE fornecer uma riqueza
de gesto da informao, Que conduz identificao de reas fracas. Os
benefcios a longo prazo a serem obtidos a partir do uso de ferramentas so
economias de custo e aumento de produtividade, o que por sua vez pode levar a
um aumento na qualidade do servio de TI prviso.
O uso de ferramentas permitir a centralizao de processos-chave e da
automao e integrao do ncleo Servio de Gesto de processos. Os dados
brutos recolhidos pelas ferramentas podem ser analisados, resultando na
identificao de "tendncias". Medidas preventivas podem ento ser aplicadas,
novamente a melhoria da qualidade do servio de TI prviso.
Alguns pontos que as organizaes devem considerar ao avaliar ferramentas de
gerenciamento de servios incluem:
Estrutura de dados, processamento de dados e de integrao

Integrao de multi-fornecedor de infra-estrutura componentes, e a
necessidade de se absorver novos componentes no futuro - estes
colocar exigncias particulares sobre a manipulao de dados e
modelagem capacidades da ferramenta
A conformidade com as normas internacionais abertas
Flexibilidade no compartilhamento de uso, implementao e dados
Usabilidade - A facilidade de uso permitido pela usurio interface
Suporte para monitoramento nvel de servios
Distribudo clientes com uma base de dados centralizada partilhada (por
exemplo, o cliente servidor)
Requisitos de converso de dados previamente rastreados
Dados apoio,controlar e segurana
As opes de suporte oferecido pelo fabricante da ferramenta de
Escalabilidade para o aumento da capacidade (o nmero de utilizadores,
o volume de dados e assim por diante).
Considerao deve ser dada aos requisitos exatos para a ferramenta. Quais so
os requisitos obrigatrios e quais so os requisitos desejados? Geralmente a
ferramenta deve apoiar os processos, e no o contrrio, para minimizar a
modificao dos processos para se adequar a ferramenta. Sempre que possvel,
melhor para comprar um instrumento totalmente integrado (embora no seja
custa da eficincia e eficcia) para apoiar a muitos (se no todos) Servio de
Gesto de processos. Se isto no for possvel, deve-se considerar que as
interfaces entre as diferentes ferramentas.
essencial ter um Declarao de Requisitos (SOR) para utilizao durante o
processo de seleco - este comando pode ser utilizado como uma "lista de
367 de 477
carrapato '. Os requisitos das ferramentas devem ser classificados usando o

MoSCoW anlise:
M - deve ter presente

S - devem ter este se possvel
C - poderia ter isso se ele no afeta qualquer outra coisa
W - no ter esse tempo, mas gostaria no futuro.
A ferramenta deve ser flexvel para suportar adequadamente o seu acesso

necessrio direitos. Voc deve ser capaz de determinar quem tem permisso
para acessar quais dados e com que finalidade, por exemplo, acesso de leitura
clientes.
Nos estgios iniciais, a considerao tambm deve ser dada para a plataforma
sobre a qual a ferramenta que se espera que operar - Isto pode ser em hardware
e software existentes ou uma nova compra. Pode haver restries impostas por
TI estratgia - Por exemplo, todos os novos produtos podem ter a residir em
especfico servidors. Isto pode restringir o qual os produtos podem ser includos
na avaliao processo. Certifique-se de que a aquisio se encaixa dentro
existente aprovado oramentos.
Existem ferramentas de Servio de Gesto muitos disponveis. Detalhes podem
ser encontrados na internet, Servio de Gesto de publicaes, de pedir outras
organizaes, de pedir consultores ou a participar de seminrios e conferncias
para ver quais os produtos que esto disponveis.
Durante os estgios iniciais do processo de seleo, pensar fornecedor e
credibilidade da ferramenta. Eles ainda esto indo para apoiar a compra em
alguns meses ou daqui a um ano? Considere o registro do passado fornecedor ,
bem como a da ferramenta. Telefone Service Desk do fornecedor para ver como
fcil de passar, e fazer algumas perguntas de teste para avaliar a sua
competncia tcnica. Pea ao vendedor para organizar uma visita a um site de
referncia para ver o que a experincia com a ferramenta na prtica - se
possvel sem o vendedor ou fornecedor atual. Certifique-se de que o
organizao tem requisitos semelhantes da ferramenta. Veja a ferramenta em
funcionamento e falar com os usurios sobre suas experincias, tanto
inicialmente e em curso.
Avaliar as necessidades de treinamento da organizao e avaliar a capacidade
do fornecedor para fornecer a formao adequada. Tambm a formao
contnua atualizao e ferramenta (upgrades e mudanas na usurio requisitos)
ter que ser avaliada para determinar o suporte e treinamento custars. Em
particular, considerar os custos de treinamento, local de treinamento, tempo
necessrio, como logo aps o treinamento da ferramenta estaro em uso, e
durante a implementao projeto assegurar que a formao suficiente
fornecido - pensar sobre como a nova ferramenta ter um impacto tanto de TI e
368 de 477
cliente. Tambm garantir que as interfaces com outras ferramentas e telefonia

esto funcionando corretamente. sbio para identificar se a combinao
planejada tem sido usado (ou tentou) em outro lugar e com que resultados.
Considere os perodos de paralelo correr ao lado de solues existentes antes
de finalmente ir viver.
Ao avaliar ferramentas, um ajuste de 100% para os requisitos no deve ser
esperado e quase certamente no ser encontrado. A regra '80 / 20 'deve ser
levado em vigor vez. A ferramenta considerado adequado para a sua
finalidade, se encontra 80% ou mais do negcio'S requisitos operacionais.
Aqueles operacional requisitos devem ser classificados como discutido
anteriormente.
Qualquer produto deve ser rejeitada como inadequada se no de todos os
requisitos obrigatrios ('must haves') so satisfeitas. Em algumas circunstncias,
ser impossvel encontrar um produto de software existente, que quer atender a
todos os requisitos obrigatrios ou fornecer uma correspondncia de 80%. Nesta
situao, o produto oferece a melhor design funcional devem ser selecionados e
os elementos inadequados re-escrito. Este processo de melhoria deve ser feito
pelo fornecedor, se possvel. Em alguns casos, parte dos custos de melhoria
podem ser cumpridas pelo comprador. Alguns produtos foram concebidos para
incluir usurio ganchos - isto proporciona acessibilidade ao local de cdigo
escrito em pontos-chave do processo, sem a necessidade de um pacote a ser
modificado.
Ela no termina quando o produto foi selecionado. Em muitos aspectos, este
poderia ser considerado como apenas o comeo. A ferramenta agora tem de ser
implementada. Uma vez que a plataforma de hardware foi preparado e
carregado o software, a populao de dados precisa ser considerada. O que, de
onde, como e quando? O tempo importante para a implementao de testes, e
os go-live processoes. Recursos deve estar disponvel para garantir o sucesso.
Em outras palavras, no agendar a implementao durante um determinado
perodo ocupado, como no final do ano de processamento. Software de hoje
como um servioOs produtos esto disponveis em hardware e software no
so necessrios. Estes produtos do acesso baseado em rede e gesto de
software disponvel comercialmente. Estes tipos de produtos ainda exigiro
planejamento e implementao, mas isso deve simplificar o processo como
nenhum hardware dedicado necessrio.
Dever tambm ser dada para gerenciado provedor de servioss e Application
Service Providers, que pode ser capaz de fornecer a mesma funcionalidade.
Em qualquer ferramenta ou o tipo de ferramenta escolhido, o cumprimento os
requisitos podem ser diferenciados entre:
Out-of-the-box - A exigncia cumprida
369 de 477
Configurao - A ferramenta pode ser configurada com x dias de esforo

para preencher o requisito e este ser preservada durante actualizaes
de produtos
Personalizao - A ferramenta deve ser reprogramado com x dias de
esforo para cumprir a exigncia, E este pode ter de ser repetida em cada
actualizao do produto.
Personalizao extensiva de qualquer produto sempre melhor evitar por causa

da alta custars incorridos na atualizao do produto. Os vendedores podem no
estar dispostos a apoiar verses antigas, e os compradores podem ser
incapazes de o recurso necessrio re-aplicao de qualquer personalizao sob
medida. Personalizao tambm pode liberar o fornecedor de grande parte das
suas obrigaes de apoio - isso seria desastroso se, como resultado, sua
Servio de Gesto de sistema no estiver disponvel por qualquer perodo de
tempo. Os custos adicionais seriam incorridos na prestao do treinamento
personalizado, que seria necessrio. Seria impossvel para tirar vantagem de
qualquer baratos cursos de formao programados sendo executados pelo
software fornecedor.
O processo de avaliao da ferramenta mostrada na Figura 7.1.
Figura 7.1 Servio de Gesto de processo de avaliao de ferramentas
A Figura 7.1 mostra a abordagem padro de identificao de requisitos antes de

identificao de produtos, mas de forma pragmtica pode haver algum elemento
de sobreposio, onde a explorao de ferramentas no mercado abre os olhos
para novas opes que mudam os requisitos. Estes estgios so direcionados
370 de 477
principalmente ao avaliao de pacotes de produtos de software, mas uma

abordagem semelhante pode tambm ser utilizado na avaliao construdo sob
encomenda software. Produzir uma clara Declarao de Requisitos (SOR) que
identifica os requisitos de negcio em conjunto com as instalaes obrigatrias e
as caractersticas de que seria "bom ter". Tambm identificar as polticas do site
e as normas a que o produto deve estar de acordo. Tais padres podem inclu-lo
em execuo no software do sistema particular, ou em hardware especfico.
Lembre-se as consideraes sobre o fornecedorAdequao 's, e realizar uma
avaliao formal dos produtos em questo.
Se as ferramentas bem desenvolvidas e adequadas so utilizados para apoiar
os processos, os resultados obtidos ser muito maior e, frequentemente, os
custos globais de servio proviso ser menor. Selecionar a ferramenta certa
significa prestar ateno a uma srie de questes:
Um ajuste de 80% a todos os requisitos funcionais e tcnicos

Uma reunio de todos os requisitos obrigatrios
Personalizao de produtos pouco (se houver) necessrio
A adeso da ferramenta e fornecedor para Gesto de Servios melhores
prticas
Uma estrutura de dados de som e manuseamento
Integrao com outros Servio de Gesto de e ferramentas de Gesto
Operacional
Suporte de padres abertos e interfaces
Business-Driven no impulsionada pela tecnologia
Administrao e manuteno custars dentro oramento
Nveis aceitveis de manuteno e liberar polticas
Segurana e integridade
Disponibilidade de servios de formao e consultoria
Gerao de relatrio boa
Escalabilidade e crescimento.
371 de 477
8 Design de Servios Implementar

Esta seo da publicao considera que a tarefa de implementar a Design de
Servios processos e aborda questes como:
Por onde comear?

Como podemos melhorar?
Como sabemos que estamos a fazer progressos?
As atividades de implementao e melhoria Service Design precisa ser focada

nas necessidades e desejos do cliente e a negcio. Portanto, essas atividades
devem ser orientadas e priorizados por:
Necessidades de negcio e impactos nos negcios

Os riscos para os servios e processoes.
As atividades sero influenciada significativamente pelos requisitos descritos nas

SLRs e pelos acordos feitos no SLAs.
372 de 477
8.1 Anlise de Impacto no Negcio

Uma valiosa fonte de entrada ao tentar verificar as necessidades de negcios,
impactos e riscos o Anlise de Impacto no Negcio (BIA). A BIA um
elemento essencial de todo o processo de continuidade de negcios (ver seco
4.7) e vai ditar o estratgia para a reduo de riscos e recuperao de
desastres. Sua finalidade normal para identificar o efeito de um desastre teria
sobre o negcio. Ela vai mostrar quais partes do organizao sero os mais
afectados por um incidente grave e qual o efeito que isso ter sobre a empresa
como um todo. , portanto, permite o reconhecimento das funes de negcios
mais crticos para a sobrevivncia da empresa e onde esta criticidade difere,
dependendo da hora do dia, semana, ms ou ano. Alm disso a experincia tem
mostrado que os resultados da BIA pode ser um contributo extremamente til
para um certo nmero de outras reas, e vai dar uma compreenso muito maior
do servio do que seria o caso.
A BIA pode ser dividido em duas reas:
Um a gesto de negcios, que tem de investigar o impacto da perda (ou

perda parcial) de um processo de negcio ou um negcio funo. Isto
inclui o conhecimento de soluo manuals e a sua custars.
Um segundo papel localizado em Servio de Gesto de essencial para
quebrar os efeitos da perda de servio para a empresa. Este elemento da
BIA mostra o impacto da interrupo do servio ao negcio. Os servios
podem ser gerenciados e influenciados pelo Service Management. Outros
aspectos tambm cobertos em 'Negcio BIA' no pode ser influenciado
pelo Service Management.
Como parte da fase de concepo de um novo servio ou alterados, a BIA deve

ser realizada para ajudar a definir a continuidade do negcio estratgia e permitir
uma maior compreenso sobre a funo e importncia do servio. Isso vai
permitir que a organizao define:
Quais so os servios essenciais, o que constitui um grande incidente

sobre esses servios, bem como o impacto subseqente e inconvenientes
causados aos negcios - importante para decidir quando e como
implementar mudars
Nveis aceitveis e horrios dos nveis de interrupo do servio - uma
vez mais importantes na considerao de cronogramas de mudana e
implementao
Negcios crticos e perodos de servio - perodos importantes para evitar
O custo de perda de servio - importante para Gesto Financeira
O potencial segurana implicaes de uma perda de servio consideraes importantes na gesto de risco.
373 de 477
8,2 Nvel Requisitos de Servio

Como parte do Gerenciamento de Nvel de Servio processo (ver Captulo 4), a
Nvel Requisitos de Servio para todos os servios ser apurado e capacidade
para entregar a estes requisitos sero avaliados e, finalmente, concordou em um
formal SLA. Para novos servios, os requisitos devem ser verificada no incio do
desenvolvimento processo, e no aps a concluso. Construir o servio com os
Requisitos de Nvel de Servio em primeiro lugar em mente essencial do ponto
de vista Design de Servios.
8,3 Riscos para os servios e processos

Ao implementar o Design de Servios e ITSM processoes, business-as-usual
prticas no deve ser afetado negativamente. Este aspecto tem de ser
considerado durante a produo e seleco da soluo preferida para assegurar
que a perturbao operacional servios minimizado. Este avaliao de risco
deve ser considerado em detalhe no Transio de Servio atividades como parte
do processo de implementao
374 de 477
8,4 Service Design Implementar

O processo, poltica e arquitetura para o projeto de De servios de TIs descrito
nesta publicao ter de ser documentado e utilizado para garantir o adequado
inovadores servios de TI pode ser projetado e implementado para atender
atuais e futuros requisitos de negcios acordados.
O IT Service Management processos descritos no captulo 4 desta publicao e
nas publicaes nesta srie tambm ter de ser implementada para garantir a
prestao de servios que corresponda s exigncias da negcio.
A questo muitas vezes colocada "Qual processo devo implementar primeiro?
'A verdadeira resposta de todos eles, como o verdadeiro valor da aplicao de
todas as Servio de Gesto de processos muito maior do que a soma dos
processos individuais. Todos os processos esto interligados e, em alguns
casos, so totalmente dependentes de outras pessoas. O que necessrio em
ltima anlise, um conjunto nico e integrado de processos, fornecendo
gerenciamento e controlar de um conjunto de servios de TI em todo o seu ciclo
de vida.
Embora reconhecendo que, para obter o benefcio completo de implementao
de IT Service Management, todos os processos precisam ser abordados,
tambm se reconhece que improvvel que as organizaes podem fazer tudo
de uma vez. Portanto, recomendvel que as reas de maior de precisar de ser
tratada primeiro. Uma avaliao detalhada precisa ser realizado para verificar os
pontos fortes e fracos dos servios de TI prviso. Esta deve ser realizada
atravs da realizao de pesquisas de satisfao de clientes, falando com
clientes, conversando com o pessoal de TI e analisar os processos em ao.
Disto avaliao, De curto, estratgias de mdio e longo prazo pode ser
desenvolvida.
Pode ser que a "progressos rpidos" devem ser implementadas a curto prazo
para melhorar a situao actual, mas estes processos melhorados podem ter
que ser descartado ou alterado, como parte das estratgias de mdio ou longo
prazo. Se "progressos rpidos" so implementadas, importante que eles no
devem ser realizados custa do longo prazo objetivos, assim que estes devem
ser considerados em todos os momentos. No entanto, cada organizao ter
que comear de algum lugar, eo ponto de partida ser sempre que a
organizao est agora em termos de TI Servio de Gesto de maturidade.
Prioridades de implementao deve ser definido contra os objetivos de um SIP.
Por exemplo, se disponibilidade de De servios de TIs uma questo crtica,
concentrar-se nos processos que visam maximizar a disponibilidade (por
exemplo, Gerenciamento de Incidentes, Gerenciamento de Problemas,Gesto
da Mudana e Gerenciamento de Disponibilidade). Ao longo do processo de
implementao, os principais atores devem estar envolvidos no processo de
375 de 477
tomada de deciso. Estas incluem receptores, bem como fornecedores da

servio. No pode haver uma tendncia, ao analisar as reas de maior
necessidade, para ir direto para as ferramentas para melhorar a situao.
Oficinas ou grupos de foco ser benfico na compreenso dos requisitos e do
processo mais adequado para a aplicao que ir incluir pessoas, processos,
produtos e parceiros.
A primeira coisa a fazer estabelecer um processo formal e mtodo de
implantao e melhoria de Design de Servios, Com a apropriada governo no
lugar. Este processo formal deve ser baseado em torno do processo de seis
fases ilustrada na Figura 8.1. Mais informaes tambm podem ser encontradas
neste processo na publicao Melhoria de Servio Continuada.
importante que aquando da aplicao ou a melhoria processoes um mtodo
estruturado de gesto de projeto usado. O processo de melhoria pode ser
resumido como, em primeiro lugar, compreender o viso determinando a alto
nvel objetivo de negcios. A "viso de definio de 'deve definir e alinhar
negcios e estratgias de TI. Segundo, a avaliao da situao atual para
identificar os pontos fortes que podem ser construdas sobre e fracos que
precisam ser abordadas. Por isso, "Onde estamos agora? ' uma anlise da
situao atual em termos do negcio, organizao, Pessoas e processos.
Terceiro, "Onde queremos ser?" um desenvolvimento dos princpios definidos
na viso de definio de, concordando as prioridades de melhoria, e quarta,
detalhando o SIP para obter maior qualidade de servio prviso. Em seguida,
medies e mtricos precisam de ser postas em prtica para mostrar que as
metas foram alcanadas e que os objetivos de negcios e prioridades de
negcios foram cumpridos. Finalmente, o processo deve assegurar que o ritmo
de qualidade melhoria mantida.
A seguir, so elementos-chave para o alinhamento de TI com sucesso os
objetivos de negcios:
Viso e liderana na criao e manuteno de estratgico direo,

objetivos claros, e medio de realizao do objetivo em termos de
estratgico direo
Aceitao da inovao e novas formas de trabalho
Profundo conhecimento do negcio, a sua das partes interessadass e seu
ambiente
A equipe de TI entender as necessidades do negcio
O negcio compreender o potencial da TI
Informao e comunicao disponveis e acessveis a todos que precisa
Tempo alocado separadamente para se familiarizar com o material
Acompanhamento contnuo de tecnologias para identificar oportunidades
para o negcio.
376 de 477
O ciclo de implementao / melhoria til para verificar o alinhamento entre o

negcio ea TI, como mostrado na figura 8.1.
Figura 8.1 ciclo de implementao / melhoria
8.4.1 O que a viso?

O ponto de partida para todas essas atividades o cultura e meio ambiente da
provedor de servios organizao. As pessoas ea cultura tem que ser adequado
e aceitvel para a melhoria e mudana. Portanto, antes de tentar qualquer outra
coisa, a cultura dentro do prestador de servios precisa ser revista para garantir
que ele ir aceitar e facilitar a implementao das mudanas requeridas e
melhorias. As etapas seguintes devem ser preenchidos para alcanar esta fase
do ciclo de:
Estabelecer um viso, Alinhado com a viso do negcio e objetivos

Estabelecer a escopo do projecto /programa
Estabelecer um conjunto de objetivos de alto nvel
Estabelecer governoE patrocnio oramento
Obter compromisso da alta administrao
Estabelecer um cultura focada em:
Qualidade
Cliente e foco dos negcios
Um ambiente de aprendizagem
Melhoria contnua
Compromisso com o 'ciclo de melhoria "
Propriedade e responsabilidade.
377 de 477
8.4.2 Onde estamos agora?

Uma vez que o viso e objetivos de alto nvel foram definidos, o provedor de
servios ento precisa analisar a situao actual, em termos do que processoes
esto no lugar ea maturidade da organizao. Os passos e atividades que
precisam ser concludas aqui so:
Arever,avaliao ou um mais formal auditar da situao atual, usando

uma tcnica preferida:
Uma reviso interna ou auditoria
Avaliao de maturidade
Uma avaliao externa ou referncia
Um ISO / IEC 20000 auditoria
Uma auditoria contra COBIT
A Foras, Fraquezas, Oportunidades e Ameaas (SWOT) anlise
Aavaliao de risco e gesto metodologia
A reviso deve incluir:
A cultura e maturidade da provedor de servios organizao
Os processos em andamento e seus capacidade e maturidade
As habilidades e competncias das pessoas
Os servios e tecnologia
O fornecedors, contratos e a sua capacidade
O qualidade de servio e as medidas atuais, mtricos e KPIs
Um relatrio que resume as concluses e recomendaes.
A reviso da cultura deve incluir a avaliao em termos de capacidade e

maturidade da cultura dentro do Provedor de servios de TI organizao, como
mostrado na figura 8.2.
Figura 8.2 avaliao de maturidade Cultural
378 de 477
Este avaliao deve basear-se no facto de cada fase de crescimento representa

uma transformao de TI e, como tal, necessrio:
Mudanas nas pessoas (habilidades e competncias)

Processos e formas de trabalho
Tecnologia e ferramentas (para apoiar e habilitar as pessoas e processos)
Direco (as vises, objetivos e resultados)
Atitude (os valores e crenas)
O nvel adequado eo grau de interao com o negcio,das partes
interessadass, clientes e usurios.
A avaliao deve incluir tambm uma rever da capacidade e maturidade do

Design de Servios processos, como se mostra na figura 8.3.
Figura 8.3 estrutura de maturidade de processo
Esta avaliao e incluir todos os aspectos dos processos e da sua utilizao,

incluindo o:
Viso: Direco, objetivos e os planos

Processo de maturidade, funcionalidade, utilizao, aplicao, eficcia e
eficincia juntamente com propriedade, gesto e documentao
Pessoas: os papels, responsabilidades, competncias e conhecimentos
das pessoas
Produtos, incluindo as ferramentas e tecnologias utilizadas para
automatizar os processos
Cultura: O foco, atitudes e crenas.
O quadro acima pode ser usado para fornecer a consistncia do processo

avaliao. Avaliando esses dois aspectos vo determinar o estado atual da
organizao e os seus Servio de Gesto de capacidade e maturidade. Ao
379 de 477
iniciar-se sobre a implementao ou melhoria de Design de Servios, Ou

qualquer conjunto de processos, importante aproveitar os pontos fortes das
culturas e processos existentes e rapidamente identificar e melhorar os pontos
fracos. Uma explicao mais detalhada deste quadro est contida no Anexo H.
8.4.3 Onde que ns queremos ser?

Com base na avaliao do estado atual, eo viso e objetivos de alto nvel, um
estado futuro desejado pode ser definido. Isto deve ser expresso em termos de
projecto resultados, incluindo parte ou a totalidade de:
Melhorou o servio de TI prviso alinhamento com os requisitos de

negcios total
Melhoria da qualidade de Design de Servios
Melhorias na nvel de servios e qualidade
Aumentos na satisfao do cliente
Melhorias no processo atuao.
8.4.4 Como que vamos chegar l?

Um conjunto de melhorias devem ser identificados para avanar a partir do
estado atual para o estado futuro concordou. A plano para implementar essas
melhorias devem ser desenvolvidas, incorporando Transio de Servio e
Operao de Servio, E deve incluir:
As aes de melhoria
A abordagem a adoptar e os mtodos a serem utilizados
Atividades e os prazos
Avaliao de risco e gesto
Recursos e oramentos
Papels e responsabilidades
Monitoramento, Medio e anlise.
8.4.5 Como podemos dizer quando temos l?

Muitas vezes, as organizaes instigar iniciativas de melhoria sem considerar ou
projetar o sistema de medio desde o incio. O sucesso da iniciativa no pode,
portanto, ser determinado porque no temos referncia antes, durante ou aps a
aplicao. imperativo que as medidas so projetados antes da implementao.
Um conjunto definido de mtricos necessita de ser utilizada, a fim de assegurar
que o estado futuro desejado seja alcanado. Este estado futuro desejado
precisa de ser expressa em termos mensurveis, tais como:
X% de reduo Design de Servios no-conformidades

X% de aumento na satisfao do cliente
X% de aumento do servio disponibilidade dos servios crticos.
380 de 477
Assim, uma vez que as aes de melhoria e planos foram concludos, cheques e
comentrios devem ser concludas no fim de determinar:
Ser que vamos alcanar nosso estado desejado novo e objetivos?

H lies aprendidas e poderamos fazer melhor da prxima vez?
Ser que vamos identificar as aes de melhoria outros?
8.4.6 Como que vamos continuar?

Tendo melhorado, agora precisamos consolidar e seguir em frente. O
organizao e a cultura deve reconhecer que sempre podemos melhorar, e,
portanto, deve estabelecer um ambiente de melhoria contnua. Assim, uma vez
que conseguimos o novo estado desejado, temos de rever o viso e objetivos,
identificar mais aes de melhoria e repetir o estgio de seis processo
novamente. Assim, nesta fase, tudo sobre:
Desenvolvimento de um ambiente de aprendizagem

Estabelecer um desejo de melhorar toda a organizao
Reconhecer e reforar a mensagem de que a qualidade ea melhoria so
tarefa de todos
Manter o mpeto na melhoria e qualidade.
381 de 477
8,5 Medio de Design de Servios

O sucesso do Design de Servios e para o sucesso da melhoria dos processos
de todo o Design de Servios deve ser medido, os dados devem ser analisados
e relatados. Onde o projeto ou processo no satisfaz os requisitos da negcio
como um todo, as mudanas no processo podem ser necessrios e os
resultados de tais alteraes devem tambm ser medidos. Medio contnua,
anlise e relatrios so requisitos obrigatrios, tanto para o Design de Servios
processo e os processos de ITSM.
Existem mtodos de medio disponveis que permitem a anlise de melhoria
dos servios. O Balanced Scorecard um mtodo desenvolvido por Robert
Kaplan e David Norton como um conceito para medir as atividades de uma
empresa em termos de sua viso e estratgias. Ele d uma viso abrangente do
desempenho de uma empresa. O sistema obriga os gestores a focar o
desempenho importante mtricoO sucesso da unidade que. Ele equilibra a
perspectiva financeira com o processo do cliente, interna e aprendizado e
perspectivas de crescimento. Mais informaes podem ser encontradas no
mtodo Balanced Scorecard na publicao Melhoria de Servio Continuada.
Seis Sigma uma metodologia desenvolvida por Bill Smith na Motorola Inc., em
1986, e foi originalmente projetado para gerenciar variaes do processo que
causam defeitos, definidos como desvio inaceitvel da mdia ou de destino, e
trabalhar sistematicamente para a gesto variao de eliminar os defeitos. Seis
Sigma j cresceu alm do controle de defeitos e frequentemente utilizado para
medir a melhoria em TI execuo do processo. (Six Sigma uma marca de
servio registrada e marca registrada da Motorola Inc.)
Seis Sigma (DMADV) um sistema de melhoria usado para desenvolver novos
processos em seis nveis de qualidade Sigma e definido como:
Definir - Formalmente definir os objetivos do projeto atividade que esto

de acordo com as demandas dos clientes e organizao estratgia
Medir - Identificar Fator Crtico de Sucessos, a capacidade do processo,
capacidade e avaliao de riscos
Analisar - Desenvolver e projetar alternativas, criar design de alto nvel e
avaliar a capacidade de projeto para selecionar o melhor projeto
Projeto - Desenvolver o projeto detalhado, otimizar projeto e plano para o
projeto verificao
Verificar - Criar piloto corridas, implementar a produo processo e
entregar a proprietrio do processos.
O Seis Sigma processo (DMAIC) (definir, medir, analisar, melhorar, controlar)

um sistema de melhoria de processos existentes caindo abaixo especificao e
olhando para a melhoria incremental.
382 de 477
8.5.1 Pr-requisitos para o sucesso

H um nmero de pr-requisitos necessrios para a Design de Servios e a bem
sucedida introduo de novos processos ou revisado. Muitas vezes, estes prrequisitos para o sucesso (PFSs) so elementos de um processo requerido por
outro. Por exemplo, totalmente preenchido e up-to-date de Negcios Catlogo
de Servios e Catlogo de Servio Tcnico so necessrios antes
Gerenciamento de Nvel de Servio pode projetar o SLA e estrutura de suporte
acordo, e antes SLM pode configurar e acordar o SLAs. Gerenciamento de
Problemas depender de uma madura Gerenciamento de Incidentes processo.
Os PFSs pode ser muito mais ampla do que apenas interdependncias ITSM
processo. Por exemplo, a projeto de disponibilidade e capacidade para um novo
servio no pode ser alcanado sem os detalhes do negcio plano para a
utilizao do novo servio. O design do servio ser impossvel sem a Portflio
de Servios e Pacote de Desenho de Servio. H muitos mais exemplos destes
PFSs que precisam ser consideradas e planejadas antes de nveis de
maturidade elevados processo pode ser alcanado. Baixo maturidade num
processo significa que altos nveis de maturidade no ser possvel em outros
processos.
8.5.2 Fatores Crticos de Sucesso e Indicadores Chave de

Desempenho
Fator Crtico de Sucesso (CSF) um termo para um elemento que necessrio
para uma organizao ou projeto para cumprir sua misso. FCS pode ser usada
como um meio para a identificao dos elementos importantes para o sucesso.
QCA so as coisas que tm de ser tem direito na Design de Servios e dentro
de cada processo de ITSM. Key Performance Indicators (KPIs) so medidas que
quantificam objectivos e permitir a medio de atuao. KPIs devem ser
ajustados e medidos em relao concepo e para cada um dos processos
para assegurar os CSFs so cumpridos. Juntos, os QCA e KPIs estabelecem o
linha de base e mecanismos de monitoramento de desempenho.
Recomenda-se que cada organizao de TI se concentra em um pequeno subconjunto de QCA e KPIs a qualquer momento. Os QCA necessrios e KPIs
devem ser definidos no incio do Plano de Melhoria de Servio Continuada
(CSIP).
importante que os QCA so acordados durante a fase de concepo de um
servio e dos processos, e que os indicadores chave de desempenho (KPIs) so
definidos, medidos e relatados para indicar o qualidade do Design de Servios e
os processos de design de servio. H uma exigncia de ser capaz de analisar o
quo bem a infra-estrutura de servios foi concebido. possvel chegar a um
bom projeto de uma forma muito ineficiente de recursos, e vice-versa, por isso
precisamos de olhar para a qualidade, bem como recursos exigido para obter a
383 de 477
qualidade desejada. KPIs todo o sucesso da entrega do servio indicam o

eficcia do Service Design so aplicveis - por exemplo, se o servio de cumprir
os requisitos (definido) de negcio de disponibilidade,
confiana,rendimento,segurana,manuteno,manuteno, Etc funcionalidade?
KPIs em torno das estimativas de recursos, no entanto, vai nos mostrar o quo
eficiente estvamos no design.
Estas devem ser definidas como parte de QA planejamento e liberao
aceitao. Estes KPIs poderia ser apoiada por semelhante componente
mtricos.
KPIs para o processo de Design de Servios incluem:
Percentagem de exigncia Design de Servios especificaos produzidas em

tempo (e de oramento)
Percentagem de Design de Servios planos produzidos no tempo
Percentual de pacotes de design de servio concludas a tempo
Porcentagem de controle de qualidade e critrios de aceitao planos
produzidos no tempo
Preciso de Design de Servios - Por exemplo, se a infra-estrutura correta
construda para suportar o servio?
Preciso percentagem da estimativa de custo de toda a fase de Desenho de
Servio
Preciso de SLA (s), OLA (s) e contrato(S) - eles realmente suportar o nvel de
servio requerido?
Para julgar servio proviso e desempenho do processo de ITSM, claramente

definida objetivos com metas mensurveis deve ser definido. A confirmao
precisa ser buscado que estes objectivos e as metas fixados no Melhoria de
Servio Continuada (CSI) fase do ciclo de vida foram alcanados e que o servio
desejado qualidade ou desejada melhoria de qualidade foi conseguida. vital na
concepo de servios ou processoes que KPIs so projetados desde o incio e
recolhido regularmente e nos marcos importantes. Por exemplo, ao conceber a
concluso de cada fase significativa do programa, Uma Reviso Psimplementao (PIR) devem ser realizados para garantir que os objectivos foram
atingidos. O PIR incluir um rever de documentao de apoio e da
conscientizao geral de entre o pessoal dos processos refinados.
A comparao necessria do que foi alcanado contra os objetivos originais
estabelecidos no projeto. Uma vez que este tenha sido confirmado, novas metas
de melhoria devem ser definidos. Para confirmar que as metas foram
alcanadas, os KPIs devem ser constantemente monitorados. Estes KPIs incluir
metas de satisfao do cliente, por isso no haver a necessidade de
levantamento clientes planejada em vrias etapas para confirmar que mudars
feitas so a melhoria da percepo do cliente da qualidade do servio.
possvel que os servios tm maior disponibilidade, que existem menos
incidentes e que tempo de respostas tm melhorado, mas ao mesmo tempo a
384 de 477
percepo do cliente de qualidade de servio no melhorou. evidente que esta

to importante, e ter de ser abordada por falar com os clientes para
determinar suas preocupaes. A confirmao dever ser procurado CSIs que
colocar no lugar esto abordando as necessidades primrias do cliente.
Para mais informaes sobre a melhoria dos servios prticas, por favor,
consulte a publicao Melhoria de Servio Continuada.
385 de 477
9 Desafios, Fatores Crticos de Sucesso e riscos

9,1 Desafios
Com cada empresa haver desafios ou dificuldades para enfrentar e superar.
Isto ser especialmente verdade quando tentando projetar novos servios e
processos que atendam as necessidades de todos os das partes interessadass
no interior da negcio. A experincia tem mostrado que a seguir ir ajudar a
superar os desafios:
Compreender os requisitos de negcio e as prioridades de negcios e

garantir que estes so em primeiro lugar em mente ao projetar os
processos e os servios.
A comunicao ser de vital importncia tanto para explicar o que est
acontecendo e como os indivduos sero afetados e em ouvir as
exigncias e necessidades dos indivduos. de vital importncia para se
comunicar com as pessoas sobre questes que se relacionam com o seu
trabalho dirio.
Envolver as pessoas como muitos como possvel no projeto. Criao de
grupos de foco ou grupos de orientao pode ser muito eficaz na
obteno da soluo correta, bem como ganhar mais apoio.
Ganhando o compromisso da gerncia snior, bem como de todos os
nveis de pessoal.
Exemplos de desafios que podem ser enfrentados incluem:
A necessidade de garantir o alinhamento com as atuais direes

arquitetnicos, estratgia e polticas. Um exemplo disto pode ser que a
infra-estrutura pode ter obtido pobre monitoramento e recursos de
controle.
O uso de tecnologias diversas e dspares e aplicaos.
Documentao e adeso s prticas e processos acordados.
Claro ou mudana de requisitos do negcio. Este pode ser inevitvel em
alguns casos porque as necessidades de negcios so susceptveis a
alteraes. O importante assegurar que h uma estreita muito relao
entre o Provedor de servios de TI organizao e do empresa cliente do
servio, Para que quaisquer mudanas de requisitos pode ser identificado
como o mais rapidamente possvel.
A falta de conscincia e conhecimento de servios e empresas de
objectivos e requisitos.
Ligada ao ponto acima, pode ser que algumas instalaes no so
incorporadas ao projeto. Mais uma vez, imperativo que os
representantes de cada usurio do servio concebido ou processo esto
envolvidos em todo o processo para reduzir a chance de que isso
386 de 477
acontea. Detalhes do ensaio em servio (um elemento importante aqui)

esto contidas dentro do Transio de Servio publicao.
A resistncia aos planejamento, Ou uma falta de planejamento de
liderana para iniciativas no planejadas e compras no planejadas.
Uso ineficiente de recursoest causando desperdcio gastar e
investimento.
Como mencionado anteriormente, um bom conhecimento e apreciao
dos impactos nos negcios e prioridades imperativo.
Relaes ruins, comunicao ou falta de cooperao entre a TI provedor
de servios e a negcio pode resultar no projeto no alcanar os
requisitos de negcios.
Resistncia ao trabalho no prazo acordado estratgia.
O uso de, e, portanto, as limitaes de, a tecnologia antiga e sistemas
legados.
Ferramentas necessrias so muito caros ou muito complexo de
implementar ou manter com as habilidades dos funcionrios atuais.
Falta de informao, acompanhamento e medies.
Metas razoveis e prazos previamente acordados no SLA e OLA.
Sobre o compromisso dos recursos disponveis com uma incapacidade
associada a entregar (por exemplo, projetos sempre atrasado ou acima
do oramento).
Pobre Gesto de Fornecedores e / ou de m fornecedor atuao.
A falta de foco no servio disponibilidade.
A falta de conscientizao e adeso ao operacional aspectos segurana
polticas e procedimentos.
Garantir diria normal operao ou de negcios, como de costume
considerado como parte do projeto.
Custo e restries oramentais.
Determinar o retorno do investimento ea realizao de benefcio do
negcio.
387 de 477
9,2 Riscos
H um certo nmero de riscos directamente associada com a Design de
Servios fase do Ciclo de Vida do Servio. Estes riscos devem ser identificados
para assegurar que eles no so realizados. Eles incluem o seguinte:
Se algum dos PFSs para Design de servio no forem satisfeitas,

Desenho do Servio ou Servio de Gesto de processo no ser bem
sucedida.
Se maturidade os nveis de um processo baixo, ser impossvel atingir a
plena maturidade em outros processos.
Requisitos de negcio no esto claras para a equipe de TI.
Prazos de negcios so tais que tempo suficiente dada ao design de
servio adequada.
Teste insuficiente, resultando em m concepo e implementao,
portanto, pobres.
Um equilbrio incorreto atingido entre inovao, risco e custar enquanto
procura uma vantagem competitiva, onde desejado pela empresa.
O ajuste entre as infra-estruturas, clientes e parceiros no suficiente
para atender os requisitos gerais de negcios.
A interface no fornecido coordenada entre os planejadores e
planejadores de negcios.
As polticas e estratgias, especialmente as Servio de Gesto de
estratgia, no esto disponveis a partir de Estratgia de Servio, Ou o
seu contedo no claramente compreendido.
H insuficincia de recursos e oramento disponvel para Design de
Servios actividades.
O risco de os servios desenvolvidos isoladamente usando seus prprios
recursos e infra-estrutura ". Isso pode parecer mais barato em isolamento,
mas pode ser muito mais caro no longo prazo por causa das economias
financeiras de compra corporativa eo custo extra de apoio diferente
arquitetura.
Tempo insuficiente dada a fase de projeto, ou treinamento insuficiente
dado ao pessoal encarregado da projeto.
Engajamento insuficiente ou compromisso com a funcional do aplicativo
desenvolvimento, Levando a ateno insuficiente s exigncias de Design
de Servio.
388 de 477
Posfcio
Design de Servios, Tal como descrito nesta publicao, abrange a concepo
de apropriada e inovador De servios de TIs para atender atuais e futuros
requisitos de negcios acordados. Design de Servios desenvolve um Pacote de
Desenho de Servio e olha para selecionar o Design de Servios apropriado
modelo. Nesta publicao, tambm examinaram os vrios modelos de sourcing
disponveis e dado algumas vantagens e desvantagens de cada um.
A publicao tambm aborda os fundamentos do projeto processoes e os cinco
aspectos da projeto:
O design do servio As solues, 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 atravs de seu ciclo
de vida
O design das arquiteturas de tecnologia e arquiteturas e ferramentas de gesto
necessrias para fornecer os servios
O desenho ou especificao dos processos necessrios para projetar,
transio,operar e melhorar a ateno, os arquiteturas e os processos prprios
O design dos sistemas de medio, mtodos e mtricos para os servios, as
arquitecturas e seus constituintes componentes e os processos.
A definio de Design de Servios a seguinte:

"O projeto de adequadas e inovadoras de servios de TI, incluindo suas
arquiteturas, processos, polticas e documentao, para atender s atuais e
futuros requisitos de negcios acordados.
A publicao explicou que a melhor e mais cuidada do projeto, a melhor soluo
a ter em operao ao vivo. Tambm muito provvel que a melhor o projeto,
menos tempo re-trabalho que ter de ser realizado durante a transio e as
fases vivas.
O escopo Esta publicao inclui a concepo de servios, bem como a
concepo de Servio de Gesto de sistemas e processos. Design de Servios
no se limita a novos servios, mas inclui mudar necessrio aumentar ou manter
o valor para os clientes sobre a ciclo de vida de servios.
Esta publicao explica que o pragmatismo s vezes substitui a soluo perfeita
onde sabemos que o que seria, mas a quantidade de esforo e custar no
justifica a soluo perfeita. Como sempre, vai depender das necessidades do
negcio e os requisitos de negcio. Como sempre, imperativo que o que feito
dentro de TI tem um benefcio direto para o negcio global
389 de 477
Apndice A: O Pacote de Desenho de Servio

A 'Pacote de Desenho de Servio"Ou SDP deve ser produzido durante a fase de
projeto, para cada novo servio, grande alterao a um servio ou a remoo de
um servio ou mudanas para o" Pacote de Desenho de Servio "em si. Este
pacote ento passado de Design de Servios para Transio de Servio e
detalhes de todos os aspectos do servio e seus requisitos atravs de todas as
fases seguintes de sua vida til. A SDP dever conter:
Categoria
Sub-categoria
Descrio do que est na SDP
Requisitos
Requisitos de
negcio
As iniciais acordados e documentados os requisitos de

negcios
Aplicabilidade
servio
Isto define como e onde o servio seria utilizada. Isso

poderia fazer referncia a cliente de negcios, e usurio
requisitos relativos aos servios internos
Design de
Servios
Contatos de
servios
Os contatos de negcios, contatos de clientes e das partes

interessadass no servio
Requisitos
funcionais de
servios
A funcionalidade alterada do servio novo ou alterado,

incluindo a sua planejada resultados e entregas, de um
acordo formal Declarao de Requisitos (SOR)
Nvel
Requisitos de
Servio
O SLR, revista ou uma nova SLA, Incluindo o servio e

qualidade alvos
Servio e
operacional
requisitos de
gesto
Requisitos de gesto para gerenciar o servio novo ou

alterado e sua componentes, incluindo todos servios de
apoios e acordos, controlar,operao,monitoramento, Medir
e informar
Design de
Servios e
topologia
O projeto,transio e posterior implementao e operao

do servio soluo e seus componentes de suporte,
incluindo:
Avaliao de
Avaliao de
A definio de servio e modelo, para transio e

operao
Todos os servios componentes e infra-estrutura
(incluindo H / W, S / W, redes, ambientes de dados,
aplicaos, tecnologia, ferramentas,
documentao), incluindo verso nmeros e
relaos, de preferncia dentro da CMS
Todos usurio, Servio, empresa, componente
transio, Suporte e documentao operacional
Processos, procedimentos, as medies, mtricos e
relatrios
Produtos de apoio, servios, acordos e fornecedors
Relatrio "Avaliao de Prontido Organizacional" e plano,
390 de 477
prontido
organizacional
prontido
organizacional
Incluindo: o benefcio do negcio, financeiro

avaliaoTcnica, avaliao, avaliao de recursos e
avaliao organizacional, juntamente com detalhes de todas
as novas habilidades, competncias, capacidades exigidas
do provedor de servios organizao, A sua fornecedors,
servios de apoios e contratos
Plano de
Servio do
Ciclo de Vida
Programa de
servio
Um total programa ou plano que abrange todas as fases do

ciclo de vida do servio, incluindo os prazos e faseamento,
para o transio,operao e posterior aperfeioamento do
novo servio, incluindo:
Plano de
Transio de
Servio
Transio global estratgia, Objetivos, poltica,avaliao de

risco e os planos incluindo:
Coordenao, gesto e integrao com qualquer

outro projetoatividades s, ou novos ou modificados,
servios ou processoes
Gesto de riscos e questes
Escopo,objetivos e componentes do servio
Habilidades, competncias, papels e
responsabilidades
Processos necessrios
Interfaces e dependncias com outros servios
Gesto de equipes, recursos, ferramentas,
tecnologia, oramentos, instalaes necessrias
Gesto de fornecedors e contratos
Relatrios de progresso, revises e reviso do
programa e planos
Planos de comunicao e planos de formao
Prazos, resultados, metas e metas de qualidade
para cada etapa
391 de 477
Construir polticas, planos e exigncias, incluindo o

servio e componente construir planos,
especificaos, controlar e ambientes, tecnologia,
ferramentas, processos, mtodos e mecanismos,
incluindo todas as plataformas
Teste de polticas, planos e exigncias, incluindo
teste ambientes, tecnologia, ferramentas,
processos, mtodos e mecanismos
O teste deve incluir:
Testes funcionais
Testes de componentes, incluindo todos os
fornecedors, contratos e fornecidos
externamente produtos e servios de apoio
Usurio aceitao e usabilidade teste
Compatibilidade de sistemas e testes de
integrao
Servio e o desempenho dos componentes
e testes de capacidade
Testes de resilincia e continuidade
Servio Plano
de Aceitao
Operacional
Global operacional estratgia, objectivos, a poltica,

avaliao de risco e os planos incluindo:
Critrios de
aceitao de
servios
Falha, Alarme e categorizao evento,

processamento e teste
Servio e componente, segurana e
integridade teste
Testes de liberao, logstica e distribuio
Testes de Gesto, incluindo controlar,
Monitorar, medir e informar, juntamente
com apoio, A recuperao de toda a
programao e processamento em lote e
Poltica de implementao, liberar polticas, planos
e exigncias, incluindo logstica, desenvolvimento,
Roll-out, estadiamento, ambientes de implantao,
a mudana cultural, mudana organizacional,
tecnologia, ferramentas, processoes, a abordagem,
mtodos e mecanismos, incluindo todas as
plataformas, habilidade, conhecimento e
transferncia de competncias e de
desenvolvimento, fornecedor e contrato transio,
Migrao de dados e converso
Interface e dependncia gesto e planejamento

Eventos, relatrios, problemas no servio, incluindo
todos os mudars, lanamentos, incidentes
resolvidos, problemas e erros conhecidos, includos
dentro do servio e quaisquer erros, problemas ou
no-conformidades dentro do novo servio
Servio final aceitao
Desenvolvimento e utilizao de Critrios de aceitao de

servios (SAC) para a progresso atravs de cada estgio
do ciclo de vida do servio, incluindo:
Todos os ambientes
Garantir e piloto critrios e perodos
Tabela A.1 contedo da embalagem Design de Servios
392 de 477
Apndice B: Critrios de aceitao do servio (exemplo)

O Critrios de aceitao de servios (SAC) um conjunto de critrios usados
para garantir que a servio cumpre a sua funcionalidade esperada e qualidade e
que o provedor de servios est pronto para entregar o novo servio, uma vez
que tenha sido implantado.
Critrios
Responsabilidade
Ter a data do "go-live" e do prazo de garantia acordado com todas

as partes envolvidas, juntamente com os critrios de aceitao
finais?
Alterar, Nvel de servio
Tem o desenvolvimento projeto e agendar sido documentado

concordou e divulgada a todos os funcionrios afetados?
Incidente mudana,
Tem o SLA / SLR sido analisados, revisados e acordados com

todas as partes interessadas?
Nvel de servio
Tem o servio foi inserido / atualizado no Catlogo de

Servios/Portflio de Servios dentro do CMS e apropriado
relaos estabelecidas para todos apoiando componentes?
Nvel de servio de
configurao,
Ter todos clientes e das partes interessadass foram identificados e

registrados no CMS?
Nvel de servio, Relao

Profissional
Ter todos os riscos operacionais associados execuo do novo

servio foi avaliado e aes de mitigao concluda quando
apropriado?
Continuidade de
Negcios, disponibilidade
Tem de contingncia e fail-over medidas foi testado com sucesso e

adicionado ao total resilincia testar horrio?
Continuidade de
Negcios, disponibilidade
Tudo pode SLA / alvos SLR ser monitorado, medido, relatados e

revistos, incluindo disponibilidade e atuao?
Nvel de servio,
Disponibilidade
Ter todos usurios foram identificados / aprovada e suas contas

apropriadas criado por eles?
Gesto de Contas
Pode tudo carga de trabalho caractersticas de desempenho, e

capacidade alvos ser medidos e incorporados Plano de
capacidades?
Capacidade
Ter todos os processos operacionais, horrios e procedimentos foi

acordado, documentao do site testadas, documentadas e
aceitas (por exemplo, apoios, limpeza, arquivamento, reteno)?
Operaes de
Continuidade de
Negcios,
Ter todos os trabalhos de grupo e requisitos de impresso foi

acordado, testado, documentado e aceito?
Operaes
Ter todos os planos de teste foi completado com sucesso?
Test Manager
Ter todos segurana verificaes e testes foram competiu com

sucesso?
Cumprimento de
Segurana
393 de 477
So apropriadas monitoramento e ferramentas de medio e

procedimentos para monitorar o novo servio, Juntamente com um
fora-de-hora o apoio Rota?
Sistemas de Gesto
Tenha tudo operacional contnuo carga de trabalhos e custars foi

identificado e aprovado?
Operaes, TI Finanas
So todos os servios e componentes custo operacionals

entendidos e incorporados financeiro processoes e o custo
modelo?
TI Finanas
Ter incidente e categorias de problemas e processos foram

analisados e revistos para o novo servio, juntamente com os erros
conhecidos e deficincias?
Incidente Relatrios de
Problemas,
Ter todos os novos fornecedors foram identificados e seus

associados contratos elaborado em conformidade?
Contrato e Gesto de
Fornecedores
Ter todos os mecanismos de apoio foram revistos e revisados SLAs, SLRs, OLAs e contratos acordados, com documentao
aceita por todas as equipes (incluindo fornecedors, equipes de
apoio, Gesto de Fornecedores, Equipes de desenvolvimento e
suporte de aplicaes)?
Gerente de Projeto
Tem apropriado suporte tcnico documentao foi apresentada e

aceita por incidentes, problemas e todas as equipes de suporte de
TI?
Problema incidente,
Ter todos os RFCs e Registro de Lanamentos foi autorizado e

atualizado?
Mudar
Ter todos os servios, SLA, SLR, OLA e detalhes do contrato,

juntamente com toda a aplicaos infra-estrutura e componente
detalhes, sido inscrita na CMS?
Gerenciamento de
Projetos, Configurao de
equipes de suporte
J apropriadas S / W licenas foram compradas ou realocados

licenas usado?
Configurao
Algum novos H / W componentes foi armazenado no DL com

detalhes gravados na CMS?
Configurao
Ter todos os novos S / W componentes foi apresentado no DL com

detalhes gravados na CMS?
Configurao
Ter todos os planos de manuteno e atualizao foi acordado,

juntamente com liberar polticas, freqncias e mecanismos?
Liberao e Implantao
Ter todos os usurios foram treinados, e tem usurio

documentao foi aceita e fornecido para todos os usurios?
Gerente de Projeto
So todos relaos, interfaces e dependncias com todos os

outros sistemas internos e externos e servios documentado,
concordou e apoiou?
Gerente de Projeto
J os gerentes de negcio apropriados assinado aceitao do

novo servio?
Gerente de Projeto
Tabela B.1 critrios de aceitao de servio
394 de 477
Anexo C: modelos de processo de documentao

(exemplo)
C1 Process Framework
Ao projetar uma nova ou revista processo para qualquer um dos Servio de
Gesto de processos, recomenda-se que um processo de especificao ou
quadro ser produzido. A especificao deve ser mantida a um nvel bastante
elevado, mas precisa de detalhe do escopo e interfaces do processo. Mais
detalhada e procedimentos instruo de trabalhos tambm sero necessrios
para garantir a consistncia do processo e sua aplicao. Os contedos tpicos
de uma estrutura de processo ou especificao so:
Nome do processo, descrio e administrao (administrao

documentao: verso, Controle de alteraes, autor, etc)
Viso e declaraes de misso
Objetivos
Escopo e termos de referncia
Viso geral do processo:
o Descrio e panormica
o Entradas
o Procedimentos
o Atividades
o Sadas
o Desencadeia
o Ferramentas e outros entregas
o Comunicao
Papels e responsabilidades:
o Operacional responsabilidades
o Proprietrio do processo
o Membros de processo
o Processo usurios
o Outros papis
Documentao associada e referncias
Interfaces e dependncias para:
o Outros processos de SM
o Outros processos de TI
o Processo de negcioes
Medies do processo e mtricos: comentrios, avaliaos e auditars
Entregas e relatrios produzidos pelo processo:
o Freqncia
o Contedo
o Distribuio
Glossrio, siglas e referncias.
395 de 477
Anexo D: Design e Planejamento documentos e seus

contedos
Este anexo contm detalhes sugeridos dos tipos de documentos de design,
planos e documentos padres que devem ser produzidos e mantidos por ela, e
tambm descreve os contedos mnimos de arquiteturas de TI e planos. No
entanto, deve-se ressaltar mais uma vez que todos estes documentos devem
ser frequente e regularmente revisto e revisado e deve ser usada ativamente
dentro de processos de TI e dirias procedimentos.
Tm tambm de ser mantida em alinhamento com todos os documentos
semelhantes em uso no interior da negcio e o conjunto organizao.
396 de 477
D1 Design e documentos de arquitetura e padres

Os documentos de projeto e padres desenvolvidos e mantidos pela TI deve
incluir:
Design e planejamento normas, polticas, processos e procedimentos

Arquiteturas de aplicaes, mtodos e padres de projeto
Requisitos de negcios, avaliao de impacto nos negcios e priorizao
e caso de negcio mtodos e normas
Funcionais padres requisitos
Sor e padres da ITT e os mtodos para a sua avaliao
Arquiteturas de TI de tecnologia, padres de projeto e polticas, que
abrangem todas as reas de tecnologia, incluindo mainframe, servidor,
Desktop, laptop, aparelhos portteis e mveis, sistemas de telefonia,
armazenamento, apoio, Rede e endereamento de rede
Sistemas operacionais, software de sistemas, servios pblicos e de
firmware arquiteturas, projeto de polticas e normas
Dados, informaes e banco de dados arquiteturas, polticas e padres
de projeto, incluindo os fluxos de informao, Gesto do Conhecimento,
Informaes segurana e de acesso, gerenciamento de dados,
armazenamento de dados, armazenamento de dados, anlise de dados e
minerao de dados
Sistema de gestos, plataformas, ferramentas e agentes e suas
arquiteturas e polticas e padres de projeto, incluindo a funcionalidade,
domnios, interfaces, protocolos de gesto, evento e tratamento de
alarmes e automao, categorizao e escalada
Cabeamento arquiteturas, desenhos e padres
Desenvolvimento de padres, mtodos e polticas
Mtodos de ensaio, polticas e padres
Entrega, aceitao e sign-off normas e mtodos
Partners, fornecedor e as normas contratuais e polticas
Polticas de comunicao e padres
Documento e documento padres de biblioteca e polticas
Internet e intranet arquiteturas, padres de projeto e polticas, incluindo
e-commerce e e-business
E-mail e groupware arquiteturas, padres de projeto e polticas
Exigncias ambientais, polticas e padres de projeto
TI segurana polticas e padres de projeto, incluindo walling incndio,
verificao de vrus, servio e nveis de acesso ao sistema, mtodos e
polticas, acesso remoto, usurio conta e gerenciamento de senhas
Normas de contratao e polticas
Programa normas e polticas, mtodos de projeto e projeto planejamento
e avaliao de polticas e normas
Qualidade normas e polticas
Usurio interfaces e padres.
397 de 477
D2 planos de TI
TI deve produzir e manter uma srie de planos, a fim de coordenar e gerir a
geral desenvolvimento e qualidade dos De servios de TIs. Estes devem incluir:
Planos de negcios de TI: Os planos de negcios para o

desenvolvimento de servios de TI
Estratgico planos: Fornecer planos para a realizao do longo prazo
viso, Misso e objetivos de TI
Ttico planos: Fornecer planos para a realizao do curto e mdio prazo,
a viso, misso e objectivos das TIC
Planos funcionais: Fornecer planos para a realizao da misso, viso e
objetivos das principais funes de TI
Planos operacionais: Fornecimento de planos para o desenvolvimento e
aperfeioamento de operacional processos, procedimentos e mtodos
Planos de projetos e programas:
o TI e negcios programas
o Projetos de TI
Processos de planos e programas:
o Objetivos e metas
o Melhoria de processos
o Papels e responsabilidades
Transio planos:
o Construir planos e horrios
o Testes e liberar horrios
o Ambientes de desenvolvimento e teste
o Transio horrios
Servio de Gesto de planos:
o Plano de Qualidade de Servio (s)
o Planos de Melhoria de servios e programas
o Planos Financeiros e oramentos
o Continuidade do Servio de TI e Planos de Recuperao e Planos
de Continuidade de Negcios
o Plano de capacidade
o Plano de disponibilidade
o Planos de Servio de Apoio
o Planos de Lanamento e horrios
o Os planos de gesto de configurao
o Alterar planos de gesto e os Alterar agendamento
o Service Desk, Gerenciamento de Incidentes e Gerenciamento de
Problemas Planos
o Fornecedor e planos de contrato.
Todos planos de TI deve ser desenvolvido, mantido e revisto em linha dentro da

negcio e o conjunto organizao. Isso deve ser feito usando o estudo de
impacto processo de um sistema adequado Gesto da Mudana. As
398 de 477
organizaes devem tomar os requisitos legais para sistemas em considerao

e tambm olhar para as normas internacionais e nacionais de regulao ea
necessidade de corporativo governo.
399 de 477
Apndice E: arquiteturas e padres ambientais

Este anexo contm detalhes de arquiteturas e padres ambientais. Toda
organizao deve produzir um ambiente poltica para a localizao de
equipamentos, com o mnimo de normas acordadas para as concentraes
particulares de equipamentos. Alm disso, os padres mnimos devem ser
acordados para a proteco de edifcios que contm equipamentos e conchas
sala de equipamentos. As tabelas que se seguem cobrem os principais aspectos
que precisam ser considerados, com caractersticas de exemplo.
Edifcio tabela E.1 / site

Acesso
Permetros de segurana, entradas seguras, pista de auditoria
Construo e
proteo de site
Segurana cercas, cmeras de vdeo, movimento e detectores de intruso

portas e janelas, alarmes, protetores de raios, bom ambiente de trabalho
(padro)
Entrada
Mltiplos pontos controlados de entrada
Ambiente externo
Minimizar riscos externos
Servios
Sempre que possvel e justificvel, rotas alternativas e fornecedors para

todos os servios essenciais, incluindo servios de rede
Tabela E.2 quarto equipamento principal

Acesso
Entrada controlado e seguro, combinao, carto magntico, cmera de

vdeo (se o negcio crtica e autnoma)
Localizao
Primeiro andar, sempre que possvel, sem riscos de gua, gs, qumicos,
ou de fogo nas imediaes, acima, abaixo ou ao lado
Visibilidade
Sem sinalizao, sem janelas externas
Concha
Casca externa: impermevel, hermtico, prova de som, resistente ao

fogo (0,5 horas a 4 horas, dependendo da criticidade)
Entrega de
equipamentos
Pr adequadaviso deve ser feito para a entrega e posicionamento dos

equipamentos delicados grande
Piso interno
Selado
Sala de planta
separado
Uninterruptible Power Supply (UPS). Alimentao elctrica e de

comutao, unidades de tratamento de ar, duas unidades e quartos se o
negcio crtico
Externo
Gerador para grandes centros de dados e sistemas crticos de negcio
400 de 477
Tabela E.3 grandes centros de dados

Acesso

Temperatura
Controle rigoroso, 22 ( 3 ). Fornecer para at 550W/m2. 6 variao ao

longo do quarto e um mximo de 6 graus por hora
Controle de
umidade
Rigoroso controle: 50% ( 10%)
A qualidade do ar
Presso positiva, filtrada ingesto de poluio gasosa baixo (por exemplo,

o dixido de enxofre 0,14 ppm), os nveis de p de partculas de 1
micron>, menos do que 5 x 106 particles/m3. Desactivao automtica de
fumaa ou de deteco de incndio
Poder
Unidade de Distribuio de Energia (PDU), com a oferta de trs fases para

no-switched caixas, uma por parte de equipamento, com as devidas
classificados disjuntores para cada oferta. Em alternativa, as tiras de
distribuio aprovados potncia pode ser utilizada. Equilibradas cargas
trifsicas. UPS (online ou linha interativa com Simple Network
Management Protocol (SNMP) Management) para garantir a tenso
fornecida de 5% da classificao com o impulso mnimo, quedas, picos
e mais / sob condies de tenso
Pisos falsos
Antiesttica, ladrilhos elevvel 600 x 600 milmetros em pedestais, com

pedestais alternativas aparafusado ao cho slido. Mnimo de folga 600
milmetros para o cho slido. Cargas no cho de at 5kN/m2 com um
mnimo recomendado de 3 m entre o piso eo teto falso
Paredes internas
Do cho ao teto falso, resistente ao fogo, mas com o fluxo de ar acima e

abaixo do nvel do cho
Deteco de
incndio /
preveno
HSSD ou VESDA alarme multi-nvel com auto FM200 (ou substituio

halon alternativa) a liberao de 'duplo-knock "deteco
Detectores
ambientais
Para fumaa, temperatura, potncia, umidade, gua e intruso com alarme

automtico capacidade. Locais painis de alarme com painis repetidores
e capacidade de alarme tambm remoto
Iluminao
Normal nveis de iluminao de teto com iluminao de emergncia em

caso de falha de energia
Segurana da
energia
Terra limpa deve ser fornecido no PDU e para todos os equipamentos.

Com claramente marcado remotas de desligamento botes em cada
sada. Tomadas de energia suja, claramente marcado, tambm deve ser
fornecido
Extintores de
incndio
Eltrica suficiente extintores com sinalizao adequada e procedimentos
Vibrao
Vibraes deve ser mnima dentro da rea completa
401 de 477
Interferncia
eletromagntica
Interferncia mnima deve estar presente (1,5 V / m de intensidade de

campo ambiente)
Instalaes
Todos os equipamentos devem ser fornecidos e instalados por pessoal

qualificado fornecedors e instaladores apropriados para padres eltricos
e de sade e segurana
As conexes de
rede
O espao de equipamento deve ser ligado com inundaes adequada

capacidade para crescimento razovel. Todos os cabos devem ser
colocados e fixados a suportes de cabos adequados
Desastre
recuperao
Planos de recuperao totalmente testados devem ser desenvolvidos para

todos os centros de dados importantes, incluindo o uso de sites de standby e equipamentos
Tabela E.4 centros de dados regionais e centros de

equipamento principal
Acesso

Temperatura
O controlo da temperatura, 22 ( 5 ), prefervel
Controle de
umidade
Rigoroso controle: 50% ( 10%), de preferncia
A qualidade do ar
Presso positiva, filtrada ingesto de poluio gasosa baixo (por exemplo,

o dixido de enxofre 0,14 ppm), os nveis de p de partculas de 1
micron>, menos do que 5 x 106 particles/m3. Desactivao automtica de
fumaa ou de deteco de incndio
Poder
PDU com alimentao trifsica no-switched caixas, uma por parte de

equipamento, com as devidas classificados disjuntores para cada oferta.
Em alternativa, as tiras de distribuio aprovados potncia pode ser
utilizada. Equilibradas cargas trifsicas. Sala de UPS para garantir a
tenso fornecida de 5% da classificao com o impulso mnimo,
quedas, picos e mais / sob condies de tenso
Pisos falsos
Antiesttica, ladrilhos elevvel 600 x 600 milmetros em pedestais, com

pedestais alternativas aparafusado ao cho slido. Mnimo de folga 600
milmetros para o cho slido. Cargas no cho de at 5kN/m2 com um
mnimo recomendado de 3 m entre o piso eo teto falso
Paredes internas
Do cho ao teto falso, resistente ao fogo, mas com o fluxo de ar acima e

abaixo do nvel do cho
Deteco de
incndio /
preveno
Geralmente deteco de incndio, mas no a supresso, embora HSSD

ou VESDA alarme multi-nvel com auto FM200 (ou substituio halon
alternativa) a liberao de 'duplo-knock' deteco pode ser includo se
sistemas crticos de negcio esto contidas
Detectores
ambientais
Para fumaa, temperatura, potncia, umidade, gua e intruso com

capacidade de alarme automtico
Iluminao
402 de 477

Segurana da
energia
Terra limpa deve ser fornecido no PDU e para todos os equipamentos.

Com claramente marcado remotas de desligamento botes em cada
sada. Tomadas de energia suja, claramente marcado, tambm deve ser
fornecido
Extintores de
incndio
Vibrao
Interferncia
eletromagntica

campo ambiente)
Instalaes

qualificado fornecedors e instaladores apropriados para padres eltricos
e de sade e segurana
As conexes de
rede
O espao de equipamento deve ser cheias com fio com capacidade

adequada para um crescimento razovel. Todos os cabos devem ser
A recuperao de
desastres
Planos de recuperao totalmente testados devem ser desenvolvidos para

todos os centros de dados regionais, incluindo o uso de sites de stand-by e
equipamentos sempre que necessrio
Servidor Tabela E.5 ou salas de equipamentos de rede

Acesso
Entrada controlado e seguro, pelo fechamento de combinao, carto

magntico ou chave e fechadura. Em alguns casos, o equipamento pode
ser contido em escritrios abertos em prateleiras ou armrios fechados
Temperatura
Ambiente de escritrio normal, mas se em quartos fechados / bloqueado

ventilao adequada deve ser fornecida
Controle de umidade
Ambiente de escritrio normal
A qualidade do ar
Ambiente de escritrio normal
Poder
Fonte de energia limpa, com uma potncia fornecida pela UPS para o
rack completo
Pisos falsos
Mnimo recomendado de 3 m entre o piso eo teto com todos os cabos

fixados no compartimento multi-trunking
Paredes internas
Sempre que possvel todas as paredes devem ser resistentes ao fogo
Deteco de
incndio / preveno
Normais de escritrio de fumaa / incndio sistemas de deteco, a

menos que grandes concentraes de equipamentos
Detectores
ambientais
Para o fumo, o poder intruso, com capacidade de alarme sonoro
Iluminao

403 de 477
Segurana da
energia
Terra limpa devem ser fornecidos para todos os equipamentos. Com

claramente marcadas poder-off botes
Extintores de
incndio
Vibrao
Interferncia
eletromagntica

campo ambiente)
Instalaes

qualificado fornecedors e instaladores apropriados para padres
eltricos e de sade e segurana
As conexes de rede
O espao de equipamento deve ser ligado com inundaes adequada

capacidade para crescimento razovel. Todos os cabos devem ser
A recuperao de
desastres
Planos de recuperao totalmente testados deve ser desenvolvida se for

o caso
Tabela E.6 ambientes de escritrio

Acesso
Todos os escritrios devem ter o acesso adequado seguro dependendo

do negcio, a informao e os equipamentos neles contidas
Qualidade de
iluminao,
temperatura,
umidade e ar
Um ambiente de escritrio normal limpo, confortvel e bem organizado,

em conformidade com os requisitos da organizao de sade, segurana
e meio ambiente
Poder
Fonte de energia limpa para todos os equipamentos de informtica, com

instalaes UPS se for o caso
Pisos falsos
Preferido, se possvel, mas todos os cabos devem estar contidos dentro

de trunking apropriado
Deteco de
incndio / preveno
e extintores
Normais de escritrio sistemas de fumaa / incndio de deteco de

intruso e sistemas de alerta, a menos que haja grandes concentraes
de equipamento. Suficientes extintores de incndio do tipo apropriado,
com sinalizao adequada e procedimentos
As conexes de
rede
O espao de escritrio deve ser preferencialmente inundaes fios com

capacidade adequada para um crescimento razovel. Todos os cabos
devem ser colocados e fixados a suportes de cabos apropriados. Todos
os equipamentos de rede deve ser fixada em armrios ou gabinetes
seguras
Desastre
recuperao
Planos de recuperao totalmente testados deve ser desenvolvida se for

o caso
404 de 477
Apndice F: Amostra SLA e OLA

Este anexo contm exemplos de SLAs e OLAs e seus contedos. No
recomendvel que todo SLA ou OLA deve necessariamente conter todas as
sees listadas nos documentos de exemplo a seguir. Sugere-se que estas
reas so considerados na preparao documento modelos, mas que eles s
esto incorporados nos documentos reais prprios onde eles so apropriados e
relevantes. Assim, as linhas a seguir devem ser considerados apenas como
diretrizs ou listas de verificao.
Acordo de nvel (SLA - Amostra)

Este acordo feito entre ............................................. .................... e
.................................................. ........................
O acordo abrange o prviso e apoio dos servios do ABC, que ..... (Breve
servio descrio).
Este acordo vlido por 12 meses a partir da (data) at (data). O acordo ser
revisto anualmente. Pequenas mudanas podem ser registrados no formulrio,
no final do contrato, desde que sejam mutuamente aprovado pelos dois partidos
e gerida atravs do Gesto da Mudana processo.
Signatrios:
Descrio do servio:
O Servio de ABC consiste .... (Uma descrio mais completa para incluir
funes de negcio, entregas e todas as informaes relevantes para descrever
o servio e sua escala, impacto e prioridade para a negcio).
mbito do acordo:
O que coberto no contrato e que est excludo?
405 de 477
Horas de servio:
Uma descrio das horas que o clientes pode esperar que o servio esteja
disponvel (por exemplo, 7 24 365, das 08:00 s 18:00 - de segunda a sextafeira).
Condies especiais para excees (por exemplo, fins de semana, feriados) e
procedimentos para solicitar extenses de servio (que para entrar em contato normalmente o Servio de Recepo - e que perodos de aviso prvio so
necessrios).
Isto pode incluir um calendrio de servio ou referncia a um calendrio servio.
Detalhes de qualquer slots pr-acordados de manuteno ou limpeza, se estes
impacto sobre as horas de servio, juntamente com detalhes de como as
interrupes de outros potenciais devem ser negociadas e acordadas - por quem
e perodos de aviso prvio etc
Procedimentos para solicitar alteraes permanentes horas de servio.
Disponibilidade do servio:
O alvo disponibilidade nveis que o Provedor de servios de TI vai procurar para
entregar dentro do horrio de servio acordados. Metas de disponibilidade
dentro de horas de servio acordados, normalmente expressa em percentagem
(por exemplo, 99,5%), os perodos de medio, mtodo e clculos devem ser
estipuladas. Este valor pode ser expresso para o geral servio, Servios que
sustentam e crticas componentes ou todos os trs. No entanto, difcil
relacionar essas figuras disponibilidade simplistas percentuais de servio
qualidade, Ou para atividades de negcios dos clientes. , portanto, muitas
vezes melhor do que tentar medir indisponibilidade do servio em termos de
incapacidade do cliente para realizar suas atividades de negcios. Por exemplo,
"as vendas so imediatamente afetados por uma falha de TI para fornecer um
servio de apoio adequado POS '. Esta forte ligao entre o De servios de TI e
do cliente processo de negcioes um sinal de maturidade em ambos SLM eo
Gerenciamento de Disponibilidade processos.
Detalhes acordados de como e em que ponto isso vai ser medido e indicado, e
sobre o que concordou perodo tambm deve ser documentada.
Confiabilidade:
O nmero mximo de quebras de servio que podem ser tolerados dentro de um
certo perodo (pode ser definido como o nmero de intervalos, por exemplo,
quatro por ano, ou como um Tempo mdio entre falhas (MTBF) ou Tempo Mdio
Entre Incidentes Sistemas (TMEIS)).
406 de 477
Definio do que constitui um 'break' e como estes sero monitoradas e

registradas.
Atendimento ao cliente:
Detalhes de como entrar em contato com a Central de Servio, as horas que vai
estar disponvel, o apoio est disponvel e horas o que fazer fora do horrio de
obter assistncia (por exemplo, chamada de apoio, assistncia de terceiros, etc)
devem ser documentados. O SLA tambm podem incluir referncia a Internet /
Intranet Auto-ajuda e / ou registro de incidentes. Mtricos e medidas devem ser
includos, tais como metas de telefone de chamada de resposta (nmero de
toques, chamadas no atendidas, etc)
Metas para Incidente tempos de resposta (quanto tempo ser antes que algum
comea a atender o cliente - pode incluir o tempo de viagem, etc)
A definio necessria de "resposta" - uma chamada telefnica de volta para
a cliente ou uma visita ao local? - Se for caso disso.
Arranjos para solicitar extenses de apoio, incluindo os perodos de aviso prvio
(pedido por exemplo, deve ser feito para a Central de Servio 12 horas para uma
extenso da noite, at s 12 horas de quinta-feira para uma extenso final de
semana)
Nota. Tanto a resposta de incidentes e resoluo vezes ser baseado em
qualquer impacto incidente /prioridade cdigos so usados - detalhes da
classificao de Incidentes tambm devem ser includos aqui.
Nota. Em alguns casos, pode ser apropriado para fazer referncia para terceiros
contactos e contratos e OLAs - mas no como uma forma de desviar a
responsabilidade.
Pontos de contacto e de escalao:

Detalhes dos contatos dentro de cada uma das partes envolvidas no acordo e
que a escalada processoes e pontos de contacto. Isto tambm deve incluir a
definio de uma denncia e procedimento para o gerenciamento de
reclamaes.
Desempenho do servio:
Detalhes da esperada capacidade de resposta da estao de trabalho IT alvo de
servio (por exemplo, tempo de respostas para a mdia, ou o tempo de resposta
mximo de estaes de trabalho, s vezes expressas como um percentual - por
exemplo, 95% dentro de dois segundos), detalhes do servio esperado
407 de 477
rendimento em que as metas so baseadas, e qualquer limiars que possam

invalidar as metas).
Isto deve incluir a indicao dos volumes de trfego provveis, a atividade de
transferncia, restries e dependncias (por exemplo, o nmero de transaos
para serem processados, nmero de concorrente usurios, e quantidade de
dados a serem transmitidos atravs da rede). Isto importante de modo a que
atuao questes que foram causados pela excessiva rendimento fora dos
termos do acordo podem ser identificados.
Turnaround vezes lote:

Se necessrio, a indicao de qualquer lote tempos de resposta, tempo de
concluso e chave entregas, incluindo os tempos de entrega de entrada e
horrio e local para a entrega do produto se for o caso.
Funcionalidade (se for o caso):

Detalhes da funcionalidade mnima a ser fornecido e do nmero de erros de
tipos especficos que podem ser tolerados antes da SLA violada. Dever incluir
os nveis de severidade e perodo de referncia.
Gesto da Mudana:
Breve meno e / ou referncia para a organizao do Gesto da Mudana
procedimentos que devem ser seguidas - apenas para reforar observncia.
Tambm tem como alvo para a aprovao, a manipulao e aplicao de RFCs,
geralmente com base no categoria ou urgncia/ Prioridade do alterar, tambm
devem ser includos e os detalhes de todas as alteraes conhecidas que tero
impacto sobre o acordo, se houver.
Continuidade de servio:
Breve meno e / ou referncia para os planos da organizao de continuidade
de servio, juntamente com detalhes de como o SLA pode ser afetado ou
referncia a um SLA Continuidade separado, contendo detalhes de quaisquer
metas de diminuio ou alterao deve ocorrer uma situao de desastre.
Detalhes de quaisquer responsabilidades especficas de ambos os lados (por
exemplo, dados apoio, Fora do local de armazenamento). Tambm detalhes da
invocao de planos e cobertura de todos segurana questes, particularmente
as responsabilidades do cliente (por exemplo, a coordenao de atividades de
negcios, documentao de negcios, backup de PCs independentes,
alteraes de senha).
408 de 477
Segurana:
Uma breve referncia e / ou de referncia para o organizao'S Poltica de
Segurana (Abrangendo questes como controles de senha, segurana
violaes, de software no autorizado, vrus etc.) Pormenores de quaisquer
responsabilidades especficas de ambos os lados (por exemplo, proteo contra
vrus, firewalls).
Impresso:
Pormenores de quaisquer condies especiais de impresso ou impressoras
(por exemplo, imprimir detalhes de distribuio, a notificao de grandes
tiragens centralizados, ou manipulao de qualquer papelaria de alto valor
especial).
Responsabilidades:
Detalhes das responsabilidades das partes envolvidas no mbito do servio e
suas responsabilidades acordadas, incluindo a provedor de servios, O cliente e
o usurios.
Carregamento (se aplicvel):

Detalhes de quaisquer carregamento frmulas utilizadas, cobrando perodos, ou
de referncia para cobrana poltica documentos, junto com a facturao
procedimentos e as condies de pagamento, etc devem ser includos. Isto
tambm deve incluir detalhes de quaisquer sanes financeiras ou bnus que
sero pagos se as metas de servio no atender s expectativas. Quais sero
as penalidades / bnus ser e como sero calculados, concordou e recolhidos /
pago (mais apropriado para terceiros situaes). Se o SLA abrange uma
terceirizao relao, As taxas devem ser detalhados em um apndice, como
so frequentemente cobertos por comerciais em-confiana disposies.
Note-se que as clusulas de penalizao podem criar suas prprias dificuldades.
Eles podem constituir um obstculo para parcerias se injustamente invocado por
um detalhe tcnico e tambm pode fazer provedor de servios funcionrios
dispostos a admitir erros, por medo de sanes sendo impostas. Isso pode, a
menos que usado corretamente, ser uma barreira para o desenvolvimento de
relaes eficazes e de resoluo de problemas.
Servio de relatrios e analisar:

O contedo, freqncia, contedo, o calendrio e distribuio de relatrios de
servios, ea frequncia de reunies de avaliao associados servios. Tambm
409 de 477
detalhes de como e quando os SLAs e as metas de associados ser analisada e

possivelmente revistas, incluindo quem estar envolvido e em que capacidade.
Glossrio:
Explicao de eventuais abreviaes inevitveis ou terminologia utilizada, para
auxiliar a compreenso do cliente.
Folha de alterao:
Para incluir um registro de todas as alteraes acordadas, com detalhes de
emendas, as datas e os signatrios. Tambm deve conter detalhes de uma
completa mudar a histria do documento e sua revisos.
Deve notar-se que o SLA contedo dadas acima so apenas exemplos. Eles
no devem ser consideradas exaustivas ou obrigatria, mas eles fornecem um
bom ponto de partida.
Acordo de Nvel Operacional (ANO - Amostra)

Este acordo feito entre ............................................. .................... e
.................................................. .......................
O acordo abrange o prviso do servio de suporte proporcionando .....
(Descrio breve servio).
Este acordo vlido por 12 meses a partir da (data) at (data).
O acordo ser revisto anualmente. Pequenas mudanas podem ser registrados
no formulrio, no final do contrato, desde que sejam mutuamente aprovado
pelos dois partidos e gerida atravs do Gesto da Mudana processo.
Signatrios:
Detalhes de alteraes anteriores:

Suporte Descrio do servio:
Explicao completa e detalhes do apoio servio sendo prestado.
410 de 477
mbito do acordo:
O que coberto no contrato e que est excludo?
Horas de servio:
Uma descrio das horas para que o servio seja prestado apoio.
Metas de servio:
Os objectivos para o proviso do servio de suporte e prestao de informaes
e reviso processoes e frequncia.
Pontos de contacto e de escalao:

Detalhes dos contatos dentro de cada uma das partes envolvidas no acordo e
que a escalada processos e pontos de contato.
Posto de servio e tempos de resposta a incidentes e

responsabilidades:
As responsabilidades e as metas acordadas para o progresso e resoluo de
incidentes e de apoio do Service Desk.
Problema tempos de resposta e responsabilidades:

As responsabilidades e as metas acordadas para o progresso e resoluo de
problemas.
Gesto da Mudana:
As responsabilidades e as metas acordadas para o progresso e implementao
de mudars.
Gerenciamento de lanamento:
As responsabilidades e as metas acordadas para o progresso e implementao
de lanamentos.
Gerenciamento de Configurao:
As responsabilidades para a propriedade, proviso e manuteno de
informaes precisas Gerenciamento da Configurao informao.
411 de 477
Gesto de Segurana da Informao:

As responsabilidades e as metas acordadas para o apoio da Poltica de
Segurana(S) e o Gesto de Segurana da Informao processo.
Gerenciamento de Disponibilidade:
A responsabilidade por garantir que todos os componentes dentro do seu
domnio de apoio so dirigidos e apoiados para atender e continuar a atender
todos os servios e metas de disponibilidade de componentes.
Gesto da Continuidade de servio:

A responsabilidade por garantir que todos os componentes dentro de seu
domnio de apoio tm up-to-date e testado recuperao planos que suportam os
requisitos de negcios acordados e documentados. Isto deve incluir a
assistncia com o tcnico avaliao de risco e sua posterior gesto e mitigao.
Gerenciamento da Capacidade:
Responsabilidade para suportar as necessidades da Gerenciamento da
Capacidade processo dentro do escopo acordado de seu domnio tcnico.
Gerenciamento de Nvel de Servio:

Assistncia com a definio e acordo de metas adequadas dentro de SLAs,
SLRs e Olas, sobre os componentes dentro da escopo do seu domnio tcnico.
Gesto de Fornecedores:
Assistncia com a gesto de contratos e fornecedors, uma vez mais,
principalmente no mbito do seu domnio tcnico.
Prviso de informaes:
O prviso e manuteno de informaes precisas, incluindo dados financeiros
para todos os componentes dentro do escopo acordado de seu domnio tcnico.
Glossrio:
Explicao de eventuais abreviaes inevitveis ou terminologia utilizada, para
auxiliar a compreenso dos termos contidos no acordo.
412 de 477
Folha de alterao:
Para incluir um registro de todas as alteraes acordadas, com detalhes de
emendas, as datas e os signatrios. Tambm deve conter detalhes de uma
completa mudar a histria do documento e sua revisos.
413 de 477
Anexo G: Catlogo de Servio Exemplo

O Catlogo de Servios documento-chave que contm informaes valiosas
sobre o conjunto completo de servios oferecidos. Ele deve preferencialmente
ser armazenados como um conjunto de "servio" CIs dentro de um CMS,
mantida sob Gesto da Mudana. Como se trata de um conjunto to valiosa de
informao deve estar disponvel a qualquer um dentro da organizao. Cada
novo servio deve ser imediatamente entrou no Catlogo de Servios uma vez
que sua definio inicial dos requisitos foi documentado e acordado. Assim, bem
como os dados abaixo, a Catlogo de Servios deve registrar o estado de cada
servio, atravs dos estgios de seu ciclo de vida definido.
No
me
do
serv
io
Des
cri
o de
Serv
io
Tip
o
de
ser
vi
o
Ser
vio
s de
apoi
o
Propr
ietri
o da
empr
esa
(s)
Unid
ade
de
Neg
cio
s (s)
Ser
vice
Man
age
r (s)
Imp
acto
nos
Neg
cio
s
Ser
vi
o1
Ser
vi
o2
Ser
vi
o3
Ser
vi
o4
Tabela G.1 Catlogo de Servio Exemplo
414 de 477
Prior
idad
e de
neg
cios
S
L
A
Ho
ras
de
ser
vi
o
Cont
atos
Com
erciai
s
Esca
lada
Cont
acto
s
Rela
trio
s de
servi
os
Come
ntrio
s de
servi
os
Segur
ana
Classi
fica
o
Anexo H: O Servio de Gerenciamento quadro maturidade

do processo
A estrutura de maturidade de processo (PMF) pode ser usado tanto como um
quadro para avaliar a maturidade de cada um dos processos de gerenciamento
de servios, individualmente, ou para medir a maturidade da Servio de Gesto
de processo como um todo. Esta uma abordagem que tem sido largamente
utilizado na indstria de TI de um certo nmero de anos, com muitos
proprietrios modelos a ser usado por um certo nmero de organizaos. Este
PMF especial foi desenvolvida para trazer uma abordagem comum e melhores
prticas para a reviso e avaliao Servio de maturidade do processo de
Gesto. Esse quadro, que mostrado na Figura H.1, pode ser utilizado pelas
organizaes para avaliar internamente seus processos de gesto de servios
prprios, bem como de terceiros organizaes trazidos como revisores externos,
avaliadores ou auditores.
Figura H.1 estrutura de maturidade de processo
O uso do FPP na avaliao de Servio de Gesto de processos depende de

uma apreciao do modelo de TI Organizao Crescimento. A maturidade dos
processos de gesto de servios fortemente dependente da fase de
crescimento da organizao de TI como um todo. difcil, se no impossvel,
para desenvolver a maturidade dos processos de gerenciamento de servios
para alm da maturidade e capacidade da organizao de TI em geral. A
415 de 477
maturidade da organizao de TI no apenas dependente da maturidade dos

processos de gerenciamento de servios. Cada nvel requer uma mudana de
uma combinao de elementos, a fim de ser completamente eficazes. Por
conseguinte, uma rever de processos exige uma avaliao para ser concluda
contra as cinco reas de:
Viso e direo
Processo
Pessoas
Tecnologia
Cultura.
Estas so as cinco reas descritas no PMF para avaliar a maturidade do

processo. As caractersticas principais de cada nvel do FPP so como se
segue.
416 de 477
Inicial (Nvel 1)
O processo foi reconhecida, mas no h actividade de gesto pouco ou nenhum
processo e atribudo nenhuma importncia, recursos ou foco dentro da
organizao. Este nvel tambm pode ser descrito como "ad hoc" ou
ocasionalmente at mesmo 'catico'.
Viso e
direo
Fundos mnimos e recursos, com pouca atividade

Resultados no temporria, mantida
Relatos espordicos e comentrios
Processo
Processos vagamente definidas e procedimentos, usado de

forma reativa, quando ocorrem problemas
Processos totalmente reativas
Irregulares, atividades no planejadas
Pessoas
Vagamente definido papels ou responsabilidades
Tecnologia
Processos manuais ou alguns especficos, ferramentas discretas

(bolsas / ilhas)
Cultura
Ferramenta e de base tecnolgica e conduzido com um foco

forte atividade
Nvel Tabela H.1 PMF 1: inicial
417 de 477
Repetitivo (Nvel 2)
O processo tem sido reconhecido e atribudo pouca importncia dos recursos,
ou o foco dentro da operao. Geralmente as atividades relacionadas ao
processo so descoordenados, irregular, sem direo e esto orientados para
processo eficcia.
Viso e direo
Claro no objetivos ou metas formais

Fundos e recursos disponveis
Irregular, no planejada actividades, relatrios e opinies
Processo
Processos e procedimentos definidos

Processo em grande parte reativa
Irregulares, atividades no planejadas
Pessoas
Independente papels e responsabilidades
Tecnologia
Muitas ferramentas discretas, mas a falta de controle

Os dados armazenados em locais separados
Cultura
Produtos e servios de base e conduzido
Nvel Tabela H.2 PMF 2: repetvel
418 de 477
Definido (Nvel 3)
O processo foi reconhecido e est documentado, mas no h nenhum acordo
formal, aceitao ou o reconhecimento de sua papel dentro da operao de TI
como um todo. No entanto, o processo tem um proprietrio do processo,
Objetivos formais e metas com recursos alocados, e est focada no eficincia ,
bem como a eficcia do processo. Relatrios e resultados so armazenados
para referncia futura.
Viso e
direo
Documentados e acordados objetivos formais e metas

Planos publicado formalmente, monitorados e revisados
Bem financiado e dotada dos recursos necessrios
Reporte regular, planejada e opinies
Processo
Processos claramente definidos e bem divulgadas e

procedimentos
Regulares, atividades planejadas
Boa documentao
Ocasionalmente processo proativo
Pessoas
Claramente definidos e acordados papels e responsabilidades

Objetivos e metas formais
Planos de formao formalizados processos
Tecnologia
Coleta de dados contnua com alarme e limiar monitoramento

Dados consolidados retidos e utilizados para formais
planejamento, Previso e tendncias
Cultura
Servio e orientada ao cliente com uma abordagem formal
Tabela H.3 3 Nvel PMF: definido
419 de 477
Gerenciado (Nvel 4)
O processo j foi plenamente reconhecido e aceito em todo TI. o servio
focado e tem objetivos e metas que so baseados em objetivos de negcios e
objetivos. O processo est totalmente definido, gerenciado e tornou-se pr-ativa,
com documentados, interfaces estabelecidas e dependncias com processo de
TI outra.
Viso e
direo
Direo clara, com os objetivos de negcio, objetivos e metas

formais, o progresso medido
Relatrios de gesto eficazes usados ativamente
Planos de processo integradas ligadas ao negcio e planos de TI
Melhorias regulares, planejado e revisado
Processo
Processos bem definidos, procedimentos e padres, includo em

todos os funcionrios de TI descrio do trabalhos
Claramente definidas as interfaces do processo e dependncias
Integrado Servio de Gesto de e sistemas desenvolvimento
processos
Principalmente proativo processo
Pessoas
Inter e intra equipe de processo de trabalho

Responsabilidades claramente definidas em todas as descries
de trabalho de TI
Tecnologia
Medio de monitoramento contnuo e relatrios limiar alertando

para um conjunto centralizado de conjuntos de ferramentas
integradas, bancos de dados e processos
Cultura
Negcios focada com a compreenso das questes mais amplas
Nvel tabela H.4 PMF 4: conseguiu
420 de 477
Otimizao (Nvel 5)
O processo foi plenamente reconhecidas e tem estratgico objetivos e metas
alinhadas com total estratgico objetivos de negcio e de TI. Estes tornaram-se
agora 'institucionalizada' como parte da atividade diria para todos os envolvidos
com o processo. Um processo auto-contido contnua de melhoria estabelecido
como parte do processo, que est agora a desenvolver um preventivo
capacidade.
Viso e
direo
Integrado estratgico planos intimamente ligado com os planos

gerais de negcios, metas e objetivos
A monitorizao contnua, medio, relatrios alertando e
comentrios ligados a um processo contnuo de melhoria
Revises regulares e / ou auditars para eficcia, A eficincia e
observncia
Processo
Parte processos bem definidos e procedimentos da cultura

corporativa
Processo pr-ativo e preventivo
Pessoas
Empresas alinhado objetivos e metas formais ativamente

monitorado, como parte da atividade diria
Funes e responsabilidades parte de uma cultura corporativa
global
Tecnologia
Bem documentado ferramenta global arquitetura com integrao

completa em todas as reas de pessoas, processos e tecnologia
Cultura
Uma atitude de melhoria contnua, juntamente com um

estratgico foco de negcios. A compreenso do valor da TI para
o negcio e os seus papel dentro da empresa cadeia de valor
Nvel tabela H.5 PMF 5: otimizao
Esta estrutura de maturidade est alinhado com o Instituto de Engenharia de

Software Capability Maturity Model Integration (CMMI SEI) e sua maturidade
vrios modelos, incluindo a evoluo CMMI-SVC, que incide sobre a prestao
de servios.
421 de 477
Apndice I: contedo exemplo de uma declarao de

Necessidade (SOR) e / ou concurso (ITT)
O seguinte um exemplo de um conjunto mnimo de contedo que devem ser
includos em uma ou ITT SOR:
A descrio dos servios, produtos e / ou componentes exigido

Todos tcnica relevante especificaos, detalhes e requisitos
Uma SLR quando aplicvel
Disponibilidade,confiana,manuteno e manuteno requisitos
Detalhes de propriedade de hardware, software, edifcios, instalaes, etc
Detalhes da atuao critrios a serem atendidos pelo equipamento e do
fornecedor(S)
Detalhes de todas as normas a serem cumpridas (interna, externa,
nacional e internacional)
Requisitos legais e regulamentares (indstria, nacional, comunitrio e
internacional)
Detalhes de critrios de qualidade
Prazos contratuais, detalhes e requisitos, termos e condies
Todas as consideraes comerciais: custars, acusaes, bnus e
sanes pecunirias e horrios
Interfaces e contatos necessrios
Mtodos de gesto de projetos a serem utilizados
Relatrio, monitoramento e reviso de procedimentos e critrios a serem
utilizados durante e depois da implementao
Fornecedor requisitos e condies
Sub-contratante requisitos
Detalhes de quaisquer termos e condies
Descrio do fornecedor requisitos de resposta:
o Formato
o Critrios
o Condies
o Prazos
o Variaos e omisses
o Responsabilidades e exigncias do cliente
Detalhes de crescimento planejado e possvel
Procedimentos para a manipulao mudars
Detalhes do contedo e estrutura das respostas necessrias.
422 de 477
Anexo J: Os contedos tpicos de um plano de

capacidade
Os teores tpicos de um Plano de capacidade so como se segue.
1 Introduo
Esta seo explica brevemente o pano de fundo desta questo do plano de
capacidade, como foi produzido eo que ele contm. Por exemplo:
A corrente servios, tecnologia e recursos

O organizaoNveis atuais "s de capacidade
Problemas vivenciados ou previstas devido a mais ou a menos de
capacidade
O grau em que nvel de servios esto a ser alcanados
O que mudou desde a ltima edio do plano.
2 Resumo de Gesto
Grande parte do plano de capacidade, por necessidade, contm detalhes
tcnicos que no de interesse para todos os leitores do plano. O resumo de
gesto deve destacar as principais questes, opes, recomendaes e custars.
Pode ser necessrio para produzir um resumo separado documento que contm
os pontos principais de cada uma das sees do plano principal
3 cenrios de negcios
necessrio colocar o plano em contexto da atual e previsto negcio ambiente.
Por exemplo, uma companhia area britnica planejado para mover um grande
nmero de funcionrios em seu edifcio-sede. Um rcio de 1,7 pessoas por
terminal desktop foi previsto. Gerenciamento da Capacidade foi alertado e foi
capaz de calcular o trfego de rede extra que seria o resultado.
importante mencionar explicitamente todas as previses conhecidas de
negcios, de modo que os leitores possam determinar o que est dentro eo que
est fora do escopo do plano. Ela deve incluir o crescimento previsto nos
servios existentes, os servios de potenciais novos e servios existentes
programados para o encerramento.
4 mbito e termos de referncia do plano de
423 de 477
Idealmente, o Plano de capacidade deve abranger todos os recursos de TI. Esta

seo deve nomear explicitamente os elementos do Infra-estrutura de TI que
so includos e aqueles que so excludos, se houver
5 Os mtodos utilizados
O Plano de Capacidade utiliza informaes recolhidas pelos sub-processos.
Esta sub-seo, portanto, deve conter detalhes de como e quando esta
informao foi obtida - por exemplo, previses de negcios obtido a partir de
planos de negcios, carga de trabalho previses obtidas a partir de clientes,
nvel de servio previses obtidas pelo uso de modelagem ferramentas
6 suposies feitas
importante que todas as suposies feitas, particularmente as relativas aos
drivers de negcio para a TI de Capacidade, so destaque no incio do plano. Se
eles so os pilares sobre os quais clculos mais detalhados so construdos,
ento vital que todos os interessados entender isso
7 resumo Servio
A seo de resumo de servio deve incluir:
Pro servio atual e recenteviso: Para cada servio que entregue,

fornecer um perfil de servio. Isto deve incluir rendimento taxas e da
utilizao de recursos resultante - por exemplo, de memria, espao de
armazenamento, taxas de transferncia, o uso do processador e uso de
rede. Curto, as tendncias de mdio e longo prazo devem ser
apresentados aqui.
Previses de servios: Os planos de negcios devem fornecer
Gerenciamento da Capacidade com detalhes dos novos servios
planejados e do crescimento ou contrao no uso dos servios existentes.
Esta sub-seo deve informar sobre novos servios ea morte de sistemas
legados
424 de 477
8 resumo de Recursos
A seo de resumo de recursos deve incluir:
O uso de recursos atual e recente: Esta seco sub-concentra-se na

utilizao de recursos resultantes dos servios. Ele informa, ainda, sobre
as tendncias de curto, mdio e longo prazo no uso de recursos,
discriminadas por plataforma de hardware. Esta informao foi recolhida e
analisada pelos sub-processos de Gerenciamento da Capacidade de
servio e Gerenciamento da Capacidade componente e assim devem
estar prontamente disponveis.
Previses de recursos: Esta sub-seo prev o uso de recursos
provavelmente resultante das previses de servios. Cada cenrio de
negcios acima mencionadas devem ser tratadas aqui. Por exemplo, uma
empresa de carpete atacado no norte da Inglaterra pode prever com
preciso o que o uso do processador de pico e mdia seria antes que
eles decidiram assumir um negcio rival. Ficou provado que uma
atualizao no seria necessrio. Isto foi alimentado para o modelo de
custo, levando a uma tomada de controlo bem sucedido
9 Opes para melhoria do servio

Com base nos resultados da seo anterior, esta seo apresenta as opes
possveis para a melhoria da eficcia e eficincia de prestao de servios. Ele
pode conter opes para mesclar diferentes servios em um nico processador,
a atualizao da rede para aproveitar os avanos tecnolgicos, afinao a
utilizao do recurso ou servio atuao, Reescrevendo sistemas legados, a
compra de novo hardware ou software, etc
10 Custos previstos
O custars associados com estas opes devem ser documentadas aqui. Alm
disso, o custo actual e prevista de fornecimento De servios de TIs devem ser
includas. Na prtica, Gerenciamento da Capacidade obtm grande parte desta
informao a partir da Gesto Financeira processo e do Plano Financeiro de TI.
425 de 477
11 Recomendaes
A seo final do plano deve conter um resumo das recomendaes feitas no ano
anterior plano e seus estado - Por exemplo, rejeitada, planejada, implementada e qualquer variaos a partir do plano. Quaisquer novas recomendaes devem
ser feitas aqui, ou seja, qual das opes mencionadas no plano a preferida, e
as implicaes se o plano e as suas recomendaes no so implementados
tambm devem ser includos.
As recomendaes devem ser quantificados em termos de:
Benefcios de negcios que podem ser esperados

Potencial impacto de levar a cabo as recomendaes
Riscos envolvidos
Recursos exigido
Custo, tanto de set-up e em curso.
426 de 477
Apndice K: Os contedos tpicos de um plano de

recuperao
Os teores tpicos de um plano de recuperao ITSCM so como se segue.
PLANO DE RECUPERAO GENRICO
1 CONTROLE DOCUMENTO
Este documento deve ser mantida para assegurar que os sistemas de infraestrutura e instalaes includos, apropriadamente, apoiar as empresas
recuperao requisitos.
1,1 Distribuio de documentos
Copiar Emitido para Data Posio
1.
2.
3.
4.
1,2 re Documentoviso
Este documento ser revisto a cada X meses.
Reviso atual: data
Prxima reviso: data
Data de reviso Nenhuma verso Resumo das alteraes
427 de 477
428 de 477
1,3 aprovao de documentos

Este documento deve ser aprovada pelo pessoal seguinte:
Nome Ttulo Assinatura
2 INFORMAES DE APOIO
2.1 Introduo
Este documento detalha as instrues e procedimentos que so necessrios a
serem seguidos para recuperar ou manter a operao de sistemas, infraestrutura, servios ou instalaes para manter a continuidade de servio para o
nvel definido ou acordado com o negcio.2.2 A estratgia de recuperao
O sistemas,Infra-estrutura,servios ou instalaes sero recuperados alternativa
sistemas, Infra-estrutura,servios ou instalaes.
Levar cerca de X horas para recuperar o sistemas,Infra-estrutura,servios ou
instalaes. O sistema ser recuperado para o ltimo ponto conhecido de
estabilidade / dados integridade, Que ponto no dia / momento.
O tempo de recuperao necessrio para este sistema, Infra-estrutura, servio
ou instalao :
O tempo de recuperao e os procedimentos para este sistema, Infraestrutura,servio ou facilidade foi testado em ltimo:
429 de 477
2,3 Invocao
O seguinte pessoal est autorizado a invocar esta plano:
1.
2.
2,4 Interfaces e dependncias de outros planos
Detalhes das inter-relaes e referncias com toda continuidade e outros planos
de recuperao e de como as interfaces so ativados.
2,5 orientao geral
Todos os pedidos de informao dos meios de comunicao ou de outras fontes
devem ser encaminhados para o Procedimento da empresa.
Ao notificar o pessoal de um desastre potencial ou real, siga o definido
operacional escalada procedimentos, e em particular:
Tenha calma e evitar longa conversa

Aconselh-los da necessidade de se referir pedidos de informao a
ponto de escalao
Aconselh-los de expectativas e aes (evitar dar-lhes detalhes do
incidente menos que seja absolutamente necessrio)
Se a chamada atendida por outra pessoa:
o Pergunte se o contato est disponvel em outros lugares
o Se no pode ser contactado, deixe uma mensagem para contat-lo
em um determinado nmero
o No fornea detalhes do incidente
o Sempre documentar chamadas detalhes de tempo, respostas e
aes.
Todas as actividades e de contacto / escalada deve ser clara e devidamente

registada. Para facilitar isso, as aes devem estar em um formato lista de
verificao e no deve haver espao para registrar a data ea hora do atividade
foi iniciado e concludo, e que realizou a atividade.
430 de 477
2,6 Dependncias
Sistema,Infra-estrutura,servio,facilidade ou interface dependncias devem ser
documentadas (por ordem de prioridade) para que os planos de recuperao
relacionados ou procedimentos que precisam ser invocado em conjunto com o
plano de recuperao pode ser identificado e acionadas. O responsvel pela
chamada deve garantir recuperao atividades so coordenadas com esses
outros planos.
Sistema Documento de referncia Contato
2,7 listas de contato

Listas de todos os nomes de contatos, organizaos e detalhes de contato e
mecanismos:
Nome Organizao / Papel Ttulo Contacto
2,8 equipe de recuperao

O seguinte pessoal / funes so responsveis por estes actioning
procedimentos ou assegurar os procedimentos so acionadas e registrando
quaisquer problemas ou problemas encontrados. Contato ser feito atravs do
normal escalada procedimentos.
Nome Ttulo Contacto
431 de 477
432 de 477
2,9 lista da equipe de recuperao

Para facilitar a execuo de atividades-chave em tempo hbil, uma lista
semelhante seguinte deve ser usada.
Tarefa
Confirme invocao
Iniciar uma chamada de trs procedimentos e
escalada
Instigar e interface com outros planos de qualquer
recuperao necessria (por exemplo, BCP,
Gerenciamento de Crise, Plano de Resposta de
Emergncia)
Organizar para a mdia de backup e documentao
a ser enviada para o site de recuperao (s)
Criar equipas de recuperao
Iniciar aes de recuperao
Confirme relatrio de progresso
Informe equipe de recuperao das obrigaes de
informao
Confirme requisitos de ligao com todas as equipes
de recuperao
Aconselhar clientes e gesto de concluso estimado
de recuperao
433 de 477
Concluso
alvo
Concluso
real
3 processo de recuperao
Digite instrues de recuperao /procedimentos ou referncias a todos
recuperao procedimentos aqui.
Contedo / formato deve ser de acordo com as normas da empresa para os
procedimentos. Se no houver nenhum, a orientao deve ser emitido pelo Lder
Manager ou da equipe para a rea responsvel pelo sistema, de infra-estrutura,
servios ou instalaes. A nica orientao que as instrues devem ser
capazes de ser executado por um profissional experiente, sem confiana
indevida em conhecimento local.
Sempre que necessrio, as referncias devem ser feitas documentao de
apoio (e sua localizao), diagramas e outras fontes de informao. Isto deve
incluir o nmero de referncia do documento (se existir). da responsabilidade
do autor plano para assegurar que esta informao mantida com este plano.
Se existe apenas uma quantidade limitada de informao de suporte, pode ser
mais fcil para que isso seja includo no plano, e este plano continua a ser fcil
de ler / seguir e no se torne demasiado complexo.
434 de 477
Outras informaes
Referncias
1. Estratgia de Servio
2. Transio de Servio
3. Operao de Servio
4. Melhoria de Servio Continuada
5. Peter Drucker
6. COBIT - ISACA
7. CMMI - CMU
8. eSCM-Portflio de Servio - CMU
9. PRINCE2 - OGC
10. ISO 9000
11. ISO / IEC 20000
12. ISO 27001
13. Empresa Arquitetura - Gartner
14. Planeje fazer verificar Act - W Edwards Deming
15. Balanced Scorecard - Kaplan / Norton
16. Arquitetura Orientada a Servios - OASIS
17. Gesto de Risco - OGC
18. Prtica Recomendada para Especificao de
Requisitos de Software (IEEE 830)
19. O Corpo de Engenharia de Software do
Conhecimento (SWEBOK)
20. Object Management Architecture - OMG
21. Common Information Model (CIM) - DMTF
22. Web-Based Empresa Gesto (WEBM) - DMTF
23. Aplicao de Gesto de Especificao - IBM
24. Windows Management Instrumentation - Microsoft
25. Desktop Management Instrumentation - Windows
26. Seis Sigma - Motorola
27. Dinmica de desenvolvimento de software - Jim
McCarthy
28. Engenharia de requisitos, exemplos de
conhecimento tcito e explcito (Maiden & Rugg,
1995)
29. Anlise de Negcios - Deborah Paulo e Donald
Yeates
30. Princpios de Gesto de Dados - Keith Gordon
31. Prtica de Migrao de Dados - John Morris
435 de 477
Glossrio
Lista de siglas
ACD
Distribuio Automtica de Chamadas
AM
Gerenciamento de Disponibilidade
AMIS
Disponibilidade do Sistema de Informao de Gesto
ASP
Application Service Provider
BCM
Gerenciamento da Capacidade de negcios
BCM
Gesto de Continuidade de Negcios
BCP
Plano de Continuidade de Negcios
BIA
Anlise de Impacto no Negcio
BRM
Gerente de Relacionamento de Negcios
BSI
British Standards Institution
BSM
Business Service Management
CAB
Alterar Conselho Consultivo
CAB / CE
Alterar Conselho Consultivo / Comit de Emergncia
CAPEX
Despesas de Capital
CCM
Gerenciamento da Capacidade componente
CFIA
Componente Anlise de Impacto falha
CI
Item de Configurao
CMDB
Configuration Management Database
CMIS
Capacidade do Sistema de Informao de Gesto
CMM
Capability Maturity Model
CMMI
Capability Maturity Model Integration
CMS
Sistema de Gerenciamento da Configurao
COTS
Comercial da Prateleira
CSF
Fator Crtico de Sucesso
CSI
Melhoria de Servio Continuada
436 de 477
CSIP
Plano de Melhoria de Servio Continuada
CSP
Pacote de servios do ncleo
CTI
Computer Telephony Integration
DIKW
Dados para-Informao-para-Conhecimento-para-Sabedoria
ELS
Life Support cedo
eSCM-CL
eSourcing Capability modelo para organizaes clientes
eSCM-SP
eSourcing Modelo de Capacidade para prestadores de servios
FMEA
Modos de Falha e Anlise de Efeitos
FTA
Anlise da rvore de Falhas
IRR
Taxa Interna de Retorno
ISG
Grupo de Coordenao de TI
ISM
Gesto de Segurana da Informao
ISMS
Sistema de Gesto da Segurana
ISO
Organizao Internacional para Padronizao
ISP
Provedor de servios de Internet
TI
Tecnologia da Informao
ITSCM
Gerenciamento da Continuidade do Servio
ITSM
IT Service Management
itSMF
IT Service Management Forum
IVR
Interactive Voice Response
BDEC
Banco de Dados de erro conhecido
KPI
Key Performance Indicator
LOS
Linha de Servio
M_o_R
Gesto de Risco
MTBF
Tempo mdio entre falhas
TMEIS
Tempo mdio entre Incidentes de Servio
MTRS
Tempo mdio para restaurar o servio
MTTR
Mean Time To Repair
VPL
Valor Presente Lquido
OGC
Office of Government Commerce
437 de 477
OLA
Acordo de Nvel Operacional
OPEX
Despesas operacionais
OPSI
Escritrio de Informao do Sector Pblico
PBA
Padro de Atividade de Negcios
PIR
Ps-Implementao comentrio
PFS
Pr-requisito para o sucesso
PSO
Interrupo do servio projetado
QA
Garantia de Qualidade
SGQ
Sistema de Gesto da Qualidade
RCA
Anlise de causa raiz
RFC
Requisio de Mudana
ROI
Retorno sobre Investimento
RPO
Objetivo do ponto de recuperao
RTO
Objetivo Tempo de recuperao
SoC
Separao de preocupaes
SAC
Critrios de aceitao de servios
SACM
Ativos de Servios e Gerenciamento de Configurao
SCD
Fornecedor e banco de dados contrato
SCM
Gerenciamento da Capacidade de servio
SDP
Pacote de Desenho de Servio
SFA
Anlise de falha de servio
SIP
Plano de Melhoria de Servio
SKMS
Servio do Sistema de Gesto do Conhecimento
SLA
Acordo de Nvel de Servio
SLM
Gerenciamento de Nvel de Servio
SLP
Pacote de nvel de servio
SLR
Exigncia de Nvel de Servio
SMO
Objetivo de manuteno do servio
SOP
Procedimentos Operacionais Padro
SOR
Declarao de requisitos
438 de 477
SPI
Interface do provedor de servios
SPM
Gesto de Portflio de Servios
SPO
Otimizao de provisionamento de servios
SPOF
Ponto nico de falha
TO
Observation tcnica
TOR
Termos de referncia
TCO
Custo Total de Propriedade
TCU
Custo Total de Utilizao
TQM
Gesto da Qualidade Total
UC
Subjacente Contrato
UP
Perfil do Usurio
VBF
Funo de Negcios Vital
VOI
Valor do Investimento
WIP
Work in Progress
439 de 477
Lista de definies
Os nomes includos na publicao parnteses aps o nome de um termo de
identificar onde o leitor pode encontrar mais informaes sobre esse termo. Isto
porque o termo usado principalmente por que a publicao ou porque
informaes adicionais teis sobre esse termo pode ser encontrado l. Termos
sem um nome de publicao que lhes esto associados podem ser utilizados
geralmente por vrias publicaes, ou no pode ser definida em maior detalhe
do que pode ser encontrado no glossrio, ou seja, ns apenas leitores apontam
para algures que podem esperar para expandir o seu conhecimento ou a ver um
contexto maior. Termos com nomes de publicao mltiplas so expandidas em
em vrias publicaes.
Quando a definio de um termo inclui outro termo, os termos relacionados so
destacadas em uma segunda cor. Isto projetado para ajudar o leitor com a sua
compreenso, apontando-os a definies adicionais que so todos parte do
termo original que eles estavam interessados dentro A forma 'Ver tambm X, Y
prazo Term " utilizada no fim de uma definio em que um termo importante
relacionado no utilizado com o texto da prpria definio.
Aceitao
Acordo formal que um servio de TI, Processo, Plano ou Deliverable

outro completa, precisa, confivel e cumpre os seus requisitos
especificados. A aceitao geralmente precedido por avaliao ou
teste e muitas vezes necessria antes de prosseguir para a prxima
fase de um projeto ou processo. Ver tambm Critrios de aceitao de
servios.
Contabilidade
(Estratgia de Servio) O Processo responsvel por identificar os

custos reais de fornecimento de servios de TI, comparando-os com
os custos orados e gerenciamento de varincia do Oramento.
Atividade
Um conjunto de aes destinadas a alcanar um determinado

resultado. Atividades so geralmente definidas como parte de
processos ou planos, e esto documentadas em procedimentos.
Tempo de servio
acordado
(Desenho de Servio) Um sinnimo de horas de servio, comumente

utilizadas em clculos formais de Disponibilidade. Veja tambm
Downtime.
Acordo
Um documento que descreve um entendimento formal entre duas ou

mais partes. Um acordo no juridicamente vinculativo, a menos que
ele faz parte de um contrato. Ver tambm Acordo de Nvel de Servio,
Acordo de Nvel Operacional.
Alertar
(Operao de Servio) Um aviso de que um limite foi atingido, algo

mudou ou uma falha ocorreu. Alertas so muitas vezes criados e
gerenciados por ferramentas de gerenciamento do sistema e so
gerenciados pelo Processo de Gesto de Eventos.
Modelagem analtica
(Estratgia de Servio) (Desenho de Servio) (Melhoria de Servio
440 de 477
Continuada) Uma tcnica que utiliza modelos matemticos para prever

o comportamento de um Item de Configurao ou Servio de TI.
Modelos analticos so comumente usados em Gesto de Capacidade
e Gerenciamento da Disponibilidade. Veja tambm Modelagem.
Aplicao
Software que fornece funes que so exigidas por um servio de TI.

Cada aplicao pode ser parte de mais do que um servio de TI. Um
aplicativo executado em um ou mais servidores ou clientes. Veja
tambm Gerenciamento de Aplicativos, Application Portfolio.
Aplicao de Gesto
de
(Desenho de Servio) (Operao de Servio) A Funo responsvel

por gerenciar aplicativos durante todo seu ciclo de vida.
Application Portfolio
(Desenho de Servio) Um banco de dados de documentos ou

estruturado usado para gerenciar aplicativos em todo o seu ciclo de
vida. O portflio de aplicativos contm atributos-chave de todas as
aplicaes. O portflio de aplicativos s vezes implementada como
parte do portflio de servios, ou como parte do Sistema de Gesto de
Configurao.
Application Service
Provider
(Desenho de Servio) Um provedor de servio externo que fornece

servios de TI utilizando aplicativos executados nas instalaes do
prestador de servios. Os usurios acessam os aplicativos por
conexes de rede para o provedor de servio.
Aplicao de
Dimensionamento
(Desenho de Servio) A Atividade responsvel por entender as

necessidades de recursos necessrios para suportar um aplicativo
novo, ou uma grande mudana para um aplicativo existente.
Dimensionamento aplicao ajuda a garantir que o Servio de TI pode
cumprir as suas metas de servio acordadas a nvel de desempenho e
capacidade.
Arquitetura
(Desenho de Servio) A estrutura de um sistema ou servio de TI,

incluindo as relaes de componentes para o outro e para o meio
ambiente que esto dentro Arquitetura tambm inclui as normas e
diretrizes que orientam a concepo e evoluo do sistema.
Avaliao
Inspeo e anlise para verificar se um padro ou conjunto de

orientaes est sendo seguido, que os registros so precisos, ou que
os objectivos de eficincia e eficcia esto sendo atendidas. Veja
tambm auditoria.
Ativos
(Estratgia de Servio) qualquer recurso ou capacidade. Activos de um

provedor de servio, incluindo tudo o que poderia contribuir para a
prestao de um servio. Os ativos podem ser um dos seguintes tipos:
Gesto, Organizao, Conhecimento, Processo, Pessoas,
informaes, aplicaes, infra-estrutura e do capital financeiro.
Gesto de Ativos
(Transio de Servio) Asset Management o processo responsvel

por acompanhar e relatar o valor ea propriedade de ativos financeiros
em todo o seu ciclo de vida. Asset Management parte de um activo
Servio geral e processo de gesto de configurao.
Atributo
(Transio de Servio) Um pedao de informaes sobre um item de

configurao. Exemplos so: nome, localizao, nmero da verso e
Custo. Atributos de ICs so registrados no Configuration Management
441 de 477
Database (CMDB). Veja tambm Relacionamento.

Auditar
Inspeo formal e verificao para verificar se um padro ou conjunto

de orientaes est sendo seguido, que os registros so precisos, ou
que os objectivos de eficincia e eficcia esto sendo atendidas. Uma
auditoria pode ser efectuada por grupos internos ou externos. Veja
tambm avaliao, certificao.
Distribuio
Automtica de
Chamadas
(Operao de Servio) O uso da Tecnologia da Informao para

direcionar uma chamada telefnica para a pessoa mais adequada no
menor tempo possvel. ACD s vezes chamado de distribuio
automtica de chamadas.
Disponibilidade
(Desenho de Servio) Capacidade de um item de configurao ou

servio de TI para executar sua funo acordada quando necessrio.
A disponibilidade determinada pela Confiabilidade, Manuteno,
manuteno, desempenho e segurana. A disponibilidade
normalmente calculada como uma percentagem. Este clculo muitas
vezes baseadas em tempo de servio acordado e tempo de
inatividade. Ela a melhor prtica para calcular a disponibilidade
usando medies da sada de Negcios do Servio de TI.
Gerenciamento de
Disponibilidade
(Desenho de Servio) O Processo responsvel pela definio, anlise,

planejamento, medir e melhorar todos os aspectos da disponibilidade
dos servios de TI. Gerenciamento de Disponibilidade responsvel
por garantir que todas as infra-estruturas de TI, Processos,
Ferramentas, Funes, etc so apropriados para as metas de servio
acordado nvel de disponibilidade.
Disponibilidade do
Sistema de
Informao de Gesto
(Desenho de Servio) Um repositrio virtual de todos os dados de

gerenciamento de disponibilidade, normalmente armazenados em
vrios locais fsicos. Veja tambm Servio de Sistema de Gesto do
Conhecimento.
Plano de
disponibilidade
(Desenho de Servio) Um plano para garantir que os requisitos de

disponibilidade existentes e futuras por servios de TI pode ser
fornecido de maneira rentvel.
Voltar-out
Veja Remediao.
Faa backup
(Desenho de Servio) (Operao de Servio) Copiar dados para

proteger contra a perda de integridade ou disponibilidade do original.
Balanced Scorecard
(Melhoria de Servio Continuada) Uma ferramenta de gesto

desenvolvido pelos drs. Robert Kaplan (Harvard Negcio Escola) E
David Norton. O Balanced Scorecard permite uma estratgia a ser
dividido em indicadores de desempenho. Desempenho em relao ao
KPIs so usados para demonstrar o quo bem a estratgia est sendo
alcanado. O Balanced Scorecard tem quatro reas principais, cada
um dos quais tem um pequeno nmero de KPIs. As mesmas quatro
reas so consideradas em diferentes nveis de detalhe em toda a
Organizao.
Linha de base
(Melhoria de Servio Continuada) Uma referncia usada como um

ponto de referncia. Por exemplo:
442 de 477
Referncia
Uma linha de base ITSM pode ser usada

como um ponto de partida para medir o efeito
de um Plano de Melhoria de Servio
Um parmetro de desempenho pode ser
usado para medir as mudanas no
desempenho sobre o tempo de vida de um
servio de TI
A linha de base do Gerenciamento da
Configurao pode ser usado para permitir
que a infra-estrutura de TI para ser restaurado
para uma configurao de sabe se uma
Alterar ou lanamento falhar.
(Melhoria de Servio Continuada) O estado de algo gravado em um

ponto especfico no tempo. A referncia pode ser criado para uma
configurao, um processo, ou qualquer outro conjunto de dados. Por
exemplo, um valor de referncia pode ser utilizada em:
Melhoria de Servio Continuada, para

estabelecer o estado atual para o
gerenciamento de melhorias
Gerenciamento da Capacidade, para
documentar as caractersticas de desempenho
durante as operaes normais.
Veja tambm Base de Benchmarking.

Aferio
(Melhoria de Servio Continuada) Comparando-se uma referncia com

uma linha de base ou com a Melhor Prtica. A avaliao do
desempenho termo tambm utilizado para significar a criao de
uma srie de parmetros de referncia ao longo do tempo, e
comparando os resultados para medir o progresso ou melhoria.
Melhores Prticas
Atividades comprovadas ou processos que tm sido utilizados com

sucesso por vrias organizaes. ITIL um exemplo de boas prticas.
Brainstorming
(Desenho de Servio) Uma tcnica que ajuda uma equipe a gerar

idias. As idias no so revisados durante a sesso de brainstorming,
mas numa fase posterior. Brainstorming muitas vezes usado pelo
Gerenciamento de Problemas para identificar as possveis causas.
Oramento
Uma lista de todo o dinheiro que uma unidade organizacional ou

planos de negcios para receber, e planeja pagar, durante um perodo
de tempo especificado. Veja tambm Planejamento, Oramento.
Oramento
A Atividade de prever e controlar o gasto de dinheiro. Consiste de um

ciclo de negociao peridica para definir oramentos futuros
(geralmente anual) eo acompanhamento do dia-a-dia e de ajuste de
Oramentos atuais.
Construir
(Transio de Servio) a actividade de montagem de uma srie de

itens de configurao para criar parte de um Servio de TI. Construir o
termo tambm usado para se referir a uma verso que est
autorizado para distribuio. Por exemplo Build Server ou laptop
443 de 477
Construir. Veja tambm linha de base de configurao.

Negcio
(Estratgia de Servio) Uma entidade corporativa geral ou

Organizao formada por um nmero de Unidades de Negcios. No
contexto do ITSM, o termo Business inclui setor pblico e sem fins
lucrativos, bem como empresas. Um provedor de servio de TI fornece
servios de TI para um cliente dentro de uma empresa. O prestador de
servio de TI pode ser parte do negcio mesmo que o seu cliente
(prestador de servios interno), ou parte de outro negcio (prestador
de servios externo).
Gerenciamento da
Capacidade de
negcios
(Desenho de Servio) No contexto do ITSM, Negcios Gerenciamento

da Capacidade a Atividade responsvel por entender Requisitos de
Negcio de futuro para utilizao no Plano de Capacidade. Ver
tambm Gerenciamento da Capacidade de servio.
Business Case
(Estratgia de Servio) Justificao para um item significativo das

despesas. Inclui informaes sobre custos, benefcios, opes,
problemas, riscos e possveis problemas. Veja tambm Anlise de
Custo-Benefcio.
Gesto de
Continuidade de
Negcios
(Desenho de Servio) O processo de negcio responsvel pela gesto

de riscos que podem afectar gravemente o negcio. BCM
salvaguardas os interesses dos principais interessados, marca,
reputao e atividades que criam valor. O processo de BCM envolve a
reduo dos riscos para um nvel aceitvel e planejamento para a
recuperao de Processos de Negcios deve uma interrupo dos
negcios ocorrem. BCM estabelece os objectivos, mbito e Requisitos
para Gerenciamento de Continuidade de Servio.
Plano de
Continuidade de
Negcios
(Desenho de Servio) Um Plano que define os passos necessrios

para restaurar os processos de negcios aps uma interrupo. O
Plano tambm vai identificar os gatilhos para Invocao, pessoas a
serem envolvidas, comunicaes, etc TI planos de continuidade de
servio formam uma parte significativa dos Planos de Continuidade de
Negcios.
Cliente negcio
(Estratgia de Servio) Um destinatrio de um produto ou um servio

do negcio. Por exemplo, se a empresa uma fabricante de
automveis, ento o cliente de negcios algum que compra um
carro.
Anlise de Impacto
no Negcio
(Estratgia de Servio) BIA a atividade em Gesto de Continuidade

de Negcios que identifica funes vitais do negcio e suas
dependncias. Estas dependncias podem incluir fornecedores,
pessoas, outros processos de negcios, servios de TI, etc BIA define
os requisitos de recuperao de servios de TI. Estes requisitos so:
Objetivos tempo de recuperao, os objetivos de ponto de
recuperao e metas de servio mnimo para cada nvel de servio de
TI.
Objetivo do Negcio
(Estratgia de Servio) O objectivo de um processo de negcio, ou da

empresa como um todo. Objetivos do Negcio apoiar a viso de
negcios, fornecer orientaes para a Estratgia de TI, e so muitas
vezes apoiados por servios de TI.
444 de 477
Operaes
comerciais
(Estratgia de Servio) O dia-a-dia de execuo, monitoramento e

gerenciamento de processos de negcios.
Perspectiva de
Negcios
(Melhoria de Servio Continuada) Uma compreenso do prestador de

servios e servios de TI a partir do ponto de vista do negcio, e uma
compreenso do negcio do ponto de vista do provedor de servio.
Business Process
Um processo que de propriedade e realizada pelo Negcios. A

Business Process contribui para a entrega de um produto ou servio a
um cliente de Negcios. Por exemplo, um varejista pode ter um
processo de compras que ajuda a fornecer servios a seus clientes
corporativos. Muitos processos de negcio dependem de servios de
TI.
Gesto de
Relacionamento com
Empresas
(Estratgia de Servio) O Processo ou Funo responsvel por manter

um relacionamento com a empresa. Gesto de Relacionamento de
Negcios geralmente inclui:
Gerenciamento de relacionamentos pessoais

com gerentes de negcios
Fornecer subsdios para Gerenciamento de
Portflio de servio
Assegurando que o prestador de servio de TI
satisfazer as necessidades de negcios dos
clientes
Este processo tem fortes ligaes com Service Level Management.

Business Service
Um servio de TI que suporta diretamente um processo de negcio, ao

contrrio de um Servio de Infra-estrutura, que utilizado internamente
pelo provedor de servio de TI e normalmente no visvel para o
negcio.
O Business Service termo tambm usado para significar um servio
que entregue aos clientes empresariais por Unidades de Negcio.
Por exemplo, a prestao de servios financeiros para clientes de um
banco, ou de mercadorias para os clientes de uma loja de varejo.
Entrega bem sucedida de servios de negcios, muitas vezes depende
de um ou mais servios de TI.
Business Service
Management
(Estratgia de Servio) (Desenho de Servio) Uma abordagem para o

gerenciamento de servios de TI que considera a processos de
negcio suportados eo valor de negcio fornecida.
Este termo tambm significa a gesto de servios de negcios
entregues a clientes empresariais.
Unidade de Negcios
(Estratgia de Servio) Um segmento do negcio que tem seus

prprios planos, mtricas, proveitos e custos. Cada Unidade de
Negcio possui ativos e usa-os para criar valor para os clientes na
forma de bens e servios.
Chamar
(Operao de Servio) Uma chamada telefnica para o Posto de

Servio de um Usurio. Uma chamada pode resultar em um incidente
ou uma solicitao de servio sendo registrado.
445 de 477
Call Center
(Operao de Servio) Uma Unidade de organizao ou empresa que

lida com um grande nmero de chamadas telefnicas de entrada e
sada. Veja tambm Service Desk.
Capacidade
(Estratgia de Servio) A capacidade de uma organizao, pessoa,

item de processo, configurao do aplicativo, ou servio de TI para
realizar uma atividade. Recursos so os ativos intangveis de uma
organizao. Veja tambm de recursos.
Capacidade
(Desenho de Servio) a vazo mxima que um Item de Configurao

ou Servio de TI pode entregar reunio enquanto acordaram metas de
nvel de servio. Para alguns tipos de CI, A capacidade pode ser do
tamanho ou do volume, por exemplo, uma unidade de disco.
Gerenciamento da
Capacidade
(Desenho de Servio) O Processo responsvel por garantir que a

capacidade dos servios de TI ea infra-estrutura de TI capaz de
entregar as metas de nvel de servio acordado de forma eficaz e
atempada. Gerenciamento da Capacidade considera todos os recursos
necessrios para oferecer o servio de TI e planos para curto,
Requisitos de Negcio de mdio e longo prazo.
Capacidade do
Sistema de
Informao de Gesto
(Desenho de Servio) Um repositrio virtual de todos os dados de

gerenciamento de capacidade, normalmente armazenados em vrios
locais fsicos. Veja tambm Servio de Sistema de Gesto do
Conhecimento.
Plano de capacidade
(Desenho de Servio) Um Plano de Capacidade usado para

gerenciar os recursos necessrios para entregar servios de TI. O
Plano contm cenrios para as previses de demanda de negcios
diferentes e opes oramentados para entregar os objetivos de nvel
de servio acordado.
Planejamento de
Capacidade
(Desenho de Servio) a atividade dentro de Gerenciamento da

Capacidade responsvel pela criao de um plano de capacidade.
Categoria
Um grupo nomeado de coisas que tm algo em comum. Categorias

so usadas para agrupar coisas semelhantes. Por exemplo, os tipos
de custos so usadas para agrupar tipos similares de custo.
Categorias incidentes so usadas para agrupar tipos semelhantes de
Incidentes, Tipos de CI so usadas para agrupar tipos semelhantes de
item de configurao.
Certificado
Emisso de um certificado para confirmar a conformidade a um

padro. Certificao inclui uma auditoria formal por um organismo
independente e credenciada. A Certificao termo tambm usado
para significar a atribuio de um certificado para verificar se uma
pessoa tem alcanado uma qualificao.
Mudar
(Transio de Servio) A adio, modificao ou remoo de tudo o

que poderia ter um efeito sobre servios de TI. O escopo deve incluir
todos os Servios de TI, itens de configurao, processos,
documentao, etc
Alterar Conselho
Consultivo
(Transio de Servio) Um grupo de pessoas que aconselha o Gerente

de Mudana na avaliao, priorizao e agendamento de alteraes.
Esta placa geralmente composto por representantes de todas as
446 de 477
reas dentro do provedor de servio de TI, representantes do negcio

e terceiros, como fornecedores.
Mudar a Histria
(Transio de Servio) Informaes sobre todas as alteraes feitas

em um Item de Configurao durante a sua vida. Histria mudana
consiste de todos esses registros de mudana que se aplicam ao CI.
Gesto da Mudana
(Transio de Servio) O Processo responsvel por controlar o ciclo de

vida de todas as alteraes. O principal objectivo da Gesto da
Mudana permitir que mudanas benficas para ser feita, com o
mnimo de perturbao para servios de TI.
Solicitao de
Mudana
Veja Requisio de Mudana.
Alterar agendamento
(Transio de Servio) um documento que lista todas as alteraes

aprovadas e as respectivas datas de execuo previstos. Um
programa de troca s vezes chamado de Programao Futura de
Mudanas, mesmo que tambm contm informaes sobre as
mudanas que j foram implementadas.
Janela Alterar
(Transio de Servio) Um regular, concordou momento Alteraes ou

Releases podem ser implementadas com o mnimo impacto sobre
Servios. O Windows mudana normalmente so documentados em
SLAs.
Carregamento
(Estratgia de Servio) exigncia de pagamento por servios de TI.

Cobrana de Servios de TI opcional, e muitas organizaes escolha
para tratar o seu fornecedor de servio de TI como um Centro de
Custo.
Classificao
O ato de atribuir uma categoria para algo. A classificao usada para

garantir uma gesto coerente e de relatrios. CIs, incidentes,
problemas, mudanas, etc, so geralmente classificados.
Cliente
Um termo genrico que significa um cliente, a empresa ou um cliente

de negcios. Por exemplo, Client Manager pode ser usado como
sinnimo de Gerente de Contas.
O cliente termo tambm utilizado para significar:
Um computador que usado diretamente por

um usurio, por exemplo, um PC, computador
porttil, estao de trabalho ou
A parte de uma aplicao cliente-servidor que
o usurio diretamente a interface com. Por
exemplo, um cliente de e-mail.
Fechado
(Operao de Servio) O status final no Ciclo de Vida de um Incidente,

Problema, Mudana, etc Quando o Estado est fechada, nenhuma
outra ao ser tomada.
Fecho
(Operao de Servio) O ato de mudar o status de um incidente,

problemas, mudanas, etc, para Fechado.
447 de 477
COBIT
(Melhoria de Servio Continuada) Objetivos de Controle para

Informaes e Tecnologia relacionada (COBIT) fornece orientao
prtica e melhor para a gesto de processos de TI. COBIT publicado
pelo Instituto de Governana de TI. Veja www.isaca.org para mais
informaes.
Espera frio
Ver recuperao gradual.
Commercial Off-theshelf
(Desenho de Servio) O software aplicativo ou Middleware que pode

ser comprado de uma terceira parte.
Observncia
A garantia de que uma norma ou conjunto de orientaes seguida,

ou que as prticas adequada, contabilidade consistente ou outra esto
sendo empregados.
Componente
Um termo geral que utilizado para significar uma parte de algo mais
complexo. Por exemplo, um sistema de computador pode ser um
componente de um Servio de TI, um aplicativo pode ser um
componente de uma Unidade de lanamento. Os componentes que
precisam ser gerenciados deve ser Itens de Configurao.
Gerenciamento da
Capacidade
componente
(Desenho de Servio) (Melhoria de Servio Continuada) O processo

responsvel por entender a capacidade de utilizao e desempenho
dos itens de configurao. Os dados so recolhidos, registados e
analisados para o uso no Plano de Capacidade. Ver tambm
Gerenciamento da Capacidade de servio.
Componente CI
(Transio de Servio) Um item de configurao que parte de um

conjunto. Por exemplo, um IC CPU ou de memria pode fazer parte de
um CI Server.
Componente Anlise
de Impacto falha
(Desenho de Servio) Uma tcnica que ajuda a identificar o impacto da

falha CI em servios de TI. A matriz criada com TI em uma
extremidade e IC, por outro. Isso permite a identificao de itens de
configurao crtica (que poderia causar o fracasso de mltiplos
servios de TI) e de Servios de TI (frgeis que tm vrios pontos
nicos de falha).
Simultaneidade
Uma medida do nmero de utilizadores que efectuam a mesma

operao ao mesmo tempo.
Confidencialidade
(Desenho de Servio) Um princpio de segurana que requer que os

dados devem ser acessados somente por pessoas autorizadas.
Configurao
(Transio de Servio) Um termo genrico, usado para descrever um

grupo de itens de configurao que trabalham em conjunto para
oferecer um servio de TI ou uma parte reconhecvel de um Servio de
TI. Configurao tambm utilizada para descrever as configuraes
de parmetros para um ou mais itens de configurao.
Base de configurao
(Transio de Servio) Uma linha de base de uma configurao que

tenha sido formalmente aceite e gerido atravs do processo de
Gerenciamento de Mudana. A linha de base de configurao usado
como base para futuras Builds, Releases e alteraes.
Controle de
(Transio de Servio) A Atividade responsvel por garantir que
448 de 477
Configurao
adicionar, alterar ou remover um CI adequadamente gerida, por

exemplo atravs da apresentao de um pedido de alterao ou
solicitao de servio.
Identificao da
Configurao
(Transio de Servio) A Atividade responsvel por coletar

informaes sobre itens de configurao e seus relacionamentos, e
carregar essa informao na CMDB. Identificao configurao
tambm responsvel para rotular o IC-se, de modo que os registos
de configurao correspondente pode ser encontrada.
Item de Configurao
(Transio de Servio) qualquer componente que precisa de ser gerida

de forma a oferecer um servio de TI. As informaes sobre cada IC
registrada em um registro de configurao dentro do Sistema de
Gesto de Configurao e mantido durante todo seu ciclo de vida
pelo Configuration Management. CIs esto sob o controle de
Gerenciamento de Mudana. ICs tipicamente incluem servios de TI,
hardware, software, prdios, pessoas e documentao formal, como a
documentao do processo e SLAs.
Gerenciamento da
Configurao
(Transio de Servio) O Processo responsvel por manter

informaes sobre Itens de Configurao necessrios para entregar
um servio de TI, incluindo seus relacionamentos. Esta informao
gerenciada durante todo o ciclo de vida do CI. Gerenciamento de
Configurao parte de um activo Servio geral e processo de gesto
de configurao.
Sistema de
Gerenciamento da
Configurao
(Transio de Servio) Um conjunto de ferramentas e bases de dados

que so usados para gerenciar dados de um provedor de servios de
TI de configurao. O CMS tambm inclui informaes sobre
incidentes, problemas, erros conhecidos, mudanas e lanamentos, e
podem conter dados sobre os funcionrios, fornecedores, locais,
unidades de negcios, clientes e usurios. O CMS inclui ferramentas
para coletar, armazenar, gerenciar, atualizar e apresentar dados sobre
todos os itens de configurao e seus relacionamentos. O CMS
mantida pela Gerncia de Configurao e utilizado por todos os
processos de gerenciamento de servios. Veja tambm Servio de
Sistema de Gesto do Conhecimento.
Melhoria de Servio
Continuada
(Melhoria de Servio Continuada) Uma fase no Ciclo de Vida de um

Servio de TI eo ttulo de uma das ITIL Ncleo publicaes. Melhoria
de Servio Continuada responsvel pela gesto de melhorias para
os processos de gerenciamento de servios de TI e Servios. O
desempenho do prestador de servio de TI continuamente medido e
melhorias so feitas para Processos, Servios de TI e infraestrutura de
TI, a fim de aumentar a eficincia, eficcia e rentabilidade. Veja
tambm Plan-Do-Check-Act.
Disponibilidade
contnua
(Desenho de Servio) Uma abordagem ou desenho para atingir 100%

de disponibilidade. Um continuamente disponvel de Servios de TI
no tem tempo de inatividade planejado ou no.
Operao Contnua
(Desenho de Servio) Uma abordagem ou desenho para eliminar

tempo de inatividade planejado de um Servio de TI. Note-se que itens
de configurao individuais podem ser baixo, embora o servio esteja
disponvel.
449 de 477
Contrato
Um acordo legalmente vinculativo entre duas ou mais partes.
Controlar
Um meio de gesto de um risco, garantindo que um objectivo de

negcio alcanado, ou garantir que um processo seguido.
Controles de exemplo incluem polticas, procedimentos, funes RAID,
fechaduras, etc Um controle s vezes chamado de contramedidas ou
de salvaguarda. Controle tambm significa gerenciar a utilizao ou o
comportamento de um sistema de configurao do item, ou Servio de
TI.
Controle de
perspectiva
(Estratgia de Servio) Uma abordagem para a gesto de servios de

TI, processos, funes, bens, etc Pode haver vrias perspectivas
diferentes sobre o Controle de Servios de TI mesmo, processo, etc,
permitindo que diferentes indivduos ou equipes a concentrar-se no
que importante e relevantes para a sua funo especfica.
Perspectivas de Controle de exemplo incluem gesto reativa e proativa
dentro de Operaes de TI, ou uma viso do ciclo de vida de uma
equipe de projeto de aplicao.
Custar
A quantidade de dinheiro gasto em uma atividade especfica, de

Servios de TI, ou Unidade de Negcios. Custos consistem de custo
real (dinheiro), custo terico, como o tempo das pessoas, e de
depreciao.
Anlise de CustoBenefcio
Uma atividade que analisa e compara os custos e os benefcios

envolvidos em um ou mais cursos alternativos de ao. Ver tambm
Processo de Negcios, Retorno sobre o Investimento.
Eficcia de Custo
Uma medida do equilbrio entre a eficcia eo custo de um servio,

processo ou atividade. Um processo de custo eficaz aquele que
atinge os seus objectivos a um custo mnimo. Veja tambm KPI,
Retorno sobre o Investimento, Value for Money.
Contramedida
Pode ser usado para se referir a qualquer tipo de controlo. O termo de

contramedidas mais frequentemente usado quando se refere a
medidas que aumentar a resilincia, tolerncia a falhas ou a
confiabilidade de um servio de TI.
Gesto de Crises
(Gerenciamento de Continuidade de Servios) de Gesto de Crise o

processo responsvel por gerenciar as implicaes mais amplas de
Continuidade de Negcios. Uma equipe de Gesto de Crise
responsvel por questes estratgicas como a gesto de relaes com
a mdia e confiana dos acionistas, e decide quando invocar Planos de
Continuidade de Negcios.
Fator Crtico de
Sucesso
Algo que deve acontecer se um processo, projeto, plano ou Servio de

TI ter sucesso. KPIs so usados para medir a realizao de cada
CSF. Por exemplo, uma LCR de "proteger Servios de TI ao fazer
alteraes" poderiam ser medidos por KPIs como "reduo percentual
de alteraes mal sucedidas", "percentagem de reduo Alteraes
causando incidentes", etc
Cultura
Um conjunto de valores que so compartilhados por um grupo de

pessoas, incluindo expectativas sobre como as pessoas devem se
comportar, as suas ideias, crenas e prticas. Ver tambm Viso.
450 de 477
Cliente
Algum que compra produtos ou servios. O cliente de um provedor de

servio de TI a pessoa ou grupo que define e aprova as metas de
nvel de servio. Os Clientes prazo tambm por vezes usado
informalmente para significar Usurios, por exemplo, 'Esta uma
organizao focada no cliente ".
Painel de
instrumentos
(Operao de Servio) Uma representao grfica do desempenho

geral do servio de TI e disponibilidade. Imagens do painel podem ser
atualizados em tempo real, e podem tambm ser includos nos
relatrios de gesto e pginas web. Painis podem ser utilizados para
apoiar Gesto de Nvel de Servio, Gesto de Eventos ou Diagnstico
de Incidentes.
Deliverable
Algo que deve ser fornecida para cumprir um compromisso em um

Acordo de Nvel de Servio ou um contrato. Deliverable tambm
usado de uma forma mais informal de significar uma sada prevista de
qualquer processo.
Gerenciamento da
Demanda
Atividades que compreendem e influenciar a demanda de clientes por

servios e na oferta de capacidade para atender a essas demandas.
Em uma Gesto Estratgica nvel de demanda pode envolver anlise
de padres de atividade de negcio e perfis de usurio. Em um nvel
ttico que pode envolver o uso de taxas diferenciadas para incentivar
os clientes a usar servios de TI em momentos de menor movimento.
Veja tambm Gerenciamento da Capacidade.
Dependncia
A dependncia directa ou indirecta de um processo ou atividade em

outro.
Desenvolvimento
(Transio de Servio) A Atividade responsvel pelo movimento de

hardware novo ou alterado, software, documentao, processos, etc,
para o ambiente ao vivo. A implantao parte do lanamento e
Processo de Gesto de Implantao.
Projeto
(Desenho de Servio) uma atividade ou processo que identifica os

requisitos e depois define uma soluo que capaz de atender a
esses requisitos. Ver tambm Design de Servios.
Deteco
(Operao de Servio) Uma fase no Ciclo de Vida de Incidentes.

Resultados de deteco no incidente se tornar conhecido para o
provedor de servio. A deteco pode ser automtica, ou pode ser o
resultado de um utilizador iniciar sesso um incidente.
Desenvolvimento
(Desenho de Servio) O Processo responsvel pela criao ou

modificao de um servio de TI ou de aplicativos. Tambm usado
para significar a funo ou grupo que realiza trabalho de
desenvolvimento.
Ambiente de
Desenvolvimento
(Desenho de Servio) Um Ambiente utilizada para criar ou modificar

servios de TI ou Aplicaes. Ambientes de Desenvolvimento no so
normalmente sujeitas ao mesmo grau de controle como ambientes de
teste ou ambientes vivos. Veja tambm Desenvolvimento.
Diagnstico
(Operao de Servio) no estdio A de os ciclos de vida de incidentes

e problemas. O objetivo do diagnstico identificar uma soluo para
um incidente ou a causa raiz de um problema.
451 de 477
Diferencial de
carregamento
Uma tcnica usada para apoiar Gesto de Demanda cobrando valores

diferentes para a mesma funo de Servios de TI em momentos
diferentes.
Documento
Informaes de forma legvel. Um documento pode ser papel ou

eletrnico. Por exemplo, uma declarao poltica, Acordo de Nvel de
Servio, Registro de Incidentes, diagrama do layout da sala de
computador. Veja tambm Record.
Tempo de inatividade
(Desenho de Servio) (Operao de Servio) O momento em que um

Item de Configurao ou Servio de TI no est disponvel durante o
seu tempo de servio acordado. A disponibilidade de um servio
muitas vezes calculado a partir de tempo de servio acordado e
tempo de inatividade.
Motorista
Algo que influencia estratgia, objectivos ou exigncias. Por exemplo,

a nova legislao ou as aes dos concorrentes.
Economias de escala
(Estratgia de Servio) A reduo do custo mdio que possvel de

aumentar o uso de um servio de TI ou de Ativos.
Eficcia
(Melhoria de Servio Continuada) Uma medida se os objectivos do

Processo de um servio ou atividade foram alcanados. Um processo
efetivo ou atividade aquele que atinge os seus objectivos acordados.
Veja tambm KPI.
Eficincia
(Melhoria de Servio Continuada) Uma medida de se o direito

quantidade de recursos foi utilizada para fornecer um processo,
servio ou atividade. Um processo eficiente alcana seus objetivos
com o mnimo de tempo, dinheiro, pessoas ou outros recursos. Veja
tambm KPI.
Ambiente
(Transio de Servio) Um subconjunto da infra-estrutura de TI que

usado para um propsito particular. Por exemplo: Ambiente Live, Test
Environment, ambiente de construo. possvel para vrios
ambientes para compartilhar um item de configurao, por exemplo,
ambientes de teste e ao vivo pode usar parties diferentes em um
computador nico mainframe. Tambm usado no ambiente de prazo
Fsica para significar a acomodao, ar condicionado, sistema de
energia, etc
Ambiente tambm usado como um termo genrico para designar as
condies externas que influenciam ou afetam algo.
Erro
(Operao de Servio) falha ou mau funcionamento Um projeto que

faz com que uma falha de um ou mais itens de configurao ou
servios de TI. Um erro cometido por uma pessoa ou um processo
deficiente que afeta um servio IC ou tambm um erro.
Escalada
(Operao de Servio) Uma Atividade que obtm recursos adicionais,

quando estes so necessrios para cumprir as metas de nvel de
servio ou expectativas dos clientes. Escalada pode ser necessria
dentro de qualquer Processo de Gesto de Servios de TI, mas mais
comumente associado com a Gesto de Incidentes, Gesto de
Problemas e gesto de reclamaes de clientes. Existem dois tipos de
escalada escalada, funcional e escalonamento hierrquico.
452 de 477
eSourcing Modelo de
Capacidade para
prestadores de
servios
(Estratgia de Servio) Uma estrutura para ajudar os provedores de

servios desenvolvem as suas capacidades de gesto de servios de
TI a partir de uma perspectiva de servio de sourcing. eSCM-SP foi
desenvolvido pela Carnegie Mellon University,EUA.
Estimativa
O uso da experincia para fornecer um valor aproximado para uma

Mtrica ou Custo. Estimativa usado tambm em capacidade e gesto
de disponibilidade como o mtodo mais barato e Modelagem menos
preciso.
Avaliao
(Transio de Servio) O Processo responsvel por avaliar um novo

ou alterado Servio de TI para garantir que os riscos foram
gerenciados e para ajudar a determinar se deseja prosseguir com a
mudana.
Avaliao tambm usada para significar comparar um resultado real
com o resultado pretendido, ou comparar uma alternativa com outra.
Evento
(Operao de Servio) Uma mudana de estado que tem importncia

para a gesto de um Item de Configurao ou Servio de TI.
O Evento termo tambm usado para significar um Alerta ou
notificao criada por qualquer TI item Configurao do servio, ou a
ferramenta de monitoramento. Eventos geralmente requerem pessoal
de operaes de TI tomar medidas, e muitas vezes levam a Incidentes
sendo registrados.
Gesto de Eventos
(Operao de Servio) O Processo responsvel por gerenciar eventos

durante todo seu ciclo de vida. Gesto de Eventos uma das
principais atividades das operaes de TI.
Relatrio de Exceo
Um documento contendo detalhes de um ou mais KPIs ou outros alvos

importantes que tenham ultrapassado os limites definidos. Exemplos
incluem SLA alvos sendo perdidas ou prestes a ser perdida, e uma
mtrica de desempenho que indica um problema de capacidade
potencial.
Ciclo de Vida do
Incidente Expandido
(Gerenciamento de Disponibilidade) etapas detalhadas no ciclo de vida

de um incidente. Os estgios so deteco, diagnstico, reparao,
restaurao, reconstruo. O Ciclo de Vida do Incidente Expandido
usado para ajudar a compreender todas as contribuies para o
impacto dos incidentes e planejar como esses poderiam ser
controlados ou reduzidos.
Prestador de servios
externo
(Estratgia de Servio) Um provedor de servio de TI que faz parte de

uma organizao diferente ao seu cliente. Um provedor de servio de
TI pode ter clientes internos e clientes externos.
Externa de Sourcing
Veja Outsourcing.
Gesto de Instalaes (Operao de Servio) A Funo responsvel por gerenciar o

ambiente fsico onde a infra-estrutura de TI est localizado. Facilities
Management inclui todos os aspectos de gesto do ambiente fsico,
para poder exemplo e refrigerao, construo de acesso, gesto e
monitoramento ambiental.
453 de 477
Falha
(Operao de Servio) Perda de capacidade de operar com a

especificao, ou para entregar a sada necessria. A falha termo
pode ser usado quando se refere a servios de TI, processos,
atividades, itens de configurao, etc Uma falha muitas vezes causa
um Incidente.
Recuperao rpida
(Desenho de Servio) Uma opo de recuperao que tambm

conhecido como Hot Standby. A proviso feita para recuperar o
servio que num curto espao de tempo: geralmente menos do que 24
horas. Recuperao rpida geralmente usa uma instalao dedicada
fixo com sistemas de computadores, software e configurado pronto
para executar os servios de TI. Recuperao rpida pode levar at 24
horas, se h a necessidade de restaurar os dados a partir de backups.
Culpa
Veja erro.
Tolerncia a Falhas
(Desenho de Servio) A capacidade de um servio de TI ou Item de

Configurao para continuar a funcionar corretamente aps falha de
um componente. Veja tambm Resilincia, de contramedidas.
Anlise da rvore de
Falhas
(Desenho de Servio) (Melhoria de Servio Continuada) Uma tcnica

que pode ser usada para determinar a cadeia de acontecimentos que
conduz a um problema. Anlise da rvore de Falhas representa uma
cadeia de eventos usando a notao booleana em um diagrama.
Gesto Financeira
(Estratgia de Servio) A funo e os processos responsveis pela

gesto de Oramento de um provedor de servio de TI, contabilidade e
carregamento de Requisitos.
Apto para o efeito
Um termo informal usado para descrever um processo, Item de

Configurao, Servio de TI, etc, que capaz de cumprir os seus
objectivos ou nveis de servio. Estar apto para o efeito requer um
projeto adequado, implementao, controle e manuteno.
Cumprimento
Realizar atividades para atender a uma necessidade ou exigncia. Por

exemplo, atravs de um Servio de TI novo, ou satisfazer um pedido
de servio.
Funo
Uma equipe ou grupo de pessoas e as ferramentas que eles usam

para realizar um ou mais processos ou atividades. Por exemplo, o
Service Desk.
A Funo termo tambm tem dois outros significados:
454 de 477
Um destino de um item de configurao,

Pessoa, equipe, Processo, ou Servio de TI.
Por exemplo, uma funo de um servio de email pode ser a de armazenar e encaminhar emails de sada, uma funo de um processo
de negcio pode ser a expedio de
mercadorias aos clientes.
Para realizar a finalidade pretendida
corretamente, "O computador est
funcionando".
Governo
Assegurar que as polticas e estratgia so realmente implementadas,

e que os processos necessrios so corretamente seguidas.
Governana inclui a definio de papis e responsabilidades, medir e
comunicar, e tomar medidas para resolver os problemas identificados.
Recuperao gradual

conhecido como espera Fria. Proviso feita para Recuperar o
Servio de TI em um perodo de tempo superior a 72 horas.
Recuperao gradual geralmente usa um mecanismo porttil ou fixo
que tem suporte ambiental e cabeamento de rede, mas no h
sistemas de computador. O hardware e software so instalados como
parte do Plano de Continuidade dos Servios de.
Diretriz
Um documento que descreve Melhores Prticas, que recomenda que

deve ser feito. Cumprimento de uma diretriz no normalmente
aplicada. Veja tambm Standard.
Alta Disponibilidade
(Desenho de Servio) Uma abordagem ou desenho que minimiza ou

esconde os efeitos da falha Item de Configurao sobre os utilizadores
de um servio de TI. Solues de alta disponibilidade so projetados
para atingir um nvel acordado de Disponibilidade e fazer uso de
tcnicas como a Tolerncia a Falhas, Resilincia e Recuperao
rpida para reduzir o nmero de incidentes, eo impacto dos incidentes.
Hot Standby
Veja a rpida recuperao ou recuperao imediata.
Recuperao
imediata

conhecido como Hot Standby. Proviso feita para Recuperar o
Servio de TI, sem perda de servio. Recuperao imediata
geralmente usa espelhamento de balanceamento de carga e
tecnologias do site Split.
Impacto
(Operao de Servio) (Transio de Servio) Uma medida do efeito

de um incidente, problema ou mudana nos processos de negcio.
Impacto muitas vezes baseada em como os nveis de servio sero
afetados. Impacto e Urgncia so usados para atribuir prioridade.
Incidente
(Operao de Servio) Uma interrupo no planejada de um servio

de TI ou a reduo da qualidade de um servio de TI. Falha de um
item de configurao que ainda no afetou servio tambm um
Incidente. Por exemplo, a falha de um disco a partir de um conjunto de
espelho.
Gerenciamento de
Incidentes
(Operao de Servio) O Processo responsvel por gerenciar o ciclo

de vida de todos os incidentes. O objetivo principal do Gerenciamento
de Incidentes retornar o Servio de TI para clientes o mais rpido
possvel.
Grave incidente
(Operao de Servio) Um Registro contendo os detalhes de um

incidente. Cada registro Incidente documenta o ciclo de vida de um
nico incidente.
Custos Indiretos
(Estratgia de Servio) Um Custo de prestao de um servio de TI, o

que no pode ser alocado integralmente para um cliente especfico.
Por exemplo, o custo da prestao de servidores compartilhados ou
licenas de software. Tambm conhecido como sobrecarga.
455 de 477
Gesto de Segurana
da Informao
(Desenho de Servio) O Processo que garante a confidencialidade,

integridade e disponibilidade dos ativos de uma organizao,
informaes, dados e servios de TI. Gesto de Segurana da
Informao geralmente faz parte de uma abordagem organizacional
para gerenciamento de segurana que tem um escopo mais amplo do
que o provedor de servio de TI, e inclui a manipulao de papel,
construo de acesso, telefonemas, etc, para toda a Organizao.
Sistema de Gesto da
Segurana
(Desenho de Servio) O quadro de polticas, processos, normas,

orientaes e ferramentas que garantem uma organizao pode atingir
os seus objectivos de gesto de segurana de informao.
Poltica de Segurana
da Informao
(Desenho de Servio) A poltica que governa abordagem da

Organizao de Gesto de Segurana da Informao.
Tecnologia da
Informao
O uso da tecnologia para o armazenamento, comunicao ou

processamento de informaes. A tecnologia normalmente inclui
computadores, telecomunicaes, aplicativos e outros softwares. A
informao pode incluir dados de negcios, voz, imagens, vdeos, etc
Tecnologia da Informao muitas vezes utilizados para apoiar
processos de negcios atravs de servios de TI.
Servio de Infraestrutura
Um servio de TI que no usado diretamente pela empresa, mas

exigido pelo provedor de servio de TI para que eles possam oferecer
outros servios de TI. Por exemplo, servios de diretrio, servios de
identificao, ou servios de comunicao.
Insourcing
Veja Interna Sourcing.
Integridade
(Desenho de Servio) Um princpio de segurana que garante que os

dados e itens de configurao so modificados somente por pessoas
autorizadas e Atividades. Integridade considera todas as possveis
causas de modificao, incluindo software e hardware falha, eventos
ambientais e interveno humana.
Recuperao
Intermedirio

conhecido como espera passiva. Proviso feita para Recuperar o
Servio de TI em um perodo de tempo entre 24 e 72 horas.
Recuperao intermedirio geralmente usa um mecanismo comum
porttil ou fixo que tem sistemas de computadores e componentes de
rede. O hardware e software precisa ser configurado, e os dados
precisam ser restaurados, como parte do Plano de Continuidade dos
Servios de.
Provedor de servio
interno
(Estratgia de Servio) Um provedor de servio de TI que faz parte da

Organizao mesmo que o seu cliente. Um provedor de servio de TI
pode ter clientes internos e clientes externos.
Interna de Sourcing
(Estratgia de Servio) Usando um provedor de servio interno para

gerenciar servios de TI.
Organizao
Internacional para
Padronizao
A Organizao Internacional de Normalizao (ISO) a maior

desenvolvedora mundial de Normas. ISO uma organizao nogovernamental que uma rede de institutos de padres nacionais de
156 pases. Veja www.iso.org para obter mais informaes sobre a
ISO.
456 de 477
ISO 9000
Um termo genrico que se refere a uma srie de normas e diretrizes

internacionais para Sistemas de Gesto da Qualidade. Veja
www.iso.org para mais informaes. Veja tambm ISO.
ISO 9001
Uma norma internacional para Sistemas de Gesto da Qualidade. Veja

tambm ISO 9000, Norma.
ISO / IEC 20000
ISO Especificao e Cdigo de Boas Prticas para o Gerenciamento

de Servios. ISO / IEC 20000 est alinhado com ITIL Best Practice.
ISO / IEC 27001
(Desenho de Servio) (Melhoria de Servio Continuada) Especificao

ISO de Gesto de Segurana da Informao. O Cdigo
correspondente da prtica a norma ISO / IEC 17799. Veja tambm
Standard.
Infraestrutura de TI
Todo o hardware, software, redes, instalaes, etc, que so

necessrios para desenvolver, testar, entregar, monitorar, controlar ou
apoiar servios de TI. O termo infra-estrutura de TI inclui toda a
Tecnologia da Informao, mas no as pessoas associadas,
processos e documentao.
Operaes de TI
(Operao de Servio) Atividades realizadas pela TI Controle de

Operaes, incluindo Management Console, Job Scheduling, Backup e
Restaurao, e impresso e Gesto de Produo. Operaes de TI
tambm usado como sinnimo de Operao de Servio.
Servios de TI
Um servio prestado a um ou mais clientes por um fornecedor de

servios de TI. Um servio de TI baseado no uso de Tecnologia da
Informao e Processos de suporte de negcio do cliente. Um servio
de TI feita a partir de uma combinao de pessoas, processos e
tecnologia e deve ser definido em um Acordo de Nvel de Servio.
Gerenciamento da
Continuidade do
Servio
(Desenho de Servio) O Processo responsvel por gerenciar os riscos

que poderiam afetar seriamente Servios de TI. ITSCM garante que o
provedor de servio de TI pode sempre fornecer nveis mnimos de
servio acordado, reduzindo o risco a um nvel aceitvel e
Planejamento de Recuperao de Servios de TI. ITSCM deve ser
projetado para suportar Gesto de Continuidade de Negcios.
TI Plano de
Continuidade do
Servio
(Desenho de Servio) Um Plano que define os passos necessrios

para recuperar um ou mais servios de TI. O Plano tambm vai
identificar os gatilhos para Invocao, pessoas a serem envolvidas,
comunicaes, etc O Plano de Continuidade de Servios de TI devem
fazer parte de um Plano de Continuidade de Negcios.
IT Service
Management
A implementao e gesto da Qualidade de Servios de TI que

atendam as necessidades do negcio. IT Service Management
realizada por servios de TI atravs de uma combinao adequada de
Tecnologia de pessoas, processos e informao. Ver tambm Servio
de Gesto de.
Provedor de servio
de TI
(Estratgia de Servio) Um prestador de servios que fornece servios

de TI para clientes internos ou clientes externos.
Grupo de
Coordenao de TI
Um grupo formal, que responsvel por garantir que as empresas e

as estratgias de TI prestadoras de servios e planos esto alinhados.
457 de 477
Um Grupo de Coordenao de TI inclui representantes de alto nvel do

negcio e do provedor de servios de TI.
ITIL
Um conjunto de orientaes de Melhores Prticas para o

Gerenciamento de Servios. ITIL de propriedade do OGC e consiste
de uma srie de publicaes com orientaes sobre a prestao de
Qualidade de Servios de TI, e sobre os processos e instalaes
necessrios para apoi-los. Veja www.itil.co.uk para mais informaes.
Descrio trabalho
Um documento que define os papis, responsabilidades, habilidades e

conhecimentos necessrios por uma pessoa em particular. Uma
descrio do trabalho pode incluir vrias funes, por exemplo, os
papis do Configuration Manager e Change Manager pode ser
realizada por uma pessoa.
Job Scheduling
(Operao de Servio) Planejamento e gerenciamento da execuo de

tarefas de software que so requeridos como parte de um servio de
TI. Job Scheduling realizado pela IT Operations Management, e
muitas vezes automatizado usando ferramentas de software que
rodam em lote ou tarefas on-line em horrios especficos do dia,
semana, ms ou ano.
Key Performance
Indicator
(Desenho de Servio) (Melhoria de Servio Continuada) Uma mtrica

que usado para ajudar a gerenciar um processo, servio ou
actividade. Muitas mtricas podem ser medidos, mas s o mais
importante deles so definidos como KPIs e usado para gerenciar
ativamente e informar sobre o processo, servio ou actividade. KPIs
devem ser selecionados para garantir que eficincia, eficcia e custoeficcia so geridos. Veja como Fator de Sucesso tambm Crtica.
Base de
Conhecimento
(Transio de Servio) Um banco de dados lgico que contm os

dados utilizados pelo Sistema de Gerenciamento de Servios de
Conhecimento.
Gesto do
Conhecimento
(Transio de Servio) O Processo responsvel pela coleta, anlise,

armazenamento e compartilhamento de conhecimento e informao
dentro de uma organizao. O principal objetivo da Gesto do
Conhecimento melhorar a eficincia, reduzindo a necessidade de
redescobrir o conhecimento. Veja tambm Servio de Sistema de
Gesto do Conhecimento.
Erro Conhecido
(Operao de Servio) Um problema que tem uma causa raiz

documentada e uma soluo alternativa. Erros Conhecidos so criados
e gerenciados durante todo seu ciclo de vida pelo Gerenciamento de
Problemas. Erros conhecidos tambm pode ser identificado por
Desenvolvimento ou Fornecedores.
Ciclo de Vida
As vrias fases na vida de um Servio de TI, Item de Configurao,

Incidentes, Problemas, Mudanas, etc O ciclo de vida define as
categorias para Estado e as transies de estado que so permitidos.
Por exemplo:
458 de 477
O Ciclo de Vida de uma Aplicao inclui

Requisitos, projetar, construir, implantar,
operar, Otimizar
O Ciclo de Vida do Incidente Expandido inclui
detectar, responder, Diagnosticar, reparar,

recuperar, restaurar
O ciclo de vida de um servidor podem incluir:
Pedido, recebeu, em teste, vivo, disposto, etc
Linha de Servio
(Estratgia de Servio) Um Core Service ou servio de apoio que tem

pacotes de mltiplos nveis de servio. Uma linha de servio
gerenciado por um gerente de produto e cada pacote de nvel de
servio projetado para suportar um determinado segmento de
mercado.
Viver
(Transio de Servio) Refere-se a um item de servio ou de

configurao de TI que est sendo usado para fornecer servio a um
cliente.
Viver Ambiente
(Transio de Servio) Um Ambiente controlado contendo itens de

configurao ao vivo usados para fornecer servios de TI para clientes.
Manutenibilidade
(Desenho de Servio) Uma medida de como o servio de forma rpida

e eficazmente um Item de Configurao ou pode ser restaurado ao
funcionamento normal aps uma falha. Manutenibilidade
frequentemente medido e relatado como MTRS.
Manutenibilidade tambm usado no contexto de Software ou IT
Development Service para significar capacidade de ser alterado ou
reparado facilmente.
Incidente grave
(Operao de Servio) Categoria mais alto de Impacto de um

Incidente. A Principais resultados incidente em perturbao
significativa para o negcio.
Servios Gerenciados
(Estratgia de Servio) Uma perspectiva em servios de TI que

enfatiza o fato de que eles so geridos. Os Servios Gerenciados
prazo tambm usado como sinnimo de servios de TI terceirizados.
Gesto da Informao
Informaes que so usadas para apoiar a tomada de deciso pelos

gestores. Gesto da informao muitas vezes gerado
automaticamente por ferramentas que suportam os diversos processos
de Gerenciamento de Servios. Gesto da Informao, muitas vezes
inclui os valores de KPIs como "porcentagem de alteraes que levam
a incidentes", ou "taxa de correo pela primeira vez".
Gesto de Risco
A metodologia de gerenciamento de riscos OGC. M_o_R inclui todas

as atividades necessrias para identificar e controlar a exposio ao
risco, o que pode ter um impacto sobre a realizao dos objetivos de
uma organizao de negcios. Veja www.m-o-r.org para mais
detalhes.
Sistema de Gesto
O quadro de polticas, processos e funes que garante uma

organizao pode alcanar seus objetivos.
Soluo manual
Uma soluo que requer a interveno manual. Soluo manual

tambm usado como o nome de uma opo de recuperao em que
o Business Process Funciona sem o uso de servios de TI. Esta uma
medida temporria e normalmente combinada com outra opo de
459 de 477
recuperao.
Maturidade
(Melhoria de Servio Continuada) Uma medida da, Organizao

Funo confiabilidade, eficincia e eficcia de um processo, etc Os
processos mais maduros e funes so formalmente alinhados aos
objetivos de negcio e estratgia, e so apoiados por um quadro de
melhoria contnua.
Tempo mdio entre

falhas
(Desenho de Servio) Uma Mtrica para medir e relatar Confiabilidade.

MTBF o tempo mdio que um Item de Configurao ou Servio de TI
pode desempenhar sua funo acordada sem interrupo. Este
medido a partir de quando o servio de CI ou ele comea a trabalhar,
at que prximo falhar.
Tempo mdio entre

Incidentes de Servio
(Desenho de Servio) A mtrica usada para medir e informar

Confiabilidade. TMEIS o tempo mdio de quando um sistema ou
servio de TI falhar, at que prximo falhar. TMEIS igual ao MTBF +
MTRS.
Mean Time To Repair
O tempo mdio para reparar um Item de Configurao ou Servio de

TI aps uma falha. MTTR medido a partir de quando o servio de CI
ou falhar at que seja consertado. MTTR no inclui o tempo
necessrio para recuperar ou restaurar. MTTR por vezes
incorretamente usado para significar tempo mdio para restaurar o
servio.
Tempo mdio para

restaurar o servio
O tempo mdio para restaurar um Item de Configurao ou Servio de

TI aps uma falha. MTRS medido a partir de quando o servio de CI
ou falhar at que seja totalmente restaurado e entregar a sua
funcionalidade normal. Veja tambm Manutenibilidade, Tempo mdio
para reparo.
Mtrico
(Melhoria de Servio Continuada) Algo que medido e relatado para

ajudar a gerenciar um processo, servio ou actividade. Veja tambm
KPI.
Middleware
(Desenho de Servio) O software que conecta duas ou mais

componentes de software ou aplicativos. Middleware geralmente
comprado de um Fornecedor, Em vez de desenvolver dentro do IT
Provedor de servios. Veja tambm fora da prateleira.
Modelo
Uma representao de um sistema, processo, servios de TI, Item de

Configurao, etc, que usado para ajudar a compreender e prever o
comportamento futuro.
Modelagem
Uma tcnica que usada para prever o comportamento futuro de um

sistema, processo, servios de TI, item de configurao, etc
Modelagem comumente usado em Gesto Financeira, Gesto de
Capacidade e Gerenciamento da Disponibilidade.
Monitoramento
(Operao de Servio) a observao repetida de um item de

configurao, servio ou processo para detectar eventos e para
garantir que a situao atual conhecido.
Objetivo
O objetivo definido ou fim de um processo, uma atividade ou de uma

Organizao como um todo. Os objetivos so geralmente expressa
460 de 477
como metas mensurveis. O Objetivo termo tambm usado

informalmente para significar uma exigncia. Veja tambm Resultado.
Off-the-shelf
Veja Commercial Off-the-shelf.
Office of Government
Commerce
OGC dona da marca ITIL (direitos autorais e marca registrada). OGC

um departamento do Governo do Reino Unido que suporta a entrega
da agenda do governo de aquisies por meio de seu trabalho nos
contratos de colaborao e no aumento dos nveis de habilidades e
capacidade de aquisio dentro dos departamentos. Ele tambm
fornece suporte para complexos projetos do setor pblico.
Off-shore
(Estratgia de Servio) Proviso de Servios a partir de um local fora

do pas onde o cliente baseia-se, muitas vezes em um continente
diferente. Esta pode ser a prestao de um servio de TI, ou de
funes de suporte, como um Service Desk. Veja tambm on-shore.
Em terra
(Estratgia de Servio) Proviso de servios de um local dentro do

pas, onde o cliente baseada. Veja tambm off-shore.
Operar
Para o desempenho esperado. Um processo ou Item de Configurao

dito para operar se est entregando os resultados desejados. Operar
tambm significa executar uma ou mais operaes. Por exemplo, para
operar um computador fazer as operaes do dia-a-dia necessrios
para que o desempenho esperado.
Operao
(Operao de Servio) a gesto do dia-a-dia de um servio de TI,

Sistema ou Item de Configurao outro. Operao tambm usada
para significar qualquer atividade pr-definido ou transao. Por
exemplo carregar uma fita magntica, aceitando dinheiro em um ponto
de venda, ou leitura de dados a partir de uma unidade de disco.
Operacional
O mais baixo dos trs nveis de Planejamento e de entrega

(Estratgico, Ttico, Operacional). Atividades operacionais incluem o
dia-a-dia de Planejamento ou de curto prazo ou entrega de um
processo de negcio ou de TI Processo de Gesto de Servio. O
termo operacional tambm um sinnimo para Live.
Custo Operacional
Custo resultante da execuo dos servios de TI. Muitas vezes,

repetindo pagamentos. Por exemplo os custos de pessoal,
manuteno de hardware e eletricidade (tambm conhecido como
"despesas correntes" ou "despesas receitas).
Acordo de Nvel
Operacional
(Desenho de Servio) (Melhoria de Servio Continuada) um acordo

entre um provedor de servio de TI e outra parte da mesma
organizao. Um OLA suporta a entrega do provedor de servio de TI,
servios de TI para clientes. O OLA define os bens ou servios a
serem prestados e as responsabilidades de ambas as partes. Por
exemplo, poderia haver um OLA:
461 de 477
Entre o prestador de servio de TI e um

departamento de compras para obter
hardware em tempos acordados
Entre o Service Desk e um grupo de apoio
para fornecer a resoluo de incidentes em
tempos acordados.
Ver tambm Acordo de Nvel de Servio.
Otimizar
Plano de Reviso e solicitar alteraes, a fim de obter a mxima

eficincia e eficcia de um processo, item de configurao, aplicao,
etc
Organizao
A empresa, pessoa jurdica ou outra instituio. Exemplos de

organizaes que no so empresas incluem International Standards
Organization ou itSMF. A Organizao termo por vezes utilizado para
se referir a qualquer entidade que tenha pessoas, recursos e
oramentos. Por exemplo, um projeto ou unidade de negcios.
Resultado
O resultado do exerccio de uma actividade, na sequncia de um

processo; entregar um servio de TI, etc O Resultado termo usado
para se referir a resultados pretendidos, bem como os resultados reais.
Veja tambm Objetivo.
Terceirizao
(Estratgia de Servio) Utilizando um prestador de servios externo

para gerenciar servios de TI.
Despesas gerais
Veja custo indireto.
Parceria
A relao entre duas organizaes que envolve o trabalho em conjunto

de objetivos comuns ou benefcio mtuo. O prestador de servios de TI
deve ter uma parceria com a empresa, e com terceiros, que so
crticos para a entrega de servios de TI. Ver tambm Rede de Valor.
Monitoramento
passivo
(Operao de Servio) O monitoramento de um item de configurao,

um servio de TI ou de um processo que depende de um alerta ou
notificao para descobrir o status atual.
Padro de Atividade
de Negcios
(Estratgia de Servio) Um perfil de carga de trabalho de uma ou mais

atividades empresariais. Padres de atividade de negcio so usados
para ajudar o prestador de servio de TI compreender e planejar para
os diferentes nveis de atividade comercial.
Atuao
Uma medida que alcanado ou entregue por um sistema, pessoa,

equipe, Processo, ou Servio de TI.
Gesto de
Desempenho
(Melhoria de Servio Continuada) O Processo responsvel pelo dia-adia de gerenciamento de capacidade. Estes incluem monitoramento,
limiar de deteco, anlise e ajuste de desempenho e alteraes de
execuo relativas ao desempenho e capacidade.
Piloto
(Transio de Servio) Implantao A limitada de um Servio de TI, um

lanamento ou um processo para o ambiente ao vivo. Um piloto
usado para reduzir o risco e para obter feedback do usurio e
aceitao. Veja tambm Avaliao de Testes.
Plano
Uma proposta detalhada que descreve as atividades e recursos

necessrios para atingir um objetivo. Por exemplo, um plano para
implementar um novo servio de TI ou processo. ISO / IEC 20000
requer um plano de gesto de cada um Processo de Gesto de
Servios de TI.
462 de 477
Plan-Do-Check-Act
(Melhoria de Servio Continuada) Um ciclo de quatro fases para a

gesto de processos, atribuda a Edward Deming. Plan-Do-Check-Act
tambm chamado de Ciclo de Deming.
PLANO: Desenho ou revisar processos que suportam os servios de
TI.
DO: Implementar o Plano e gerenciar os processos.
VERIFICAO: medir os processos e servios de TI, compare com
objetivos e produzir relatrios.
ACT: Planejar e implementar mudanas para melhorar os processos.
Tempo de inatividade
planejado
(Desenho de Servio) Acordado momento em que um servio de TI

no estar disponvel. Tempo de inatividade planejado
frequentemente usado para manuteno, atualizaes e testes. Veja
tambm Alterar Janela, O tempo de inatividade.
Planejamento
Uma Atividade responsvel pela criao de um ou mais planos. Por

exemplo, planejamento de capacidade.
PMBOK
Um padro de gerenciamento do Projeto mantida e publicada pelo

Project Management Institute. PMBOK significa Corpo de
Gerenciamento de Projetos do Conhecimento. Veja www.pmi.org para
mais informaes. Veja tambm PRINCE2.
Poltica
Formalmente documentado expectativas da administrao e intenes.

Polticas so usados para decises diretas, e para garantir o
desenvolvimento coerente e adequado e implementao de
processos, padres, papis, atividades, infra-estrutura de TI, etc
Facilidade porttil
(Desenho de Servio) Um edifcio pr-fabricado, ou um veculo de

grande porte, fornecido por um terceiro e se mudou para um local
quando necessrio por um Plano de Continuidade de Servio de TI.
Veja tambm opo de recuperao.
Ps-Implementao
comentrio
Uma reviso que ocorre depois de uma mudana ou um projeto foi

implementado. A PIR determina se a alterao ou projeto foi bem
sucedido, e identifica oportunidades de melhoria.
Prtica
A maneira de trabalhar, ou uma maneira em que o trabalho deve ser

feito. Prticas podem incluir atividades, processos, funes, normas e
orientaes. Veja tambm Best Practice.
Pr-requisito para o
sucesso
Uma atividade que precisa ser concluda, ou uma condio que

precisa ser cumprida, para permitir a implementao bem sucedida de
um Plano ou processo. A PFS frequentemente uma sada de um
processo que uma entrada necessria para outro processo.
Preos
(Estratgia de Servio) A Atividade para estabelecer o quanto os

clientes sero cobrados.
PRINCE2
O padro Reino Unido metodologia de governo para a gesto do

projeto. Veja www.ogc.gov.uk/prince2 para mais informaes. Veja
463 de 477
tambm PMBOK.
Prioridade
(Transio de Servio) (Operao de Servio) Uma Categoria usada

para identificar a importncia relativa de um incidente, problema ou
mudana. Prioridade baseada em impacto e urgncia, e usado
para identificar os tempos necessrios para as aes a serem
tomadas. Por exemplo, a SLA pode-se afirmar que a prioridade de dois
incidentes devem ser resolvidos dentro de 12 horas.
Problema
(Operao de Servio) Uma causa de um ou mais incidentes. A causa

geralmente no conhecido no momento um registro de problema
criado, eo processo de Gerenciamento de Problema responsvel por
uma investigao mais aprofundada.
Gerenciamento de
Problemas

de vida de todos os problemas. Os principais objetivos do
Gerenciamento de Problemas so para evitar incidentes de acontecer,
e para minimizar o impacto dos incidentes que no podem ser
evitados.
Procedimento
Um documento contendo os passos que especificam como realizar

uma atividade. Procedimentos so definidos como parte de Processos.
Ver tambm Instruo de Trabalho.
Processo
Um conjunto estruturado de atividades destinadas a alcanar um

objetivo especfico. Um processo leva uma ou mais entradas definidas
e as transforma em sadas definidas. Um processo pode incluir
qualquer um dos papis, responsabilidades, ferramentas e gesto de
controlos necessrios para entregar de forma confivel as sadas. Um
processo pode definir polticas, normas, orientaes, atividades e
Instrues de Trabalho, se eles so necessrios.
Controle de Processo
A atividade de planejamento e regulao de um processo, com o

objetivo de realizar o processo de forma eficaz, eficiente e consistente.
Proprietrio do
Processo
Um papel responsvel por garantir que um processo est apto para o

efeito. As responsabilidades do proprietrio do processo incluem
patrocnio, Design, Gesto de Mudana e melhoria contnua do
processo e suas mtricas. Este papel muitas vezes atribuda a
mesma pessoa que exerce a funo de Gerente de Processo, mas as
duas funes pode ser separado em organizaes maiores.
Proforma
Um documento de modelo, ou exemplo contendo dados de exemplo

que sero substitudos pelos valores reais quando estes esto
disponveis.
Programa
Uma srie de projetos e atividades que so planejadas e gerenciadas

em conjunto para alcanar um conjunto global de objectivos
relacionados e outros resultados.
Projeto
A Organizao temporria, com pessoas e outros Ativos necessrios

para atingir um resultado objetivo ou outro. Cada projeto tem um ciclo
de vida que normalmente inclui iniciao, planejamento, execuo,
encerramento, projetos etc geralmente so gerenciados usando uma
metodologia formal, como PRINCE2.
464 de 477
Qualidade
A capacidade de um produto, servio ou processo para fornecer o

valor pretendido. Por exemplo, um componente de hardware pode ser
considerado de elevada qualidade, se o desempenho esperado e
oferece a confiabilidade necessria. Qualidade processo tambm
exige uma capacidade de monitorar a eficcia e eficincia, e para
melhor-los, se necessrio. Veja tambm Sistema de Gesto da
Qualidade.
Sistema de Gesto da
Qualidade
(Melhoria de Servio Continuada) O conjunto de processos

responsveis por garantir que todo o trabalho realizado por uma
organizao de qualidade adequada para atender de forma confivel
Objetivos de negcios ou Nvel de servios. Veja tambm ISO 9000.
RACI
(Desenho de Servio) (Melhoria de Servio Continuada) Um modelo

usado para ajudar a definir papis e responsabilidades. RACI significa
Responsvel, responsvel, consultado e informado.
Acordo de
reciprocidade
(Desenho de Servio) uma opo de recuperao. Um acordo entre

duas organizaes para compartilhar recursos em uma emergncia.
Por exemplo, o espao Sala de Informtica ou o uso de um mainframe.
Registro
Um documento contendo os resultados ou outra sada a partir de um

processo ou atividade. Os registros so a prova de que uma atividade
ocorreu e pode ser papel ou eletrnico. Por exemplo, um relatrio de
auditoria, um registro de incidentes, ou as atas de uma reunio.
Recuperao
(Desenho de Servio) (Operao de Servio) Retornar um Item de

Configurao ou um Servio de TI para um estado de funcionamento.
Recuperao de um servio de TI, muitas vezes inclui a recuperao
de dados em um estado conhecido consistente. Aps a recuperao,
medidas adicionais podem ser necessrias antes de o servio que
pode ser disponibilizado para os Usurios (Restaurao).
Opo de
recuperao
(Desenho de Servio) Uma estratgia para responder a uma

interrupo de servio. Estratgias comumente usados so no fazer
nada, soluo manual, acordo de reciprocidade, recuperao gradual,
recuperao intermediria, rpida recuperao, recuperao imediata.
Opes de recuperao podem fazer uso de instalaes especficas
ou instalaes de terceiros compartilhados por vrias empresas.
Redundncia
Veja tolerncia a falhas.

O termo redundante tambm tem um significado genrico de obsoleto,
ou deixaram de ser necessrios.
Relao
Uma conexo ou interao entre duas pessoas ou coisas. Em Gesto

de Relacionamento de Negcios a interao entre o prestador de
servio de TI e de Negcios. Em Gerenciamento de Configurao,
um elo entre dois itens de configurao que identifica uma
dependncia ou conexo entre eles. Por exemplo candidaturas podem
ser ligados aos servidores so executadas. Servios de TI tem muitos
links para todos os itens de configurao que contribuam com eles.
Processos de
Relacionamento
A ISO / IEC 20000 Processo de grupo que inclui Gesto de Negcios e

Gesto de Relacionamento Fornecedor.
465 de 477
Solte
(Transio de Servio) Uma coleo de hardware, software,

documentao, processos ou outros componentes necessrios para
implementar uma ou mais aprovou alteraes aos servios de TI. O
contedo de cada lanamento so geridos, testado e implantado como
uma nica entidade.
Gerenciamento de
Liberao e
Implantao
(Transio de Servio) O Processo responsvel tanto Gerenciamento

de Liberao e Implantao.
Gerenciamento de
Liberao
(Transio de Servio) O Processo responsvel por planejar,

programar e controlar o movimento de lanamentos para testar e Live
Ambientes. O objetivo primrio do Gerenciamento de Liberao
garantir que a integridade do ambiente vivo est protegido e que os
componentes corretos so liberados. Gerenciamento de Liberao
parte do lanamento e Processo de Gesto de Implantao.
Registro de
Lanamento
(Transio de Servio) A Record no CMDB que define o contedo de

um comunicado. A Record Lanamento tem relaes com todos os
itens de configurao que so afectados pela libertao.
Confiana
(Desenho de Servio) (Melhoria de Servio Continuada) Uma medida

de quanto tempo um item de configurao ou servio de TI pode
desempenhar sua funo acordada sem interrupo. Normalmente
medida como MTBF ou TMEIS. A Confiabilidade termo tambm pode
ser usado para indicar como provvel que um processo, funo, etc
vai entregar suas sadas exigidas. Veja tambm disponibilidade.
Reparar
(Operao de Servio) A substituio ou correo de um item de

configurao falhou.
Requisio de
Mudana
(Transio de Servio) Uma proposta formal de alterao a ser feita.

Uma RFC inclui detalhes da mudana proposta, e pode ser registrada
em papel ou eletronicamente. O RFC termo freqentemente mal
utilizada para significar um registro de mudana, ou a mudana em si.
Cumprimento de
Requisio

de vida de todas as solicitaes de servio.
Exigncia
(Desenho de Servio) Uma declarao formal de que necessrio.

Por exemplo, um requisito de nvel de servio, uma exigncia do
projeto ou das entregas necessrias para um processo. Ver tambm
Declarao de requisitos.
Resilincia
(Desenho de Servio) A capacidade de um item de configurao ou

servio de TI para resistir falha ou recuperar rapidamente aps uma
falha. Por exemplo, um cabo blindado ir resistir falha quando
colocado sob estresse. Veja tambm tolerncia a falhas.
Resoluo
(Operao de Servio) Ao tomada para reparar a causa raiz de um

incidente ou problema, ou para implementar uma soluo alternativa.
Na norma ISO / IEC 20000, os processos de resoluo o grupo que
inclui Processo de Incidentes e Gesto de Problemas.
Recurso
(Estratgia de Servio) Um termo genrico que inclui infraestrutura de

TI, pessoas, dinheiro ou qualquer outra coisa que possa ajudar a
466 de 477
proporcionar um servio de TI. Os recursos so considerados ativos de

uma organizao. Veja tambm a capacidade, Servio de ativos.
Tempo de Resposta
Uma medida do tempo necessrio para completar uma operao ou

transao. Usado em Gerenciamento da Capacidade como uma
medida do desempenho de TI Infra-estrutura, e em Gerenciamento de
Incidentes como uma medida do tempo necessrio para atender o
telefone, ou para iniciar Diagnstico.
Capacidade de
resposta
A medio do tempo necessrio para responder a qualquer coisa. Este

poderia ser tempo de resposta de uma transao, ou a velocidade com
que um fornecedor de servios de TI responde a um incidente ou
solicitao de mudana, etc
Restaurao de
Servio
Veja Restaurar.
Restaurar
(Operao de Servio) Tomar medidas para devolver um servio de TI

aos Usurios aps reparao e recuperao de um incidente. Este o
principal objetivo do Gerenciamento de Incidentes.
Aposentar
(Transio de Servio) a remoo permanente de um servio de TI ou

Item de Configurao outro, do ambiente ao vivo. Aposentado uma
fase do ciclo de vida de muitos itens de configurao.
Retorno sobre
Investimento
(Estratgia de Servio) (Melhoria de Servio Continuada) Uma medida

do benefcio esperado de um investimento. No sentido mais simples
o lucro lquido de um investimento dividido pelo patrimnio lquido dos
ativos investidos.
Retornar para Normal
(Desenho de Servio) A fase de um Plano de Continuidade dos

Servios de completos durante o qual as operaes normais so
retomadas. Por exemplo, se um centro de dados alternativo est em
uso, ento essa fase vai trazer o centro de dados primrio de volta em
operao, e restaurar a capacidade de invocar TI Continuidade do
Servio de planos novamente.
Comente
A avaliao de uma Mudana, Problema, Processo, Project, etc

Comentrios so normalmente realizadas em pontos pr-definidos no
Ciclo de Vida e, especialmente, aps o encerramento. O propsito de
um comentrio garantir que todos os resultados foram fornecidos, e
identificar oportunidades de melhoria. Veja tambm Reviso psimplementao.
Direitos
(Operao de Servio) direitos ou permisses, concedidas a um

usurio ou funo. Por exemplo, o direito de modificar os dados
particulares, ou autorizar uma mudana.
Risco
Um evento possvel que possa causar danos ou perda, ou afetar a

capacidade de alcanar os objetivos. Um risco medido pela
probabilidade de uma ameaa, a vulnerabilidade do Activo a essa
ameaa, e do impacto que teria se ele ocorreu.
Avaliao de Risco
Os passos iniciais da gesto de risco. Analisando o valor dos ativos

para o negcio, identificando ameaas a esses ativos, e avaliar como
cada ativo vulnervel a essas ameaas. Avaliao de Risco pode ser
467 de 477
quantitativa (com base em dados numricos) ou qualitativa.

Gesto de risco
O Processo responsvel pela identificao, avaliao e controle de

riscos. Veja tambm Avaliao de Risco.
Papel
Um conjunto de responsabilidades, atividades e autoridades

concedidas a uma pessoa ou equipe. Um papel definido em um
processo. Uma pessoa ou equipe pode ter vrias funes, por
exemplo, os papis do Configuration Manager e Change Manager
pode ser realizada por uma nica pessoa.
Causa raiz
(Operao de Servio) A causa subjacente ou original de um incidente

ou problema.
Custos de
funcionamento
Veja Custo Operacional.
Escalabilidade
A capacidade de um Servio de TI, Processo, Item de Configurao,

etc, para executar sua funo acordada quando as mudanas de
carga de trabalho ou de escopo.
Escopo
O limite, ou extenso, para que um processo, procedimento contrato

de certificao, etc se aplica. Por exemplo, o escopo de
Gerenciamento de Mudana pode incluir todos ao vivo Servios de TI
e itens de configurao relacionados, o escopo de uma norma ISO /
IEC 20000 Certificado pode incluir todos os servios de TI entregues
fora de um centro de dados chamado.
Segurana
Consulte Informaes Gesto de Segurana.
Gesto de Segurana
Consulte Informaes Gesto de Segurana.
Poltica de segurana
Consulte Informaes Poltica de Segurana.
Separao de
preocupaes
(Estratgia de Servio) Uma abordagem para a criao de uma

soluo ou servio de TI que divide o problema em partes que podem
ser resolvidos de forma independente. Essa abordagem separa "o
que" est a ser feito a partir de "como" para ser feito.
Servidor
(Operao de Servio) Um computador que esteja conectado a uma

rede e fornece funes de software que so utilizados por outros
computadores.
Servio
Um meio de entregar valor aos clientes, facilitando Resultados clientes

querem alcanar, sem a posse de Custos e riscos especficos.
Critrios de aceitao
de servios
(Transio de Servio) Um conjunto de critrios utilizados para garantir

que um servio de TI cumpre a sua funcionalidade e requisitos de
qualidade e que o provedor de servio de TI est pronta para operar o
servio de TI novo quando foi implantado. Veja tambm Aceitao.
Servio de ativos
Qualquer capacidade ou recurso de um Provedor de servios. Veja

tambm Ativos.
Gerenciamento da
Capacidade de
servio
(Desenho de Servio) (Melhoria de Servio Continuada) A Atividade

responsvel por entender o desempenho ea capacidade de servios
de TI. Os recursos usados por cada Servio de TI e o padro de uso
468 de 477
ao longo do tempo so coletados, registrados e analisados para uso

no Plano de Capacidade. Veja tambm Negcios Capacidade,
Gerenciamento de Capacidade de componentes.
Catlogo de Servios

estruturado com informaes sobre todos os servios de TI ao vivo,
incluindo os disponveis para a implantao. O Catlogo de Servios
a nica parte do portflio de servios publicado aos Clientes, e
usado para apoiar a venda e entrega de servios de TI. O Catlogo de
Servio inclui informaes sobre entregas, preos, pontos de contacto,
ordenao e processos de solicitao.
Gesto da
Continuidade do
Servio
Veja TI Gesto da Continuidade do Servio.
Cultura de servio
Uma cultura orientada ao cliente. Os principais objectivos de uma

cultura de servio so a satisfao do cliente e ajudando os clientes a
atingir seus objetivos de negcios.
Design de Servios
(Desenho de Servio) Uma fase no Ciclo de Vida de um Servio de TI.

Design de Servios inclui uma srie de processos e funes e o ttulo
de um dos ITIL Ncleo publicaes. Veja tambm Design.
Pacote de Desenho
de Servio
(Desenho de Servio) documento (s) a definio de todos os aspectos

de um servio de TI e seus requisitos atravs de cada estgio de seu
ciclo de vida. Um Pacote de Desenho de Servio produzido para
cada Servio de TI novo, grande mudana, ou TI Aposentadoria
Servio.
Service Desk
(Operao de Servio) O ponto nico de contato entre o prestador de

servios e os usurios. Uma Central de Servios tpico gerencia
incidentes e solicitaes de servios, e tambm lida com a
comunicao com os usurios.
Anlise de falha de
servio
(Desenho de Servio) Uma Atividade que identifica as causas

subjacentes de uma ou mais interrupes do servio de TI. SFA
identifica oportunidades para melhorar os processos de o prestador de
servios de TI e ferramentas, e no apenas a infraestrutura de TI. SFA
um tempo limitado, a atividade de projeto semelhante, em vez de um
processo contnuo de anlise.
Horas de servio
(Desenho de Servio) (Melhoria de Servio Continuada) Um perodo

de tempo acordado quando um determinado servio de TI deve estar
disponvel. Por exemplo, 'Segunda-feira a Sexta-feira 8:00-17:00,
exceto feriados. Horas de servio devem ser definidos em um Acordo
de Nvel de Servio.
Plano de Melhoria de
Servio
(Melhoria de Servio Continuada) um plano formal para implementar

melhorias a um processo ou servio de TI.
Servio do Sistema
de Gesto do
Conhecimento
(Transio de Servio) Um conjunto de ferramentas e bases de dados

que so usados para gerenciar conhecimento e informao. Os SKMS
inclui o Sistema de Gerenciamento de Configurao, bem como outras
ferramentas e bancos de dados. O lojas SKMS, gerencia as
atualizaes, e apresenta todas as informaes de que um provedor
469 de 477
de servio de TI precisa gerenciar o ciclo de vida completo de servios

de TI.
Nvel de servio
Medido e relatado conquista contra um ou mais objetivos de nvel de

servio. O nvel de servio termo por vezes usado informalmente
para significar objetivo de nvel de servio.
Acordo de Nvel de
Servio
(Desenho de Servio) (Melhoria de Servio Continuada) um acordo

entre um provedor de servios de TI e um Cliente. O SLA descreve o
servio de TI, objetivos de nvel de documentos de servio, e
especifica as responsabilidades do fornecedor de servios de TI eo
cliente. Uma nica SLA pode abranger vrios servios de TI ou
clientes mltiplos. Veja Acordo de Nvel Operacional tambm.
Gerenciamento de
Nvel de Servio
(Desenho de Servio) (Melhoria de Servio Continuada) O Processo

responsvel por negociar Acordos de Nvel de Servio, e garantir que
estes sejam cumpridos. SLM responsvel por garantir que todos os
processos de TI Service Management, Acordos de Nvel Operacional e
Contratos de Apoio, so adequadas para os objetivos de nvel de
servio acordado. SLM monitores e relatrios sobre os nveis de
servio, e mantm Opinies regulares.
Pacote de Nvel de
Servio
(Estratgia de Servio) Um nvel definido de Utilidade e Garantia para

um pacote de servios especfico. Cada SLP projetado para atender
as necessidades de um padro particular de atividade empresarial.
Veja tambm Linha de Servio.
Exigncia de Nvel de
Servio
(Desenho de Servio) (Melhoria de Servio Continuada) uma exigncia

do cliente para um aspecto de um Servio de TI. SLRs so baseados
em objetivos de negcios e so usados para negociar objetivos de
nvel de servio acordado.
Meta de nvel de
servio
(Desenho de Servio) (Melhoria de Servio Continuada) Um

compromisso que documentado em um Acordo de Nvel de Servio.
Metas de nvel de servio so baseados em Requisitos de Nvel de
Servio, e so necessrias para garantir que o Design de Servios de
TI est apto para o efeito. Metas de nvel de servio devem ser
SMART, e normalmente so baseados em KPIs.
Servio de Gesto de
Service Management um conjunto de capacidades especializadas

organizacionais para o valor aos clientes na forma de servios.
Servio de Gesto de
ciclo de vida
Uma abordagem para IT Service Management, que enfatiza a

importncia da coordenao e controle em diversas funes,
processos e sistemas necessrios para gerenciar o ciclo de vida de
servios de TI. O Servio de Gerenciamento abordagem de ciclo de
vida considera que a estratgia, projeto, transio, operao e
melhoria contnua dos servios de TI.
Service Manager
Um gestor que responsvel por gerenciar o ciclo de vida de ponta a

ponta de um ou mais servios de TI. O Gerenciador de Servios termo
tambm usado para significar qualquer gestor dentro do provedor de
servio de TI. Mais comumente usado para se referir a um Gerente de
Relacionamento de Negcios, Gerente de Processos, Gerente de
Contas ou um gerente snior com a responsabilidade de Servios de
TI em geral.
470 de 477
Operao de Servio
(Operao de Servio) Uma fase no Ciclo de Vida de um Servio de

TI. Operao de Servio inclui uma srie de processos e funes e o
ttulo de um dos ITIL Ncleo publicaes. Veja tambm Operao.
Proprietrio do
servio
(Melhoria de Servio Continuada) um papel que responsvel pela

entrega de um servio de TI especfica.
Portflio de Servios
(Estratgia de Servio) O conjunto completo de servios que so

gerenciados por um provedor de servio. O portflio de servios
usado para gerenciar o ciclo de vida de todos os Servios, e inclui trs
categorias: Servio de Pipeline (proposto ou em desenvolvimento);
Catlogo de Servio (Live ou disponveis para implantao) e Servios
de aposentados. Ver tambm Gesto de Portflio de Servios.
Gesto de Portflio
de Servios
(Estratgia de Servio) O Processo responsvel por gerenciar o

portflio de servios. Gesto de Portflio de Servio considera
Servios em termos de valor de negcios que eles proporcionam.
Provedor de servios
(Estratgia de Servio) Uma Organizao prestao de servios a um

ou mais clientes internos ou clientes externos. Prestador de servio
muitas vezes usada como uma abreviao para a TI do provedor de
servio.
Servio de relatrio
(Melhoria de Servio Continuada) O Processo responsvel pela

produo e entrega de relatrios de desempenho e as tendncias em
relao aos nveis de servio. Relatrios de servio deve concordar o
formato, contedo e frequncia dos relatrios com os Clientes.
Solicitao de servio
(Operao de Servio) Um pedido de um usurio para obter

informaes ou conselhos, ou para uma mudana de padro ou de
acesso a um servio de TI. Por exemplo, para redefinir uma senha, ou
a prestao de servios de TI padro para um novo usurio.
Solicitaes de servios so geralmente tratado por um Service Desk,
e no necessitam de uma RFC para ser apresentado. Veja tambm
Pedir Cumprimento.
Estratgia de Servio
(Estratgia de Servio) O ttulo de um dos ITIL Ncleo publicaes.

Estratgia de servio estabelece uma estratgia global de servios de
TI e de IT Service Management.
Transio de Servio
(Transio de Servio) Uma fase no Ciclo de Vida de um Servio de

TI. Transio de Servio inclui uma srie de processos e funes e o
ttulo de um dos ITIL Ncleo publicaes. Ver tambm Transio.
Garantia de servio
(Estratgia de Servio) Garantia de que um servio de TI ir atender

aos requisitos acordados. Este pode ser um acordo formal, como um
Acordo de Nvel de Servio ou Contrato, ou pode ser uma mensagem
de marketing ou imagem de marca. O valor de negcio de um Servio
de TI criado pela combinao de Service Utility (o que o servio faz)
e garantia de servio (como ele faz isso). Ver tambm Garantia.
Manuteno
(Desenho de Servio) (Melhoria de Servio Continuada) A capacidade

de um terceiro fornecedor de cumprir os termos de seu contrato. Este
Contrato incluir os nveis acordados de Confiabilidade
Sustentabilidade, ou disponibilidade para um item de configurao.
471 de 477
Deslocar
(Operao de Servio) Um grupo ou equipe de pessoas que realizam

uma funo especfica, por um perodo fixo de tempo. Por exemplo,
poderia haver quatro turnos de Operaes de TI controle de pessoal
para suportar um servio de TI que usado 24 horas por dia.
Modelagem,
simulao
(Desenho de Servio) (Melhoria de Servio Continuada) Uma tcnica

que cria um modelo detalhado para prever o comportamento de um
item de configurao ou servio de TI. Modelos de simulao podem
ser muito precisos, mas so caro e demorado para criar. Um modelo
de simulao muitas vezes criado usando os itens de configurao
reais que esto sendo modelados, com cargas de trabalho artificiais ou
transaes. Eles so usados em Gesto de Capacidade quando
resultados precisos so importantes. Um modelo de simulao s
vezes chamado de Referncia de Desempenho.
Ponto nico de falha
(Desenho de Servio) qualquer item de configurao que pode causar

um incidente quando falha, e para os quais uma contramedida no foi
implementado. A SPOF pode ser uma pessoa, ou um passo em um
processo ou atividade, bem como um componente da infra-estrutura
de TI. Veja tambm falha.
A SMART
(Desenho de Servio) (Melhoria de Servio Continuada) Um acrnimo

para ajudar a lembrar que os objectivos em Acordos de Nvel de
Servio e Planos de projeto devem ser especficos, mensurveis,
atingveis, relevantes e oportunas.
Especificao
Uma definio formal de Requisitos. A especificao pode ser usada

para definir os requisitos tcnicos e operacionais, e pode ser interna ou
externa. Muitas normas pblicas consistem de um Cdigo de Prtica e
uma Especificao. A especificao define o padro contra o qual uma
organizao pode ser auditado.
Stakeholder
Todas as pessoas que tm interesse em uma Organizao do Projeto,

Servios de TI, etc Stakeholders pode estar interessado nas
atividades, metas, recursos, ou entregas. As partes interessadas
podem incluir clientes, parceiros, funcionrios, acionistas, proprietrios,
etc Veja tambm RACI.
Padro
Um requisito obrigatrio. Exemplos incluem ISO / IEC 20000 (um

padro internacional), um padro de segurana interna para a
configurao do Unix, ou um padro do governo para saber como
registros financeiros devem ser mantidos. O Standard termo tambm
usado para se referir a um Cdigo de Prtica ou Especificao
publicado por uma organizao de padres como ISO ou BSI. Veja
tambm orientao.
Espera
(Desenho de Servio) Usado para se referir a recursos que no so

necessrios para entregar os servios de TI ao vivo, mas esto
disponveis para apoiar TI Planos de Continuidade de Servio. Por
exemplo, um centro de dados de espera pode ser mantido para apoiar
Hot Standby, espera aquecido ou frio arranjos de espera.
Declarao de
requisitos
(Desenho de Servio) Um documento contendo todas as exigncias

para a compra do produto, ou um novo ou alterado Servio de TI. Ver
tambm Termos de referncia.
472 de 477
Estado
O nome de um campo obrigatrio em muitos tipos de Record. Ele

mostra o estgio atual do ciclo de vida do item de configurao
associado, incidentes, problemas, etc
Estratgico
(Estratgia de Servio) O mais alto dos trs nveis de Planejamento e

de entrega (Estratgico, Ttico, Operacional). Atividades Estratgicas
incluem definio de objetivo e planejamento de longo prazo para
alcanar a viso global.
Estratgia
(Estratgia de Servio) Um Plano Estratgico concebido para alcanar

objetivos definidos.
Fornecedor
(Estratgia de Servio) (Desenho de Servio) um terceiro responsvel

pelo fornecimento de bens ou servios que so necessrios para
entregar servios de TI. Exemplos de fornecedores incluem hardware
commodity e fornecedores de software, rede e provedores de
telecomunicaes e Organizaes de terceirizao. Ver tambm
Subjacente Contrato,Cadeia de suprimentos.
Fornecedor e Banco
de Dados Contrato

estruturado usado para gerenciar contratos de fornecedores ao longo
do seu ciclo de vida. O SCD contm atributos-chave de todos os
contratos com fornecedores, e devem fazer parte do Sistema de
Gerenciamento de Servios de Conhecimento.
Gesto de
Fornecedores
(Desenho de Servio) O Processo responsvel por garantir que todos

os contratos com fornecedores de suportar as necessidades do
negcio, e que todos os fornecedores cumpram os seus compromissos
contratuais.
Cadeia de
suprimentos
(Estratgia de Servio) As Atividades em uma Cadeia de Valor

realizado por Fornecedores. Uma cadeia de suprimentos normalmente
envolve vrios fornecedores, cada um agregando valor ao produto ou
servio. Ver tambm Rede de Valor.
Grupo de apoio
(Operao de Servio) Um grupo de pessoas com habilidades

tcnicas. Os grupos de apoio fornecer o apoio tcnico necessrio a
todos os Processos de Gesto de Servios de TI. Ver tambm Gesto
tcnica.
Horas de suporte
(Desenho de Servio) (Operao de Servio) Os tempos ou horas,

quando o apoio est disponvel para os usurios. Normalmente estas
so as horas em que o Service Desk est disponvel. Horas de suporte
devem ser definidos em um Acordo de Nvel de Servio, e pode ser
diferente da hora de servio. Por exemplo, as horas de servio pode
ser de 24 horas por dia, mas as horas de suporte podem ser 7:0019:00.
Servios de apoio
(Estratgia de Servio) um servio que permite ou melhora um servio

essencial. Por exemplo, um servio de diretrio ou um servio de
backup.
A anlise SWOT
(Melhoria de Servio Continuada) Uma tcnica que analisa e analisa

os pontos fortes e fraquezas internas de uma organizao e as
oportunidades e ameaas externas que enfrenta SWOT significa
Foras, Fraquezas, Oportunidades e Ameaas.
473 de 477
Sistema
Uma srie de coisas relacionadas que trabalham em conjunto para

alcanar um objetivo global. Por exemplo:
Um sistema de computador, incluindo

hardware, software e aplicativos
Um sistema de gesto, incluindo vrios
processos que so planejados e gerenciados
em conjunto. Por exemplo, um Sistema de
Gesto da Qualidade
Um Sistema de Gerenciamento de Banco de
Dados ou Sistema Operacional que inclui
mdulos de software que so projetados para
realizar um conjunto de funes relacionadas.
Sistema de Gesto de
A parte da IT Service Management que se concentra na gesto de

infraestrutura de TI ao invs de processo.
Ttico
O meio de trs nveis de Planejamento e de entrega (Estratgico,

Ttico, Operacional). Atividades tticas incluem os planos de mdio
prazo necessrios para atingir objetivos especficos, normalmente
durante um perodo de semanas a meses.
Gesto tcnica
(Operao de Servio) A Funo responsvel por fornecer

competncias tcnicas de apoio de servios de TI e gesto da infraestrutura de TI. Gesto tcnica define os papis dos grupos de apoio,
bem como as ferramentas, processos e procedimentos necessrios.
Servio tcnico
Veja Servio de Infra-estrutura.
Suporte tcnico
Ver Gesto tcnica.
Termos de referncia
(Desenho de Servio) Um documento especificando os requisitos,

escopo, entregas, Recursos e cronograma para um projeto ou
atividade.
Teste
(Transio de Servio) Uma Atividade que verifica se um item de

configurao, servio, processo, etc cumpre a sua Especificao
Requisitos ou acordado. Veja tambm Aceitao.
Terceiro
Uma pessoa, grupo ou empresa que no faz parte do Acordo de Nvel

de Servio para um servio de TI, mas necessrio para garantir a
entrega bem sucedida do Servio de TI. Por exemplo, um fornecedor
de software, uma empresa de manuteno de hardware, ou um
departamento de instalaes. Requisitos para terceiros so
normalmente especificada na sustentao Contratos ou Acordos de
Nvel Operacional.
Terceira linha de
apoio
(Operao de Servio) O terceiro nvel em uma hierarquia de grupos

de apoio envolvidos na resoluo de incidentes e investigao de
problemas. Cada nvel contm habilidades mais especializadas, ou
tem mais tempo ou outros recursos.
Ameaa
Qualquer coisa que possa explorar uma vulnerabilidade. Qualquer

causa potencial de um incidente pode ser considerado uma ameaa.
Por exemplo, um incndio uma ameaa que pode explorar a
474 de 477
vulnerabilidade de revestimentos inflamveis. Este termo comumente

usado em Gesto de Segurana da Informao e Gerenciamento de
Continuidade do Servio, mas tambm se aplica a outras reas, como
Problema e Gerenciamento de Disponibilidade.
Limiar
O valor de uma mtrica que deve causar um alerta a ser gerado, ou de

gesto a adoptar. Por exemplo "Incidente Prioridade 1 no resolvido
em quatro horas", "mais de cinco erros de disco moles em uma hora",
ou "mais de 10 mudanas no em um ms.
Vazo
(Desenho de Servio) Uma medida do nmero de transaes, ou

outras operaes, realizadas em um tempo fixo. Por exemplo, 5.000 emails enviados por hora, ou 200 de disco I / Os por segundo.
Custo Total de
Propriedade
(Estratgia de Servio) Uma metodologia usada para ajudar a tomar

decises de investimento. TCO avalia o Custo do Ciclo de Vida cheia
de possuir um item de configurao, no apenas o custo inicial ou
preo de compra.
Transao
Uma funo discreta realizada por um servio de TI. Por exemplo

transferir dinheiro de uma conta bancria para outra. Uma nica
operao pode envolver inmeros acrscimos, supresses e
modificaes de dados. Ou todos estes completo com xito ou
nenhuma delas realizada.
Transio
(Transio de Servio) Uma mudana no estado, o que corresponde a

um movimento de um servio de TI ou Item de Configurao de um
outro estado de Ciclo de Vida para a prxima.
Anlise de tendncias
(Melhoria de Servio Continuada) Anlise de dados para identificar

padres relacionados com o tempo. Anlise de tendncias usado em
Gerenciamento de Problema para identificar falhas comuns ou itens de
configurao frgeis, e em Gerenciamento da Capacidade como uma
ferramenta de modelagem para prever o comportamento futuro. Ele
tambm usado como uma ferramenta de gesto para identificao
de deficincias nos processos de Gerenciamento de Servios.
Afinao
A Atividade responsvel por planejar mudanas para tornar o uso mais

eficiente dos recursos. Tuning parte de Gesto de Desempenho, que
tambm inclui o monitoramento de desempenho e implementao das
mudanas necessrias.
Subjacente Contrato
(Desenho de Servio) um contrato entre um fornecedor de servios de

TI e um terceiro. O terceiro fornecer bens ou servios que suportam a
entrega de um servio a um cliente. O Contrato Subjacente define
metas e responsabilidades que so necessrias para cumprir as metas
de servio acordado em um nvel SLA.
Urgncia
(Transio de Servio) (Desenho de Servio) Uma medida de quanto

tempo ser at que um incidente, problema ou mudana tem um
impacto significativo sobre o negcio. Por exemplo, um incidente de
alto impacto podem ter Urgncia baixo, se o impacto no afetar o
negcio at o final do exerccio financeiro. Impacto e Urgncia so
usados para atribuir prioridade.
Usabilidade
(Desenho de Servio) A facilidade com que um aplicativo, produto, ou
475 de 477
servio de TI pode ser utilizada. Requisitos de Usabilidade so

freqentemente includos em uma declarao de requisitos.
Caso de Uso
(Desenho de Servio) Uma tcnica usada para definir funcionalidade e

objectivos, e para projetar testes. Casos de Uso definir cenrios
realistas que descrevem as interaes entre usurios e um servio de
TI ou outro sistema.
Usurio
Uma pessoa que usa o servio de TI em uma base dia-a-dia. Usurios

so distintos de clientes, como alguns clientes no usar o servio
diretamente.
Utilidade
(Estratgia de Servio) Funcionalidade oferecida por um produto ou

servio para atender a uma necessidade especfica. Utilidade muitas
vezes resumido como "o que ele faz".
Validao
(Transio de Servio) Uma Atividade que garante um novo ou

alterado Servio de TI, Processo, Plano, ou Deliverable outro atende
s necessidades do negcio. A validao garante que Requisitos de
Negcio so atendidas mesmo que estes podem ter mudado desde
que o projeto original. Ver tambm Verificao, Aceitao.
Cadeia de Valor
(Estratgia de Servio) Uma sequncia de processos que cria um

produto ou servio que de valor para um cliente. Cada passo da
sequncia baseia-se nas etapas anteriores e contribui para o produto
final, ou de servio. Ver tambm Rede de Valor.
Value for Money
Uma medida informal de rentabilidade. Custo-benefcio muitas vezes

baseada em uma comparao com o custo de alternativas. Veja
tambm Anlise de Custo-Benefcio.
Rede de Valor
(Estratgia de Servio) Um conjunto complexo de relaes entre dois

ou mais grupos ou organizaes. Valor gerado por meio do
intercmbio de conhecimentos, informaes, produtos ou servios. Ver
tambm Cadeia de Valor, Parceria.
Variao
A diferena entre o valor previsto e o valor real medido. Comumente

usado em Gesto Financeira, Gesto de Capacidade e Gerenciamento
de Nvel de Servio, mas pode ser aplicvel em qualquer rea onde os
planos esto no lugar.
Verificao
(Transio de Servio) Uma Atividade que garante um novo ou

alterado Servio de TI, Processo, Plano, ou qualquer outra prestao
completa, precisa, confivel e corresponde ao seu projeto
especificao. Ver tambm Validao, Aceitao.
Verso
(Transio de Servio) Uma verso utilizado para identificar uma

linha de base especfica de um item de configurao. Verses
tipicamente usam uma conveno de nomeao que permite a
seqncia ou data de cada linha de base a ser identificado. Por
exemplo folha de pagamento 3 Verso aplicativo contm
funcionalidade atualizada a partir da verso 2.
Viso
Uma descrio do que a Organizao pretende tornar-se no futuro.

Uma viso criado pela alta administrao e usado para ajudar
Cultura influncia e Planejamento Estratgico.
476 de 477
Funo de Negcios
Vital
(Desenho de Servio) uma funo de um processo de negcio que

fundamental para o sucesso do negcio. Funes vitais para os
negcios so uma considerao importante de Gesto de
Continuidade de Negcios, Gerenciamento da Continuidade de
Servio e Gerenciamento de Disponibilidade.
Vulnerabilidade
Uma fraqueza que pode ser explorada por uma ameaa. Por exemplo,
uma porta de firewall aberto, uma senha que nunca alterado, ou um
tapete inflamvel. A falta de controle tambm considerado uma
vulnerabilidade.
Espera quente
Veja Recuperao Intermedirio.
Garantia
(Estratgia de Servio) Uma promessa ou garantia de que um produto

ou servio ir satisfazer os seus requisitos acordados. Ver tambm
Garantia de servio.
Instruo de Trabalho
Um documento contendo instrues detalhadas que especificam

exatamente o que os passos a seguir para realizar uma atividade. A
Instruo de Trabalho contm muito mais detalhes do que um
Procedimento e criada apenas se instrues muito detalhadas so
necessrias.
Soluo
(Operao de Servio) Reduzir ou eliminar o impacto de um incidente

ou problema para o qual uma resoluo completa ainda no est
disponvel. Por exemplo, reiniciando um item de configurao falhou.
Solues alternativas para problemas so documentadas em registros
de erro conhecidas. Solues alternativas para a incidentes que no
tm registros de problemas associados esto documentadas no
registro de incidentes.
Workload
Os recursos necessrios para entregar uma parte identificvel de um

Servio de TI. Cargas de trabalho podem ser classificados por
usurios, grupos de usurios, ou funes no mbito do Servio de TI.
Isto usado para auxiliar na anlise e gesto do desempenho,
capacidade e utilizao de itens de configurao e servios de TI. A
carga de trabalho termo usado s vezes como sinnimo de
throughput.
477 de 477

Itil v3 Design de Serviços

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Itil v3 Design de Serviços

Загружено:

Авторское право:

Доступные форматы

ITIL Verso 3

ITIL V3 - Service Design - Pgina:

O Core ITIL composto por cinco publicaes. Cada uma

ITIL V3 - Service Design - Pgina:

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

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

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

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

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

ITIL V3 - Service Design - Pgina:

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

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

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

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

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

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

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

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

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

4,3 Gerenciamento da Capacidade............................................................................ 143

ITIL V3 - Service Design - Pgina:

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

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

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

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

4.3.9 Desafios, Fatores Crticos de Sucesso e riscos.................................................... 175

4.4 Gerenciamento de Disponibilidade ...................................................................... 177

4.4.6 Triggers, entradas, sadas e interfaces................................................................. 222

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

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

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

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

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

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

ITIL V3 - Service Design - Pgina:

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

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

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

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

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

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

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

5 Servios de design de tecnologia actividades relacionadas com o ............... 306

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

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

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

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

ITIL V3 - Service Design - Pgina:

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

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

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

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

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

ITIL V3 - Service Design - Pgina:

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

8,5 Medio de Design de Servios ........................................................................... 382

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

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

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

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

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

ITIL V3 - Service Design - Pgina:

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