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

Itil v3 operação de serviço

on

  • 9,314 views

 

Statistics

Views

Total Views
9,314
Views on SlideShare
9,314
Embed Views
0

Actions

Likes
1
Downloads
297
Comments
1

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • ITIL Versão 3 Operação de Serviço ITIL V3 - Operação de Serviço - Página: 1 de 423
    • O Core ITIL é composto por cinco publicações. Cada uma delas fornece a orientação necessária para uma abordagem integrada, tal como exigido pela ISO / IEC 20000 padrão especificação: • Estratégia de Serviço • Design de Serviços • Transição de Serviço • Operação de Serviço • Melhoria de Serviço Continuada. ITIL V3 - Operação de Serviço - Página: 2 de 423
    • I N D I C E Prefácio .............................................................................................................12 Prefácio da OGC........................................................................................................... 12 Prefácio Arquiteto Chefe............................................................................................... 13 Prefaciar............................................................................................................14 Informações de contato ................................................................................................ 14 Agradecimentos.................................................................................................15 Arquiteto-chefe e autores ............................................................................................. 15 ITIL autoria da equipe................................................................................................... 15 Mentores ....................................................................................................................... 15 Outras contribuições..................................................................................................... 15 O ITIL Grupo Consultivo..................................................................................................16 Revisores.........................................................................................................................16 1 Introdução ......................................................................................................17 1.1 Visão Geral ............................................................................................................. 18 1,2 Contexto.................................................................................................................. 19 1.2.1 Gestão de Serviços ................................................................................................19 1.2.2 Boas práticas no domínio público...........................................................................19 1.2.3 ITIL e boas práticas em Gestão de Serviços ..........................................................21 1.2.3.1 Estratégia de Serviço.................................................................................................. 23 1.2.3.2 Design de Serviços..................................................................................................... 23 1.2.3.3 Transição de Serviço .................................................................................................. 24 1.2.3.4 Operação de Serviço .................................................................................................. 24 1.2.3.5 Melhoria de Serviço Continuada.................................................................................. 24 1,3 Propósito................................................................................................................. 26 1,4 Uso.......................................................................................................................... 26 1,5 Visão geral do capítulo ........................................................................................... 27 2 Gerenciamento de Serviço como uma prática ................................................28 2.1 O que é Gerenciamento de Serviços?................................................................... 28 2.2 O que são serviços?............................................................................................... 30 2.2.1 O valor proposição..................................................................................................30 2.3 Funções e processos em todo o ciclo de vida....................................................... 31 2.3.1 Funções..................................................................................................................31 2.3.2 Processos...............................................................................................................31 2.3.3 Especialização e coordenação em todo o ciclo de vida..........................................32 2.4 Operação fundamentos Serviço............................................................................. 33 2.4.1 Finalidade objetivo / / objetivo.................................................................................33 2.4.2 Âmbito ....................................................................................................................33 2.4.3 Valor para os negócios...........................................................................................34 2.4.4 Otimização do desempenho do Serviço de Operação............................................35 2.4.5 Processos dentro de Operação de Serviço ............................................................35 2.4.5.1 Gestão de Eventos ..................................................................................................... 35 2.4.5.2 Incidentes e Gestão de Problemas.............................................................................. 35 2.4.5.3 Cumprimento de Requisição ....................................................................................... 36 2.4.5.4 Gerenciamento de Acesso .......................................................................................... 36 2.4.6 Funções dentro de Operação de Serviço ...............................................................36 2.4.6.1 Service Desk............................................................................................................... 37 2.4.6.2 Gestão Técnica........................................................................................................... 37 2.4.6.3 Gestão de Operações de TI ........................................................................................ 37 2.4.6.4 Gerenciamento de Aplicativos..................................................................................... 37 2.4.6.5 Interfaces para outros estágios Serviço Lifecycle Management ................................... 38 ITIL V3 - Operação de Serviço - Página: 3 de 423
    • 3 Operação princípios do serviço ......................................................................39 3,1 Funções, grupos, equipes, departamentos e divisões .......................................... 40 Alcançar 3,2 equilíbrio na Operação de Serviço.......................................................... 42 3.2.1 TI interna ver contra vista de negócios externo ......................................................42 3.2.2 Estabilidade em relação a capacidade de resposta................................................46 3.2.3 A qualidade do serviço versus custo do serviço .....................................................49 3.2.4 reativa contra proativo ............................................................................................52 3,3 prestação de serviços............................................................................................. 57 3,4 a participação do pessoal de operação em Design de Serviços e Transição de Serviço .......................................................................................................................... 58 3,5 Saúde Operacional................................................................................................. 59 3,6 Comunicação.......................................................................................................... 61 3.6.1 Reuniões.................................................................................................................62 3.6.1.1 A reunião de Operações ............................................................................................. 63 3.6.1.2 Departamento reuniões de grupo ou equipe................................................................ 64 3.6.1.3 reuniões com clientes ................................................................................................. 64 3,7 Documentação........................................................................................................ 66 4 Operação processos de serviço .....................................................................67 4.1 Gestão de Eventos ................................................................................................. 69 4.1.1 Finalidade objetivo / / objetivo.................................................................................69 4.1.2 Âmbito ....................................................................................................................69 4.1.3 Valor para os negócios...........................................................................................70 4.1.4 Políticas / princípios / conceitos básicos.................................................................71 4.1.5 as atividades de processo, métodos e técnicas......................................................73 4.1.5.1 Evento ocorre ............................................................................................................. 74 4.1.5.2 Notificação de eventos................................................................................................ 74 4.1.5.3 Detecção de eventos .................................................................................................. 75 4.1.5.4 Evento filtragem.......................................................................................................... 75 4.1.5.5 Significado de eventos................................................................................................ 75 4.1.5.6 correlação de eventos................................................................................................. 77 4.1.5.7 Gatilho........................................................................................................................ 77 4.1.5.8 Resposta seleção ....................................................................................................... 78 4.1.5.9 Rever as acções ......................................................................................................... 81 4.1.5.10 evento Close............................................................................................................. 81 4.1.6 Triggers interfaces de entrada e saída / inter-processo..........................................82 4.1.7 Gestão da Informação ............................................................................................83 4.1.8 Métricas..................................................................................................................84 4.1.9 Desafios, Fatores Críticos de Sucesso e riscos......................................................85 4.1.9.1 Desafios ..................................................................................................................... 85 4.1.9.2 Fatores Críticos de Sucesso ....................................................................................... 85 4.1.9.3 Riscos......................................................................................................................... 86 4.1.10 Projeto de Gestão de Eventos..............................................................................86 4.1.10.1 Instrumentação ......................................................................................................... 86 4.1.10.2 mensagens de erro ................................................................................................... 87 4.1.10.3 de detecção de eventos e mecanismos de alerta....................................................... 87 4.1.10.4 Identificação de limiares............................................................................................ 88 4.2 Gestão de Incidentes.............................................................................................. 89 4.2.1 Finalidade objetivo / / objetivo.................................................................................89 4.2.2 Âmbito ....................................................................................................................89 4.2.3 Valor para os negócios...........................................................................................90 4.2.4 Políticas / princípios / conceitos básicos.................................................................90 4.2.4.1 Prazos ........................................................................................................................ 90 4.2.4.2 Modelos de Incidentes ................................................................................................ 90 4.2.4.3 grandes incidentes...................................................................................................... 91 4.2.5 As atividades de processo, métodos e técnicas.....................................................92 4.2.5.1 identificação de incidentes .......................................................................................... 93 4.2.5.2 registro de incidentes.................................................................................................. 94 ITIL V3 - Operação de Serviço - Página: 4 de 423
    • 4.2.5.3 categorização de incidentes........................................................................................ 95 4.2.5.4 priorização de Incidentes ............................................................................................ 97 4.2.5.5 O diagnóstico inicial .................................................................................................... 99 4.2.5.6 escalada de incidentes................................................................................................ 99 Nota sobre alocação de Incidentes ..........................................................................................................100 4.2.5.7 Investigação e Diagnóstico........................................................................................ 100 4.2.5.8 Resolução e Recuperação ........................................................................................ 101 4.2.5.9 Fechamento de Incidentes ........................................................................................ 102 Regras para reabertura incidentes ................................................................................103 4.2.6 Triggers interfaces de entrada e saída / inter-processo........................................103 4.2.7 Gestão da Informação ..........................................................................................104 4.2.8 Métricas................................................................................................................105 4.2.9 Desafios, Fatores Críticos de Sucesso e riscos....................................................106 4.2.9.1 Desafios ................................................................................................................... 106 4.2.9.2 Fatores Críticos de Sucesso ..................................................................................... 107 4.2.9.3 Riscos....................................................................................................................... 107 4,3 Cumprimento de Requisição ................................................................................ 108 Finalidade 4.3.1 meta / / objetivo...................................................................................108 4.3.2 Âmbito ..................................................................................................................108 4.3.3 Valor para os negócios.........................................................................................109 4.3.4 Políticas / princípios / conceitos básicos...............................................................109 4.3.4.1 Modelos Pedido........................................................................................................ 109 4.3.5 as atividades de processo, métodos e técnicas....................................................110 4.3.5.1 seleção do menu....................................................................................................... 110 4.3.5.2 aprovação Financeiro................................................................................................ 110 4.3.5.3 aprovação Outros ..................................................................................................... 110 4.3.5.4 Cumprimento ............................................................................................................ 111 4.3.5.5 Encerramento ........................................................................................................... 111 4.3.6 Triggers interfaces de entrada e saída / inter-processo........................................111 4.3.7 Gestão da Informação ..........................................................................................112 4.3.8 Métricas................................................................................................................112 4.3.9 Desafios, Fatores Críticos de Sucesso e riscos....................................................112 4.3.9.1 Desafios ................................................................................................................... 112 4.3.9.2 Fatores Críticos de Sucesso ..................................................................................... 113 4.3.9.3 Riscos....................................................................................................................... 113 4,4 Gerenciamento de Problemas.............................................................................. 115 4.4.1 Finalidade objetivo / / objetivo...............................................................................115 4.4.2 Âmbito ..................................................................................................................115 4.4.3 Valor para os negócios.........................................................................................115 4.4.4 Políticas / princípios / conceitos básicos...............................................................116 4.4.4.1 Modelos de problemas.............................................................................................. 116 4.4.5 as atividades de processo, métodos e técnicas....................................................116 4.4.5.1 detecção de problemas............................................................................................. 117 4.4.5.2 registro Problema...................................................................................................... 118 4.4.5.3 Categorização Problema........................................................................................... 119 4.4.5.4 Priorização de Problemas ......................................................................................... 119 4.4.5.5 Investigação e Diagnóstico de Problemas ................................................................. 119 4.4.5.6 Soluções Alternativas................................................................................................ 123 4.4.5.7 Levantando um registro de Erro Conhecido............................................................... 124 4.4.5.8 A resolução de problemas......................................................................................... 124 4.4.5.9 Encerramento Problema ........................................................................................... 125 4.4.5.10 Revisão grande problema ....................................................................................... 125 4.4.5.11 Os erros detectados no ambiente de desenvolvimento............................................ 126 4.4.6 Triggers interfaces de entrada e saída / inter-processo........................................126 4.4.7 Gestão da Informação ..........................................................................................128 4.4.7.1 CMS ......................................................................................................................... 128 4.4.7.2 Banco de Dados Erro Conhecido .............................................................................. 128 4.4.8 Métricas................................................................................................................130 4.4.9 Desafios, Fatores Críticos de Sucesso e riscos....................................................131 ITIL V3 - Operação de Serviço - Página: 5 de 423
    • 4,5 Gerenciamento de Acesso ................................................................................... 132 4.5.1 Finalidade objetivo / / objetivo...............................................................................132 4.5.2 Âmbito ..................................................................................................................132 4.5.3 Valor para os negócios.........................................................................................132 4.5.4 Políticas / princípios / conceitos básicos...............................................................133 4.5.5 as atividades de processo, métodos e técnicas....................................................133 4.5.5.1 Solicitação de acesso ............................................................................................... 133 4.5.5.2 Verificação................................................................................................................ 134 4.5.5.3 Prever direitos........................................................................................................... 134 4.5.5.4 status de identidade de Monitoramento..................................................................... 136 4.5.5.5 acesso acompanhamento e rastreamento................................................................. 136 4.5.5.6 Remoção ou restritiva de direitos .............................................................................. 137 4.5.6 Triggers interfaces de entrada e saída / inter-processo........................................138 4.5.7 Gestão da Informação ..........................................................................................139 4.5.7.1 Identidade................................................................................................................. 139 4.5.7.2 Os usuários, grupos, funções e grupos de serviço..................................................... 140 4.5.8 Métricas................................................................................................................141 4.5.9 Desafios, Fatores Críticos de Sucesso e riscos....................................................141 4,6 As atividades operacionais de processos cobertos de fases do ciclo de vida de outros .......................................................................................................................... 143 4.6.1 Gestão da Mudança .............................................................................................143 4.6.2 Gerenciamento da Configuração..........................................................................143 4.6.3 Gerenciamento de Liberação e Implantação ........................................................144 4.6.4 Gerenciamento da Capacidade ............................................................................144 4.6.4.1 Capacidade e Performance Monitoring...................................................................... 145 4.6.4.2 capacidade ou manipulação desempenho incidentes relacionados............................ 146 4.6.4.3 Capacidade e tendências de desempenho................................................................ 147 4.6.4.4 Armazenamento de dados de gerenciamento de capacidade .................................... 147 4.6.4.5 Gerenciamento da Demanda .................................................................................... 148 4.6.4.6 Workload Management ............................................................................................. 148 4.6.4.7 Modelação e aplicações de dimensionamento........................................................... 149 4.6.4.8 Planejamento de Capacidade ................................................................................... 149 4.6.5 Gerenciamento de Disponibilidade.......................................................................150 4.6.6 Gestão do Conhecimento .....................................................................................151 4.6.7 Gerenciamento Financeiro para Serviços de TI....................................................152 4.6.8 Gestão da Continuidade de Serviço de TI............................................................152 5 atividades operação comum Serviço ............................................................ 154 5,1 Monitoramento e controle..................................................................................... 157 5.1.1 Definições.............................................................................................................157 5.1.2 Controle Loops monitor ........................................................................................158 5.1.2.1 malha de controle Complexo do Monitor.................................................................... 160 5.1.2.2 O ITSM Monitor de Controle de Loop ........................................................................ 162 5.1.2.3 definir o que precisa ser monitorado.......................................................................... 165 5.1.2.4 Monitoramento Interno e Externo e Controle ............................................................. 165 5.1.2.5 Definir objectivos para monitoramento e controle ...................................................... 166 5.1.2.6 Tipos de monitoramento............................................................................................ 168 5.1.2.7 Monitoramento em ambientes de teste...................................................................... 171 5.1.2.8 Relatórios e ação...................................................................................................... 171 5.1.2.9 auditorias Operação de Serviço ................................................................................ 172 5.1.2.10 Medição, métricas e KPIs........................................................................................ 172 Medição.....................................................................................................................................................173 Métrica ......................................................................................................................................................173 Indicadores Chave de Desempenho ........................................................................................................173 5.1.2.11 Interfaces para práticas de outros serviços do Ciclo de Vida.................................... 174 Monitoramento Operacional e Melhoria de Serviço Continuada....................................174 5,2 Operações de TI ................................................................................................... 176 5.2.1 Management Console / Ponte de Operações.......................................................176 ITIL V3 - Operação de Serviço - Página: 6 de 423
    • 5.2.2 Job Scheduling .....................................................................................................177 5.2.3 Backup e Restauração .........................................................................................178 5.2.3.1 backup...................................................................................................................... 179 5.2.3.2 Restaurar.................................................................................................................. 181 5.2.4 impressão e de saída ...........................................................................................181 5.3 Gestão Mainframe ................................................................................................ 183 5,4 Management Server e suporte............................................................................. 184 5,5 Gerenciamento de Rede ...................................................................................... 186 5,6 Armazenamento e Arquivo................................................................................... 188 5,7 Database Administration ...................................................................................... 190 5,8 Diretório de Gestão de Serviços .......................................................................... 192 5,9 Desktop Support................................................................................................... 193 5,10 Middleware Gestão............................................................................................. 194 5,11 Gestor da Internet / Web .................................................................................... 196 5,12 Instalações e Data Management Centre............................................................ 197 5.12.1 Dados estratégias Centro...................................................................................198 5,13 Gestão de Segurança da Informação e Operação de Serviço.......................... 200 5.13.1 Policiamento e relatórios.....................................................................................200 5.13.2 Assistência técnica .............................................................................................201 5.13.3 controle de segurança operacional.....................................................................201 5.13.4 Seleção e habilitação..........................................................................................201 5.13.5 Treinamento e conscientização ..........................................................................202 5.13.6 políticas e procedimentos documentados...........................................................202 5,14 Melhoria das actividades operacionais .............................................................. 203 5.14.1 automação de tarefas manuais...........................................................................203 5.14.2 Rever atividades improvisadas ou procedimentos..............................................203 5.14.3 Auditorias Operacionais......................................................................................203 5.14.4 Usando o Gerenciamento de Incidentes e de Problemas...................................203 5.14.5 Comunicação......................................................................................................203 5.14.6 A educação ea formação....................................................................................204 6 Organizador para Operação de Serviço ....................................................... 205 6.1 Funções ................................................................................................................ 205 6.1.1 Funções e atividades............................................................................................207 6,2 Service Desk......................................................................................................... 210 6.2.1 Justificação e do papel do Service Desk ..............................................................210 6.2.2 Posto de objectivos de serviço .............................................................................211 6.2.3 estrutura organizacional Service Desk .................................................................212 6.2.3.1 Posto de Serviço Local.............................................................................................. 212 6.2.3.2 Service Desk centralizado......................................................................................... 213 6.2.3.3 Service Desk Virtual.................................................................................................. 214 6.2.3.4 Siga o Sol ................................................................................................................. 215 6.2.3.5 grupos Posto de serviço especializado...................................................................... 216 6.2.3.6 Ambiente .................................................................................................................. 216 6.2.3.7 Nota sobre a construção de um único ponto de contato............................................. 217 6.2.4 pessoal Service Desk ...........................................................................................217 6.2.4.1 Os níveis de pessoal................................................................................................. 217 6.2.4.2 Os níveis de especialização...................................................................................... 219 6.2.4.3 Formação ................................................................................................................. 221 6.2.4.4 retenção de pessoal.................................................................................................. 222 6.2.4.5 Superusuários........................................................................................................... 223 6.2.5 Posto de métricas de serviço................................................................................224 6.2.5.1 cliente / usuário pesquisas de satisfação................................................................... 226 6.2.6 A terceirização do Service Desk...........................................................................228 6.2.6.1 As ferramentas comuns e processos......................................................................... 229 6.2.6.2 metas de SLA ........................................................................................................... 230 6.2.6.3 A boa comunicação................................................................................................... 230 ITIL V3 - Operação de Serviço - Página: 7 de 423
    • 6.2.6.4 Propriedade dos dados ............................................................................................. 231 6.3 Gestão Técnica..................................................................................................... 232 6.3.1 papel de Gestão Técnica......................................................................................232 6.3.2 Técnicas objectivos de gestão..............................................................................233 6.3.3 genéricos técnicos actividades de gestão ............................................................233 6.3.4 organização Gestão Técnica................................................................................236 6.3.5 Manutenção Design e Técnico de Apoio Técnico e..............................................237 6.3.6 Técnicas de Gestão de métricas ..........................................................................237 6.3.7 documentação Gestão Técnica ............................................................................239 6.3.7.1 A documentação técnica........................................................................................... 239 6.3.7.2 programações de manutenção.................................................................................. 239 6.3.7.3 Inventário de Habilidades.......................................................................................... 239 6,4 TI Gestão de Operações ...................................................................................... 241 6.4.1 Funções de Gerenciamento de Operações de TI.................................................241 6.4.2 Operações de TI objectivos de gestão .................................................................243 6.4.3 Operações de TI Gestão de organização.............................................................243 6.4.4 Operações de TI métricas de gestão....................................................................244 6.4.5 Operações de TI Gestão de documentação .........................................................245 6.4.5.1 Procedimentos Operacionais Padrão ........................................................................ 245 6.4.5.2 Operações Logs........................................................................................................ 245 6.4.5.3 Shift Schedules e Relatórios ..................................................................................... 246 6.4.5.4 Horário de Operações............................................................................................... 247 6,5 Gerenciamento de Aplicativos.............................................................................. 247 6.5.1 papel Gerenciamento de Aplicativos ....................................................................247 6.5.2 Aplicação objectivos de gestão.............................................................................248 6.5.3 Gestão de princípios de aplicação........................................................................249 6.5.3.1 Construir ou comprar? .............................................................................................. 249 6.5.3.2 Modelos Operacionais .............................................................................................. 250 6.5.4 Aplicação de Gestão do Ciclo de Vida..................................................................250 6.5.4.1 Requisitos................................................................................................................. 252 6.5.4.2 Desenho................................................................................................................... 253 6.5.4.3 Construção ............................................................................................................... 254 6.5.4.4 Implantar .................................................................................................................. 254 6.5.4.5 Operar ...................................................................................................................... 255 6.5.4.6 Otimizar.................................................................................................................... 255 6.5.5 Aplicação de Gestão de actividades de carácter genérico ...................................256 6.5.6 Aplicação de Gestão de organização ...................................................................259 6.5.6.1 papéis organizacionais.............................................................................................. 261 6.5.7 Aplicação funções de gerenciamento e responsabilidades ..................................263 6.5.7.1 Aplicações Gerentes / ou chefes de equipa............................................................... 263 6.5.7.2 Aplicações Analista / Arquiteto .................................................................................. 264 6.5.8 Gestão de métricas de aplicação..........................................................................265 6.5.9 documentação Gerenciamento de Aplicativos......................................................266 6.5.9.1 Application Portfolio .................................................................................................. 266 6.5.9.2 Requisitos da Aplicação............................................................................................ 267 6.5.9.3 mudanças de uso e Casos........................................................................................ 268 6.5.9.4 documentação de projeto.......................................................................................... 269 6.5.9.5 Manuais.................................................................................................................... 270 6,6 Serviço de Operação papéis e responsabilidades............................................... 271 6.6.1 Posto de Serviço papéis.......................................................................................271 6.6.1.1 Service Desk Manager.............................................................................................. 271 6.6.1.2 Supervisor de Service Desk ...................................................................................... 271 6.6.1.3 Posto de Serviço Analistas........................................................................................ 272 6.6.1.4 Superusuários........................................................................................................... 272 6.6.2 Técnicas funções de gerenciamento ....................................................................272 6.6.2.1 Os gerentes técnicos / ou chefes de equipa .............................................................. 272 6.6.2.2 Os analistas técnicos / Arquitetos.............................................................................. 273 6.6.2.3 Operador Técnico ..................................................................................................... 274 6.6.3 Operações de TI funções de gerenciamento........................................................274 ITIL V3 - Operação de Serviço - Página: 8 de 423
    • 6.6.3.1 TI Gerente de Operações.......................................................................................... 274 6.6.3.2 Líderes Turno ........................................................................................................... 275 6.6.3.3 Operações de TI Analistas ........................................................................................ 275 6.6.3.4 Operadores de TI...................................................................................................... 275 6.6.4 Gestão funções de aplicativo................................................................................276 6.6.4.1 Aplicações Gerentes / ou chefes de equipa............................................................... 276 6.6.4.2 Aplicações Analista / Arquiteto .................................................................................. 276 6.6.5 Gestão de papéis de Eventos...............................................................................277 6.6.5.1 O papel do Service Desk........................................................................................... 277 6.6.5.2 O papel do Técnico e Gerenciamento de Aplicativos................................................. 278 6.6.5.3 O papel da TI Gestão de Operações......................................................................... 278 6.6.6 Gestão de Incidentes papéis ................................................................................278 6.6.6.1 Gerente de Incidentes............................................................................................... 278 6.6.6.2 Primeira linha............................................................................................................ 279 6.6.6.3 de segunda linha....................................................................................................... 279 6.6.6.4 Terceira linha............................................................................................................ 279 6.6.7 A realização de papéis Pedido .............................................................................280 6.6.8 Problema funções de gerenciamento ...................................................................280 6.6.8.1 Gestor Problema....................................................................................................... 280 6.6.8.2 resolução de problemas Grupos................................................................................ 281 6.6.9 Acesso funções de gerenciamento.......................................................................281 6.6.9.1 O papel do Service Desk........................................................................................... 282 6.6.9.2 O papel do Técnico e Gerenciamento de Aplicativos................................................. 282 6.6.9.3 O papel da TI Gestão de Operações......................................................................... 283 6,7 Serviço Organização Estruturas de Operação .................................................... 284 6.7.1 Organização pela especialização técnica.............................................................284 6.7.2 Organização pela atividade ..................................................................................286 6.7.3 Organização para gerenciar processos................................................................288 6.7.4 Organização de Operações de TI por geografia...................................................289 6.7.5 híbridos estruturas de organização.......................................................................292 6.7.5.1 Funções combinadas................................................................................................ 293 6.7.5.2 Aplicação de Organização e Gestão Técnica ............................................................ 295 6.7.5.3 Geografia.................................................................................................................. 295 6.7.5.4 Técnica Combinada e estrutura de Gerenciamento de Aplicativos............................. 296 7 considerações de tecnologia ........................................................................ 298 7,1 requisitos genéricos.............................................................................................. 299 7.1.1 Auto-Ajuda............................................................................................................299 7.1.2 Fluxo de Trabalho ou processo motor ..................................................................299 7.1.3 Integrado CMS......................................................................................................299 7.1.4 Descoberta de Implantação / / licenciamento de tecnologia.................................299 7.1.5 O controle remoto.................................................................................................300 7.1.6 utilitários de diagnóstico .......................................................................................300 7.1.7 Relatórios..............................................................................................................300 7.1.8 Dashboards ..........................................................................................................301 7.1.9 Integração com o Business Service Management................................................301 7.2 Gestão de Eventos ............................................................................................... 302 7,3 Gerenciamento de Incidentes............................................................................... 303 7.3.1 Integrado ITSM tecnologia....................................................................................303 7.3.2 Fluxo de Trabalho e escalonamento automatizado ..............................................303 7,4 cumprimento Pedido............................................................................................. 304 7,5 Gerenciamento de Problemas.............................................................................. 305 7.5.1 Integrated Service Management Technology .......................................................305 7.5.2 Gestão da Mudança .............................................................................................305 7.5.3 Integrado CMS......................................................................................................305 7.5.4 Banco de Dados Erro Conhecido .........................................................................305 7,6 Gerenciamento de Acesso ................................................................................... 307 7,7 Service Desk......................................................................................................... 308 ITIL V3 - Operação de Serviço - Página: 9 de 423
    • 7.7.1 Telefonia...............................................................................................................308 7.7.2 Ferramentas de suporte .......................................................................................308 7.7.2.1 Banco de Dados Erro Conhecido .............................................................................. 309 7.7.2.2 os scripts de diagnóstico........................................................................................... 309 7.7.2.3 interface web de Auto-Ajuda ..................................................................................... 309 7.7.2.4 O controle remoto ..................................................................................................... 310 7.7.3 Planejamento da Continuidade dos Serviços de TI para ferramentas de suporte ITSM..............................................................................................................................311 8 considerações sobre a aplicação.................................................................. 312 8,1 mudança de gestão, em Operação de Serviço.................................................... 313 8.1.1 Mudança desencadeia..........................................................................................313 8.1.2 Avaliação de Mudança .........................................................................................313 8.1.3 Medição de mudança bem sucedida ....................................................................314 8.2 Operação de Serviços e Gerenciamento de Projetos ......................................... 315 8,3 Avaliação de risco e gestão na Operação de Serviço......................................... 316 8,4 pessoal operacional em Design de Serviços e Transição................................... 317 8,5 Planejamento e implementação de tecnologias de gerenciamento de serviços 318 8.5.1 As licenças............................................................................................................318 8.5.1.1 licenças dedicados.................................................................................................... 318 8.5.1.2 licenças partilhadas................................................................................................... 318 8.5.1.3 licenças Web ............................................................................................................ 318 8.5.1.4 Serviço sob demanda ............................................................................................... 319 8.5.2 Implantação ..........................................................................................................320 8.5.3 verifica a capacidade............................................................................................320 8.5.4 O tempo de implantação de tecnologia ................................................................320 8.5.5 Tipo de introdução................................................................................................321 9 Desafios, Fatores Críticos de Sucesso e riscos............................................ 323 9,1 Desafios ................................................................................................................ 323 9.1.1 A falta de compromisso com a equipe de desenvolvimento e projeto ..................323 9.1.2 financiamento Justificando....................................................................................324 9.1.3 Desafios para os Gestores operação de serviço ..................................................324 9,2 Fatores Críticos de Sucesso ................................................................................ 327 9.2.1 Gestão de apoio ...................................................................................................327 9.2.2 O apoio às empresas............................................................................................328 9.2.3 Campeões ............................................................................................................328 9.2.4 Recrutamento e retenção .....................................................................................329 9.2.5 formação em Gestão de Serviços.........................................................................329 9.2.6 Ferramentas adequadas.......................................................................................330 9.2.7 Validade dos testes ..............................................................................................330 9.2.8 Medição e comunicação.......................................................................................331 9,3 Riscos ................................................................................................................... 332 9.3.1 Serviço de perda...................................................................................................332 9.3.2 Os riscos para a operação de serviço de sucesso ...............................................332 Posfácio........................................................................................................... 334 Apêndice A: orientações da indústria Complementar ...................................... 335 A1 COBIT.................................................................................................................... 336 A2 ISO / IEC 20000 .................................................................................................... 338 A3 CMMI ..................................................................................................................... 339 Balanced Scorecard A4.............................................................................................. 339 A5 de Gestão da Qualidade ....................................................................................... 340 A6 ITIL eo Quadro OSI............................................................................................... 340 Apêndice B: Comunicação na Operação de Serviço ....................................... 342 Comunicação B1 rotina operacional .......................................................................... 342 Comunicação B2 entre os turnos ............................................................................... 345 ITIL V3 - Operação de Serviço - Página: 10 de 423
    • B3 Relato de Desempenho......................................................................................... 346 IT Performance Serviço.................................................................................................346 Equipe do Serviço de Operação ou desempenho departamento ..................................348 Infra-estrutura ou o desempenho do processo..............................................................350 B4 Comunicação em projetos .................................................................................... 352 A comunicação relacionada com alterações B5........................................................ 354 B6 comunicação relacionada com exceções............................................................. 356 Comunicação B7 relação às emergências................................................................. 358 B8 A comunicação com os usuários e clientes.......................................................... 360 Anexo C: Kepner Tregoe e .............................................................................. 362 C1 Definindo o problema...............................................................................................363 C2 Descrevendo o problema .........................................................................................363 C3 Estabelecer as possíveis causas .............................................................................363 C4 Testando a causa mais provável..............................................................................364 C5 Verificando a verdadeira causa................................................................................364 Anexo D: Diagramas de Ishikawa.................................................................... 365 Apêndice E: Descrição detalhada de Gestão de Instalações........................... 367 E1 Gestão de Edifícios ............................................................................................... 368 E2 Equipamentos de Hospedagem............................................................................ 369 Gerenciamento de energia E3.................................................................................... 370 E4 condicionamento ambiental e sistemas de alerta................................................. 372 E5 Segurança ............................................................................................................. 374 E6 Controle de Acesso Físico .................................................................................... 374 E7 envio e recebimento.............................................................................................. 374 E8 Envolvimento em Gestão de Contratos................................................................ 375 Manutenção E9........................................................................................................... 376 Anexo F: Controle de Acesso Físico................................................................ 377 Glossário ......................................................................................................... 382 Lista de siglas ............................................................................................................. 382 Lista de definições ...................................................................................................... 386 ITIL V3 - Operação de Serviço - Página: 11 de 423
    • Prefácio Prefácio da OGC Desde a sua criação, ITIL cresceu e se tornou a abordagem mais aceita para o gerenciamento de serviços no mundo. No entanto, juntamente com este sucesso vem a responsabilidade de assegurar que a orientação mantém o ritmo com um ambiente de negócios em constante mudança global. Requisitos de gerenciamento de serviços são inevitavelmente moldado pelo desenvolvimento de tecnologia, modelos de negócios revistos e as expectativas dos clientes cada vez maior. A nossa mais recente versão do ITIL foi criado em resposta a estes desenvolvimentos. Esta é uma das cinco publicações principais que descrevem as práticas de gerenciamento de serviços de TI que compõem a ITIL. Eles são o resultado de um projeto de dois anos para revisar e atualizar a orientação. O número de profissionais de gerenciamento de serviços de todo o mundo que ajudaram a desenvolver o conteúdo dessas publicações é impressionante. Sua experiência e conhecimentos que contribuíram para o conteúdo para trazer-lhe um conjunto consistente de alta qualidade orientação. Isto é apoiado pelo desenvolvimento contínuo de um sistema de qualificação abrangente, juntamente com formação acreditada e consultoria. Se você faz parte de uma empresa global, um departamento ou uma pequena empresa, ITIL dá acesso a conhecimento de classe mundial de gestão de serviços. Essencialmente, ele coloca os serviços de TI onde eles pertencem - no centro de operações de negócios de sucesso. Peter Fanning Atuando Executivo Office of Government Commerce ITIL V3 - Operação de Serviço - Página: 12 de 423
    • Prefácio Arquiteto Chefe ITIL Service orientação Prática de Gestão está estruturado em torno do Ciclo de Vida do Serviço. Comum em todo o ciclo de vida é a prática geral em si, que se baseia em processos, funções, atividades, modelos organizacionais e de medição, que, juntos, permitem IT Service Management (ITSM) para integrar com os processos de negócio, fornecer valor mensurável e evoluir a indústria de ITSM em frente na nossa busca da excelência no atendimento. Em nenhum outro lugar do ITIL Service Lifecycle faz o efeito de como atuar como prestadores de serviços tocar os clientes intimamente como operações de serviços. Este é o lugar onde a estratégia, design, transição e melhorias são entregues e apoiada em uma base dia-a-dia. A publicação traz Operação de Serviço Gerenciamento de Serviços de vida para o negócio, e a prestação de contas para a execução dos serviços, as pessoas que os criam e da tecnologia que permite que eles são monitorados, controlados e entregue nesta fase do Ciclo de Vida do Serviço. Esta publicação vai ajudar a orientar-nos a todos para alcançar a excelência do serviço e ver o valor de ITSM em uma ampla visão de negócios com foco dela. Se você é novo para a prática de ITIL ou um profissional experiente, a orientação nesta publicação irá expandir sua visão e conhecimento de como ser o provedor de serviços de best-of-breed, através da implementação de Operação de Serviço. Há um ditado que diz que a aprendizagem é 20/20. A orientação na Operação de Serviço é destilado de mais de 20 anos de experiência em ITSM por especialistas mundiais, empresários e profissionais de ITSM e as lições aprendidas por eles sobre o serviço de excelência realmente é e como alcançá- lo. Qualquer pessoa envolvida em serviços de operação irá beneficiar da orientação nas páginas seguintes desta publicação. Operação de Serviço oferece o melhor aconselhamento e orientação de todo o mundo e um caminho para o que é possível em seu futuro. Sharon Taylor Arquiteto Chefe, Práticas ITIL Service Management ITIL V3 - Operação de Serviço - Página: 13 de 423
    • Prefaciar Esta publicação abrange e supera os aspectos operacionais do ITIL Service Support e Service Delivery publicações e também cobre a maior parte do escopo de Gestão TIC infra-estrutura. Ele também incorpora aspectos operacionais do planejamento para implementar, gerenciamento de aplicações, gerenciamento de ativos de software e publicações de Gestão de Segurança. Os princípios básicos de boas práticas de serviços de TI de gestão enquadrada no âmbito de versões anteriores do ITIL permanecem inalteradas. O senso comum permanece o bom senso! No entanto, as tecnologias, ferramentas e relações mudaram significativamente, mesmo em período de tempo relativamente curto desde a última versão do ITIL foi concluída. Embora esta publicação re-usos e atualizações material relevante das versões anteriores se for caso disso, também inclui muitos novos conceitos e práticas da indústria para dar cobertura completa de melhores práticas de orientação para a Operação de hoje serviço em um único volume, para os negócios de hoje e ambiente tecnológico . Informações de contato Todos os detalhes sobre a gama de material publicado sob a bandeira ITIL podem ser encontradas em www.best-management-practice.com/itil Se você gostaria de nos informar de quaisquer alterações que possam ser necessárias para esta publicação por favor, registrá-los em www.best- management-practice.com/changelog Para mais informações sobre qualificação e acreditação da formação, visite www.itil-officialsite.com. Alternativamente, favor contatar: APMG Service Desk Espada Casa Totteridge Estrada High Wycombe Buckinghamshire HP13 6DG Tel: +44 (0) 1494 452450 E-mail: servicedesk@apmgroup.co.uk ITIL V3 - Operação de Serviço - Página: 14 de 423
    • Agradecimentos Arquiteto-chefe e autores Sharon Taylor (Aspect Group Inc) Arquiteto Chefe David Cannon (HP) Autor David Wheeldon (HP) Autor ITIL autoria da equipe O ITIL equipe de criação contribuiu para este guia através de comentários sobre o conteúdo e alinhamento em todo o conjunto. Então, graças também são devidos a outros autores do ITIL, especificamente Jeroen Bronkhorst (HP), Gary Case (Pink Elephant), Ashley Hanna (HP), Majid Iqbal (Carnegie Mellon University), Shirley Lacy (ConnectSphere), Vernon Lloyd (Fox IT ), Ivor Macfarlane (Guillemot Rock), Michael Nieves (Accenture), Stuart Rance (HP), Colin Rudd (itens) e George Spalding (Pink Elephant). Mentores Christian Nissen e Paul Wilkinson Outras contribuições Um número de pessoas contribuíram generosamente seu tempo e conhecimento para esta publicação operação de serviço. Jim Clinch, como OGC Gerente de Projeto, agradece o apoio prestado pela HP para a equipe de criação no desenvolvimento desta publicação e, particularmente, a contribuição de Peter Doherty e Stroud Robert, e para o apoio de Jenny Dugmore, Convenor do Grupo de Trabalho ISO / IEC 20000, Janine Eves, Carol Hulm, Aidan Lawes e Michiel van der Voort. Os autores também gostariam de agradecer a Stuart Rance e Ashley Hanna, da Hewlett- Packard, Christian F Nissen (Itilligence), Maria Jarra (Itilligence), Eu Jin Ho (UBS), Jan Bjerregaard, (Sun Microsystems), Jan Oberg (Oberg Parceiros ), Lars Zobbe Mortensen (Zobbe Consult & Zoftware), Mette Nielsen (Carlsberg TI), Michael Imhoff (IBM), Niels Berner (Novo Nordisk), Nina Schertiger (HP), Signe-Marie Hernes Bjerke (DNV), Steen Sverker Nilsson (Westergaard CSM), Ulf Myrberg (Bita), Russell Jukes, Debbi Jancaitis, Sheldon Parmer, Ramon Alanis, Tim Benson e Nenen Ong da Hewlett-Packard TI, Jaye Thompson, Dee Seymour, Andranik Ziyalyan, Young Chang, Lauren Abernethy, abril McCowan, Becky Wershbale, Rob Garman, Scott McPherson, Sandra de panificação, Rick Streeter, Leon Gantt, Charlotte Devine, Greg Algorri, Maria Fischer, Bill Thayer e Diana Osberg da Empresa The Walt Disney Company de TI, Dennis Deane e João Sowerby da DHL, Richard Fahey e Chris Hughes de Serviços de Entrega Global da HP Aplicação, Cindi Locker e Dhiraj Gupta da Companhia Progressive Casualty Insurance, Peter Doherty e Robert Stroud, da Computer Associates e Tillston Paulo da Hewlett-Packard, Brian Jakubec, Vernon Blakes, Angela Chin, Colin Lovell , Ken Hamilton, Rose ITIL V3 - Operação de Serviço - Página: 15 de 423
    • Lariviere, Jenny McPhee, Tom Nielsen, Roc Paez, Lloyd Robinson, Paul Wilmot, Jeanette e Ken Smith Wendle da Hewlett-Packard. A fim de desenvolver práticas de gestão ITIL Service para refletir as melhores práticas actuais e produzir publicações de valor duradouro, OGC amplas consultas com as diferentes partes interessadas em todo o mundo em todas as fases do processo. OGC também gostaria de agradecer às seguintes pessoas e suas organizações, por suas contribuições à orientação refrescante ITIL a: O ITIL Grupo Consultivo Pippa Bass, OGC; Tony Betts, Independente; Signe-Marie Hernes Bjerke, Det Norske Veritas; Alison Cartlidge, Xansa; Diane Colbeck, DIYmonde Solutions Inc; Ivor Evans, DIYmonde Solutions Inc; Karen Ferris, ProActive; Malcolm Fry, Fry-Consultores , João Gibert, Independente; Colin Hamilton, RENARD Consulting Ltd; Lex Hendriks, EXIN; Carol Hulm, British Computer Society-ISEB; Tony Jenkins, DOMAINetc; Phil Montanaro, EDS; Alan Nance, ITpreneurs; Christian Nissen, Itilligence; Página Don, Marval Grupo; Bill Powell, IBM; Sergio Rubinato Filho, CA; James Siminoski, SOScorp; Robert E. Stroud, CA; Jan van Bon, informe-IT; Ken Wendle, HP, Paul Wilkinson, Getronics PinkRoccade; Takashi Yagi, Hitachi. Revisores Jorge Acevedo, Computec SA; Balaji Alapilla; Valerie Arraj, INTEQ; Colin Ashcroft, Cidade de Londres, William Bagley, Amgreetings; Martijn Bakker, Getronics PinkRoccade; Jeff Bartrop, BT & Atendimento ao Cliente direto; Rajesh Basava Amatyappa Bellary, Satyam, John Bennett , Centram Ltd; Ian Bevan, Fox IT, Enrico Boverino, CA; Bart Van Brabant, Post; Ronald Browning, CA; Stephen Bull, Serra de Sistemas; Bradley Busch, InTotality; Howard Carpenter, IBM; Liang Cheng, IBM, John Clark, HP; Nicole Conboy, Nicole Conboy & Associates; Sharon Dale, Aquip Internacional; Sandra Daly, Dawling Consultoria; Tony Domínio, Blue Yonder, Michael Donahue, IBM; Ken Doughty, André J. Emmell, DKMStech; Matthew Evans, Processo Worx, Juan Antonio Fernandez, Quint Wellington Redrood; Karen Ferris, proativa Serviços; Juan José Figueiras, Globant; Liz Gallacher; Rae Garrett, Pink Elephant, Klaus Goedel, HP; David Gooda, Genesys Consultoria; Detlef Gross, Automação Consulting Group GmbH; Matthias Hall, Universidade de Dundee, John Hannan, melhores práticas de TI; Jonas Hansen, MMIT; Oliver Hast, Scoops; Jabe Hickey, IBM; Graham Hill, Metisc; Kevin Hite, Microsoft; Sergio Hrabinski, Xelere; Scott Jaegar, Plexant; Chris Jay; Chunyang Jia, Microsoft; Masthan Kadhar Kadhar, Cognizant, Tony Kelman- Smith, HP; Peter Koepp, Independente; Joanne Kopcho, a Capgemini América; Rene van Kuijen; Debbie Langenfield, IBM; Horacio Laprea; Sarah Lascelles, Interserve Projeto Services Ltd, Peter Loos , Accenture Services GmbH, Marcos Lopez, da Microsoft; Emmanuel Marchand, Advens; James Marmion, Yell Group, Jesus Martin, Ibermatica SA; Luis Moran, Independente; Steve Morgan, KPMG; Ron Morton, HP; Philip Mougis, TCS; Richard Mulholland, IBM; Ron Muns, IDH; Darren Murtagh, Retravision; Krisna Nugraha, Cleon Consultoria; Shuichi Owa, Niandc; Sampo Pasanen, Efecte; Rodrigo Pementa, Pink Elephant, Eddy Peters, CTG; Steve Phelan, Lua Macaco; Carol Piccus, CA; Poul Mols Poulsen, Coop Norden TI; Roger Purdie, A Arte de Serviço; Glen Ralph, iCore Ltd; Padmini Ramamurthy, Satyam Computer Services Ltd; Keith Reynolds, NSS Consultoria; Manfred Rieder, HP; Stephanie Roddy, Camelot Group; Mieke Roelens, CTA; Frances Scarff, OGC; Markus Schiemer, a Unisys; Barbara Schiesser, Swiss TIC; Klaus Seidel, Microsoft; Migel Sergey; Mamak Shafai; Prakash Sharma; Gilbert Silva, Techbiz Informatica Ltd; Jim Siminoski, Soscorp; Dierk Soellner, Mod-gruppe , José Estêvão, do Departamento de Transportes, Governo dos EUA; Michala Sterling, Mid Sussex Conselho Distrital; Helen Sussex, Logic ACMG; Rohan Thuraisingham, Friends Provident Management Services Ltd, Mateus Tolman, Sandvik, Cheryl Tovizi, MWH Global; Frank Victor, Victor GmbH ; Corde Wagner; Christoph Wettstein, CLAVIS KLW AG; Andi Wijaya, IBM; Aaron Wolfe, Pink Elephant, Mike Yang, IBM; Younghoon Youn, IBM. ITIL V3 - Operação de Serviço - Página: 16 de 423
    • 1 Introdução Esta publicação fornece as melhores práticas de aconselhamento e orientação sobre todos os aspectos da gestão do dia-a-dia operação de uma organização de tecnologia da informação (TI). Abrange questões relacionadas com as pessoas, processoes de tecnologia, infra-estrutura e relaçãos necessária para garantir a elevada qualidade, o fornecimento eficaz de Serviços de TI necessário para atender às necessidades de negócio. O advento de novas tecnologias e as linhas ténues entre agora os silos de tecnologia tradicionais de hardware, redes, telefonia e software aplicaçãos gestão significa que uma abordagem atualizada para a gestão operação de serviços é necessária. Organizaçãos estão cada vez mais propensos a considerar formas de prestação de TI na sua melhor custar e flexibilidade, com a introdução de utilidade TI, pay-per-use serviços de TI, fornecimento de TI virtuais, dinâmicas capacidade e Adaptive Enterprise Computing, bem como em tarefas de abastecimento e terceirização opções. Estas alternativas têm levado a uma miríade de relações de negócios de TI, tanto interna como externamente, que aumentaram em complexidade, tanto quanto as tecnologias que estão sendo gerenciados têm. Negócio dependência sobre essas relações complexas é cada vez mais crítico para a sobrevivência e prosperidade. ITIL V3 - Operação de Serviço - Página: 17 de 423
    • 1.1 Visão Geral Operação de Serviço é a fase em ITSM Ciclo de Vida que é responsável por "business-as-usual" atividades. Operação de Serviço pode ser visto como a "fábrica" de TI. Isto implica um maior foco nas atividades do dia-a-dia e infra-estrutura que são utilizados para prestar serviços. No entanto, esta publicação é baseada no entendimento de que o objetivo primordial da Operação de Serviço é para entregar e suportar serviços. Gestão da infra-estrutura ea operacional atividades devem sempre apoiar esta finalidade. Processos bem planejados e implementados será em vão se a operação do dia- a-dia desses processos não é bem conduzido, controlado e gerenciado. Nem será serviço melhorias será possível se dia-a-dia para monitorizar atuação, Avaliar métricos dados e recolher não são sistematicamente realizadas durante a Operação de Serviço. Operação equipe de serviço deve dispor de processos e ferramentas de apoio que lhes permitam ter uma visão global da operação de serviço e de entrega (e não apenas a parte componentes, como o hardware, aplicações de software e redes, que compõem o fim-de-final serviço a partir de um perspectiva de negócios) E para detectar quaisquer ameaças ou falhas de serviço qualidade. Dado que os serviços podem ser fornecidos, no todo ou em parte, por um ou mais parceiros /fornecedor organizaçãos, o Operação de Serviço ver de fim-de- final serviço deve ser ampliada para abranger os aspectos externos de prestação de serviços - e onde compartilhada necessária ou interface processoes e são necessárias ferramentas para gerenciar fluxos de trabalho inter-organizacionais. Operação de Serviço não é nem uma unidade organizacional nem um único processo - mas inclui vários funçãos e muitos processos e actividades, que estão descritos nos Capítulos 4, 5 e 6 ITIL V3 - Operação de Serviço - Página: 18 de 423
    • 1,2 Contexto 1.2.1 Gestão de Serviços TI é um termo comumente utilizado que muda de significado com o contexto. A partir da perspectiva de primeira, TI sistemas, aplicaçãos e infra-estrutura são componentes ou subconjuntos de um produto maior. Eles permitem ou são incorporados em processos e serviços. A partir da segunda perspectiva, é uma organização com seu próprio conjunto de capacidades e recursos. Organizações de TI podem ser de vários tipos, tais como funções de negócios, unidades de serviços partilhados e unidades de nível empresarial do núcleo. A partir da terceira perspectiva, é uma categoria dos serviços utilizados pelas empresas. Eles são tipicamente aplicações de TI e infra-estrutura que são empacotados e oferecidos como serviços por organizações de TI interna ou externa provedor de serviçoss. TI custars são tratados como despesas comerciais. A partir da quarta perspectiva, é uma categoria de negócio ativoss que fornecem um fluxo de benefícios para seus proprietários, incluindo, mas não limitado a, lucros, receitas e lucro. Os custos de TI são tratados como investimentos. 1.2.2 Boas práticas no domínio público Organizações operar em ambientes dinâmicos com a necessidade de aprender e se adaptar. Existe uma necessidade de melhorar atuação enquanto gestora trade-offs. Sob pressão semelhante, clientes procuram vantagem de prestadores de serviços. Eles perseguem estratégias de sourcing que melhor servem o seu interesse próprio negócio. Em muitos países, as agências governamentais e organizações sem fins lucrativos empresas têm uma propensão similar ao terceirizar para o bem da operacional eficácia. Isso coloca uma pressão adicional sobre os prestadores de serviços para manter uma vantagem competitiva em relação às alternativas que os clientes possam ter. O aumento em terceirização se particularmente expostas prestador de serviços internos à concorrência incomum. Para lidar com a pressão, organizações referência se contra colegas e procurar para fechar lacunas em capacidades. Uma forma de fechar essas lacunas é a adoção de boas práticas em toda a indústria. Existem várias fontes de boas práticas, incluindo estruturas públicas, padrãos e do conhecimento de propriedade de organizações e indivíduos (ver Figura 1.1). ITIL V3 - Operação de Serviço - Página: 19 de 423
    • Figura 1.1 Fonte de Prática Gestão de Serviços Estruturas públicas e as normas são atraentes quando comparados com conhecimento de propriedade: • Conhecimento proprietário, está profundamente enraizado nas organizações e, portanto, difícil de adotar, replicar ou transferir, mesmo com a cooperação dos proprietários. Tal conhecimento é muitas vezes na forma de conhecimento tácito que é indissolúvel e mal documentadas. • Conhecimento proprietário é personalizado para o contexto local e as necessidades específicas do negócio, a ponto de ser idiossincrático. A não ser que os destinatários de tais conhecimentos têm correspondência circunstâncias, o conhecimento não pode ser tão eficaz em uso. • Proprietários de conhecimento proprietário esperam ser recompensados por seus investimentos de longo prazo. Eles podem fazer tal conhecimento disponível apenas em termos comerciais, por meio de compras e licenciamento acordos. • Publicamente disponíveis quadros e padrãos, tais como ITIL, Objetivos de Controle para TI (COBIT), CMMI, eSCM-SP, PRINCE2,ISO 9000, ISO 20000 e ISO 27001 são validados através de um conjunto diversificado de ambientes e situações, em vez de limitada experiência de um único organização. Eles estão sujeitos a ampla rever através de várias organizações e disciplinas. Eles são controlados por diversos conjuntos de parceiros, fornecedors e concorrentes. • O conhecimento das estruturas públicas é mais provável a ser amplamente distribuído entre uma grande comunidade de profissionais por meio de treinamento disponíveis publicamente e certificado. É mais fácil para as organizações a adquirir tais conhecimentos por meio do mercado de trabalho. ITIL V3 - Operação de Serviço - Página: 20 de 423
    • Ignorando estruturas públicas e padrões podem desnecessariamente colocar uma organização em desvantagem. As organizações devem cultivar seu próprio conhecimento proprietária em cima de um corpo de conhecimento baseado em quadros públicos e padrões. Colaboração e coordenação entre as organizações são mais fáceis com base compartilhada práticas e padrões. 1.2.3 ITIL e boas práticas em Gestão de Serviços O contexto desta publicação é o ITIL Quadro como uma fonte de boas práticas Serviço de Gestão de. ITIL é usado por organizações em todo o mundo para estabelecer e melhorar as capacidades de gerenciamento de serviços. ISO / IEC 20000 fornece um padrão formal e universal para organizações que buscam ter seus recursos de gerenciamento de serviço auditado e certificado. Enquanto a norma ISO / IEC 20000 é um padrão a ser alcançado e mantido, ITIL oferece um corpo de conhecimento útil para alcançar o padrão. A Biblioteca ITIL tem o seguinte componentes: • ITIL Core: melhores práticas de orientação aplicável a todos os tipos de organizações que prestam serviços a uma empresa de • ITIL Orientação complementar: um conjunto complementar de publicações com orientações específicas para os setores da indústria, tipos de organização, modelos operacionais e tecnologia arquiteturas. O Core ITIL é composto por cinco publicações (ver Figura 1.2). Cada uma delas fornece a orientação necessária para uma abordagem integrada, conforme exigido pela norma ISO / IEC 20000 padrão especificação: • Estratégia de Serviço • Design de Serviços • Transição de Serviço • Operação de Serviço • Melhoria de Serviço Continuada. ITIL V3 - Operação de Serviço - Página: 21 de 423
    • Figura 1.2 ITIL Núcleo Cada publicação aborda as capacidades que têm impacto direto sobre um serviço de provedor atuação. A estrutura do núcleo é na forma de um ciclo de vida. Ele é interativo e multidimensional. Ele garante que organizaçãos são criados para alavancar as capacidades em uma área de aprendizagem e melhorias em outras. O Núcleo é esperado para dar estabilidade, estrutura e força para Serviço de Gestão de capacidades, com duráveis princípios, métodos e ferramentas. Isso serve para proteger os investimentos e proporcionar a base necessária para a aprendizagem, medição e melhoria. A orientação em ITIL pode ser adaptado para as mudanças de uso em vários negócios ambientes e estratégias organizacionais. Orientação Complementar fornece flexibilidade para implementar o núcleo em uma variada gama de ambientes. Os médicos podem seleccionar Orientação Complementar conforme necessário, para proporcionar tracção para o núcleo num contexto comercial determinada, tanto quanto os pneus são seleccionados com base no tipo de finalidade do automóvel, e as condições da estrada. Isto é para aumentar a durabilidade e a portabilidade de conhecimento ativoss e proteger os investimentos em capacidades de gerenciamento de serviços. ITIL V3 - Operação de Serviço - Página: 22 de 423
    • 1.2.3.1 Estratégia de Serviço O Estratégia de Serviço volume fornece orientação sobre como projeto, Desenvolver e implementar o Gerenciamento de Serviço, não apenas como uma organização capacidade mas também como um estratégico ativos. São fornecidas orientações sobre os princípios subjacentes à prática de Gestão de Serviços, que são úteis para o desenvolvimento de políticas de gerenciamento de serviços, diretrizs e processoes entre o ITIL Serviço Ciclo de Vida. Orientação Estratégia serviço é útil no contexto de Design de Serviços,Transição de Serviço,Operação de Serviço e Melhoria de Serviço Continuada. Os tópicos abordados na Estratégia de Serviço incluem o desenvolvimento dos mercados, interno e externo, serviço ativos, catálogo de serviços e implementação de estratégia através do Ciclo de Vida do Serviço. Gestão Financeira,Gestão de Portfólio de Serviços, Desenvolvimento Organizacional e Estratégico Riscos estão entre outros grandes temas. Organizações usam a orientação para definir objetivos e expectativas de desempenho para servir clientes e espaços de mercado e para identificar, selecionar e priorizar oportunidades. Estratégia de Serviço se de garantir que as organizações estão em uma posição para lidar com a custars e os riscos associados ao seu portfólio de serviçoss e são criados não só para operacional eficácia mas para o desempenho diferenciado. As decisões feitas em relação à Estratégia de Serviço tem conseqüências de longo alcance, incluindo aqueles com efeito retardado. Organizações que já praticam ITIL usar este volume para orientar uma estratégica rever de suas capacidades baseadas em ITIL Service Management e melhorar o alinhamento entre esses recursos e suas estratégias de negócios. 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. Respostas para o primeiro tipo de questões estão mais próximas de negócio do cliente. Estratégia de Serviço expande o escopo do Quadro de ITIL além do público tradicional de profissionais de ITSM. 1.2.3.2 Design de Serviços O volume de Design de Serviços fornece orientação para a concepção e desenvolvimento de serviços e processos de gerenciamento de serviços. Ele abrange os princípios de design e métodos para converter objetivos estratégicos em portfólios de serviços e bens de serviço. O âmbito do Design de Serviços não se limita a novos serviços. Ele inclui as mudanças e melhorias necessárias para aumentar ou manter valor para os clientes durante o ciclo de vida dos serviços, a continuidade dos serviços, a realização de nível de serviços e conformidade com padrãos e regulamentos. Ele orienta as organizações sobre como desenvolver capacidades de design para Gerenciamento de Serviços. ITIL V3 - Operação de Serviço - Página: 23 de 423
    • 1.2.3.3 Transição de Serviço O Transição de Serviço volume fornece orientação para o desenvolvimento e melhoria de capacidades para a transição de serviços novos e modificados em operaçãos. Esta publicação fornece orientação sobre como o exigências de Estratégia de Serviço codificados em Design de Serviços são efetivamente realizados em Operações de Serviço ao controlar a riscos de fracasso e ruptura. A publicação combina práticas em Gerenciamento de Liberação,Programa Gestão e Gestão de Risco e coloca-os no contexto da prática de Serviço de Gestão de. Ele fornece orientações sobre o gerenciamento da complexidade relacionada a alterações nos serviços e gestão de serviços processoes, evitando consequências indesejáveis, permitindo a inovação. Orientação é fornecida sobre a transferência do controlar de serviços entre clientes e provedor de serviçoss. 1.2.3.4 Operação de Serviço Este volume incorpora práticas na gestão de Operação de Serviços. Inclui orientação sobre a realização eficácia e eficiência na entrega e suporte de serviços, de modo a garantir um valor para o cliente e o provedor de serviços. Estratégico objetivos são, em última análise realizada através de operações de serviços, portanto, tornando-se uma crítica capacidade. São fornecidas orientações sobre como manter a estabilidade em operações de serviços, o que permite mudanças de escala, design, escopo e níveis de serviço. Organizações são fornecidos com processo detalhado diretrizs, métodos e ferramentas para uso em dois grandes controle de perspectivas: reativa e pró-ativa. Gestores e profissionais são fornecidos com o conhecimento que lhes permite tomar melhores decisões em áreas como a gestão do disponibilidade de serviços, a demanda controle, otimização capacidade agendamento de utilização, das operações de fixação e problemas. São fornecidas orientações sobre operações de apoio através de novos modelos e arquiteturas, tais como serviços compartilhados, utilidade computação, serviços web e comércio móvel. 1.2.3.5 Melhoria de Serviço Continuada Este volume oferece orientação instrumental na criação e manutenção de valor para os clientes através de uma melhor projeto, Implantação e operação de serviços. Ele combina os princípios, práticas e métodos de Qualidade Gestão, Gestão da Mudança e Melhoria de Capacidade. Organizações aprender a perceber melhorias incrementais e de larga escala em serviço qualidade, operacional eficiência e continuidade dos negócios. Orientação é fornecida para ligar os esforços de melhoria e resultados com Service Design de Serviços, Estratégia e Transição de Serviço. A realimentação de circuito fechado sistema, Com base no Plan-Do-Check-Act (PDCA) modelo especificado no ISO / IEC 20000, É estabelecido e capaz de receber entradas para mudar a partir de qualquer planejamento perspectiva. ITIL V3 - Operação de Serviço - Página: 24 de 423
    • A gestão do dia-a-dia operacional da Serviços de TIs é significativamente influenciado pela maneira como um organização'S estratégia geral de TI serviço foi definido e quão bem os processos de ITSM foram planejadas e implementadas. Esta é a quarta publicação no Gerenciamento de Serviços ITIL série Práticas e as outras publicações sobre Estratégia de Serviço, Desenho de Serviço e Transição de Serviço deve ser consultado para melhores práticas orientação sobre esses importantes etapas anteriores à operação do serviço. Operação de Serviço é extremamente importante, pois é no dia-a-dia operacional que eventos ocorrer o que pode adversamente impacto qualidade do serviço. A forma como uma organização Infra-estrutura de TI e seus processos de apoio ITSM são operados terá mais direta e imediata influência de curto prazo sobre serviço qualidade. ITIL V3 - Operação de Serviço - Página: 25 de 423
    • 1,3 Propósito Operação de Serviço é uma fase crítica do ITSM ciclo de vida. Bem planejado e processos bem implementados será em vão se a operação do dia-a-dia desses processos não é bem conduzido, controlado e gerenciado. Nem vai atender melhorias será possível se dia-a-dia para monitorar atuação, Avaliar métricos dados e recolher não são sistematicamente realizadas durante a Operação de Serviço. Operação equipe de serviço deve dispor de processos e ferramentas de apoio que lhes permitam ter uma visão global da operação de serviço e de entrega (e não apenas a parte componentes, tais como hardware, software aplicaçãos e redes, que compõem o fim-de-final serviço a partir de uma perspectiva de negócios) e para detectar qualquer ameaças ou falhas de serviço qualidade. Dado que os serviços podem ser fornecidos, no todo ou em parte, por um ou mais parceiros /fornecedor organizações, o Operação de Serviço vista de ponta a ponta-de serviço deve ser estendido para abranger os aspectos externos de prestação de serviços - e onde compartilhada necessária ou interface processoes e são necessárias ferramentas para gerenciar fluxos de trabalho inter-organizacionais. 1,4 Uso Esta publicação deve ser usada em conjunto com as outras quatro publicações que compõem o Serviço ITIL Ciclo de Vida. Os leitores devem estar cientes de que a melhor prática diretrizs em volumes este e outros não são destinados a ser prescritiva. Cada organização é único e deve "adaptar e adotar" a orientação para suas próprias necessidades específicas, ambiente e cultura. Isso envolverá tendo em conta a dimensão da organização, competências /recursos, cultura, financiamento, prioridades e ITSM existentes maturidade e modificando a orientação adequada para atender às necessidades da organização. Para as organizações encontrando ITIL, pela primeira vez, a forma inicial de alguns avaliação comparar os processos atuais da organização e práticas com as recomendadas pelo ITIL seria um ponto de partida muito valioso. Estas avaliações são descritos em mais pormenor no ITIL Melhoria de Serviço Continuada publicação. Onde existem lacunas significativas, pode ser necessário para resolvê-los em etapas ao longo de um período de tempo para atender às prioridades de negócio da organização e manter o ritmo com o que a organização é capaz de absorver e pagar ITIL V3 - Operação de Serviço - Página: 26 de 423
    • 1,5 Visão geral do capítulo Capítulo 2 introduz o conceito de Serviço de Gestão de como uma prática. Aqui, Gerenciamento de Serviços está posicionada como uma estratégica e profissional componente de qualquer organização. Este capítulo também fornece uma visão geral da operação de serviço como um componente crítico da Prática de Gestão de Serviços. Os princípios fundamentais da operação de serviço são abordados no Capítulo 3 desta publicação. Estes princípios delinear alguns dos conceitos e princípios básicos em que o restante da publicação se baseia. Capítulo 4 abrange os processos realizados dentro de Operação de Serviço - a maioria dos processos de operação de serviço são reativos devido à natureza do trabalho a ser realizado para manter Serviços de TIs numa condição estável robusto. Este capítulo também abrange processos proactivos de enfatizar que o objetivo da Operação de Serviço é a estabilidade - mas não de estagnação. Operação de Serviço deve ser constantemente procurando maneiras de fazer as coisas melhor e de forma mais econômica, e os processos de dinamização têm um papel importante a desempenhar aqui. Capítulo 5 abrange uma série de atividades de serviços comuns de operação, que são grupos de atividades e procedimentos realizadas por Funções operação de serviço. Estes especializados, e muitas vezes técnicas, atividades não são processos no verdadeiro sentido da palavra, mas todos eles são vitais para a capacidade de oferecer qualidade de serviços de TI no ideal custar. Capítulo 6 cobre os aspectos organizacionais da Operação de Serviço - os indivíduos ou grupos que realizam processos de serviço de operação ou atividades - e inclui algumas orientações sobre estruturas de organização de serviços de Operação. Capítulo 7 descreve as ferramentas e tecnologia que são usados durante a Operação de Serviço. Capítulo 8 aborda alguns aspectos da implementação que precisam ser considerados antes da operacional fase do ciclo de vida torna-se ativa. Capítulo 9 destaca os desafios, Fatores Críticos de Sucesso e riscos enfrentou durante Operação de Serviço, Enquanto o Posfácio resume e conclui a publicação. ITIL não está sozinha na prestação de orientação para os gestores de TI e os apêndices delinear algumas das estruturas complementares fundamentais, metodologias e abordagens que são comumente usados em conjunto com ITIL durante Operação de Serviço ITIL V3 - Operação de Serviço - Página: 27 de 423
    • 2 Gerenciamento de Serviço como uma prática 2.1 O que é Gerenciamento de Serviços? Serviço de Gestão de é um conjunto de capacidades especializadas organizacionais para o valor de clientes, sob a forma de serviços. As capacidades de assumir a forma de funçãos e processoes para gerenciamento de serviços ao longo de um ciclo de vida, Com especializações em estratégia,projeto, Transição, operação e melhoria contínua. Os recursos representam um serviço organização'S capacidade, Competência e confiança para a ação. O ato de transformar recursos em serviços de valor está no centro de Gerenciamento de Serviço. Sem esses recursos, uma organização de serviço é meramente um conjunto de recursos que por si só tem relativamente baixo valor intrínseco para os clientes. Definição de Gerenciamento de Serviço Service Management é um conjunto de capacidades especializadas organizacionais para o valor aos clientes na forma de serviços. Capacidades organizacionais são moldadas pelos desafios que eles terão de superar. Um exemplo desta situação é como em 1950 Toyota desenvolvidas capacidades únicas de superar o desafio de menor escala e capital financeiro em relação aos seus rivais americanos. Toyota desenvolvidas novas capacidades em engenharia de produção, gestão de operações e gestão fornecedors para compensar sua incapacidade de pagar grandes estoques, fazer componentes, produzir matérias-primas ou possuir as empresas que os produzem. [Fonte: Magretta, Joan 2002. O que é gestão: Como funciona e por que negócio é de todos. O Free Press.] Capacidades de gerenciamento de serviços são igualmente influenciado pelos seguintes desafios que o distinguem de outros serviços sistemas de criação de valor, tais como mineração, manufatura e agricultura: • Natureza intangível dos produtos de saída e intermediário de processos de serviços: difícil de medir, controlar e validar (ou provar). • A demanda está intimamente ligado com o cliente ativoss: Usuários e ativos dos clientes, tais como processos, aplicaçãos, documentos e transaçãos chega com a demanda e estimular a produção de serviços. • Alto nível de contato para os produtores e consumidores de serviços: tampão Pouca ou nenhuma entre o cliente, o front-office e back-office. • A natureza perecível serviço saída e serviço capacidade: Não há valor para o cliente de garantia da continuidade do fornecimento de consistente qualidade. Provedores precisam garantir um suprimento constante de demanda dos clientes. ITIL V3 - Operação de Serviço - Página: 28 de 423
    • No entanto, Serviço de Gestão de é mais do que apenas um conjunto de capacidades. É também um profissional prática suportado por um extenso corpo de conhecimento, experiência e habilidades. Uma comunidade global de indivíduos e organizações dos setores público e privado promove seu crescimento e maturidade. Esquemas formais existem para a educação, formação e certificado de praticar organizações e indivíduos influenciar sua qualidade. Indústria melhores práticasA pesquisa, acadêmica e formal padrãos contribuir para o seu capital intelectual e tirar dele. As origens do Gerenciamento de Serviço estão em empresas de serviços tradicionais, tais como companhias aéreas, bancos, hotéis e empresas de telefonia. Sua prática tem crescido com a adoção pelas organizações de TI de uma abordagem orientada a serviços para gestão de TI aplicaçãoa infra- estrutura e processos. Soluções para os negócios problemas e suporte para negócios modelos, estratégias e operaçãos são cada vez mais sob a forma de serviços. A popularidade de serviços partilhados e terceirização contribuiu para o aumento do número de organizações que são provedor de serviçoss, incluindo unidades organizacionais internas. Este, por sua vez, reforçou a prática de Gestão de Serviços e, ao mesmo tempo imposta maiores desafios em cima dele. ITIL V3 - Operação de Serviço - Página: 29 de 423
    • 2.2 O que são serviços? 2.2.1 O valor proposição Definição de serviço Um serviço é um meio de entregar valor aos clientes, facilitando resultados clientes querem alcançar, sem a posse de determinado custars e riscos. Os serviços são um meio de entregar valor aos clientes, facilitando os resultados que os clientes querem alcançar, sem a posse de custos e riscos específicos. Serviços de facilitar os resultados através do aumento da atuação associado de tarefas e a redução do efeito de restrições. O resultado é um aumento na probabilidade de resultados desejados. Figura 2.1 Uma conversa sobre a definição e significado de serviços ITIL V3 - Operação de Serviço - Página: 30 de 423
    • 2.3 Funções e processos em todo o ciclo de vida 2.3.1 Funções Funçãos são unidades de organizações especializadas para executar certos tipos de trabalho e responsável pela específico resultados. Eles são auto- suficientes, com capacidades e recursos necessária para a sua atuação e os resultados. Os recursos incluem métodos de trabalho interno para as funções. Funções têm seu próprio corpo de conhecimentos, que se acumula com a experiência. Eles fornecem estrutura e estabilidade para as organizações. Funções são um meio de estruturar as organizações, de modo a implementar o princípio da especialização. Funções normalmente definem papels ea autoridade associado e responsabilidade para um desempenho específico e os resultados. Coordenação entre funções através compartilhada processoes é um padrão comum na organização projeto. Funções tendem a otimizar seus métodos de trabalho a nível local, para se concentrar nos resultados atribuídos. Fraca coordenação entre as funções, combinados com um foco para dentro, leva a silos funcionais que impedem o alinhamento e feedback crítico para o sucesso do organização como um todo. Processo modelos ajudar a evitar esse problema com hierarquias funcionais, melhorando a coordenação inter-funcional e controlar. Processos bem definidos pode melhorar a produtividade dentro e através de funções. 2.3.2 Processos Processos são exemplos de circuito fechado sistemas, pois fornecem mudar e de transformação para um objetivo e utilizar o feedback para a auto-reforço e auto-ação corretiva (ver Figura 2.2). É importante levar em consideração todo o processo, ou como um processo encaixa outra. Figura 2.2 Um processo básico ITIL V3 - Operação de Serviço - Página: 31 de 423
    • Definições de processos descrevem ações, dependências e seqüência. Processos de ter as seguintes características: • Mensuráveis: Nós somos capazes de medir o processo de uma maneira relevante. É o desempenho conduzido. Os gerentes querem medir custar,qualidade e outras variáveis, ao passo que os profissionais estão preocupados com a duração e a produtividade. • Resultados específicos: A razão de um processo existe é entregar um resultado específico. Este resultado deve ser individualmente identificáveis e contáveis. Enquanto podemos contar mudanças, é impossível contar quantas Service Desks foram concluídas. • Clientes: Todo processo de entrega de seus resultados primários para um cliente ou das partes interessadas. Elas podem ser internas ou externas à organização, mas o processo tem de satisfazer as suas expectativas. • Responde a um específico evento: Enquanto um processo pode ser contínuo ou iterativo, deve ser feita com um gatilho específico. As funções são muitas vezes confundidos com os processos. Por exemplo, existem conceitos errados sobre Gerenciamento da Capacidade ser um Serviço de Gestão de processo. Primeiro, Gerenciamento da Capacidade é uma organização capacidade com processos especializados e métodos de trabalho. Quer se trate de uma função ou de um processo depende inteiramente o projeto de organização. É um erro supor que Gerenciamento da Capacidade pode ser apenas um processo. É possível medir e controlar capacidade e para determinar se ele é adequado para um determinado fim. Assumindo que é sempre um processo, Com contável discreto resultados, pode ser um erro. 2.3.3 Especialização e coordenação em todo o ciclo de vida Especialização e coordenação são necessários no ciclo de vida abordagem. Feedback e controle entre o funçãos e processos dentro e entre os elementos do ciclo de vida de tornar isso possível. O padrão dominante do ciclo de vida é o progresso seqüencial a partir de SS através SO-SD-ST e volta a SS por meio de CSI. No entanto, esse não é o único padrão de acção. Cada elemento do ciclo de vida fornece pontos de feedback e controle. A combinação de múltiplas perspectivas permite uma maior flexibilidade e controle em ambientes e situações. A abordagem do ciclo de vida imita a realidade da maioria das organizações onde a gestão eficaz requer a utilização de múltiplas controle de perspectivas. Os responsáveis pela projeto,desenvolvimento e melhoria de processos para Serviço de Gestão de pode adotar uma perspectiva de controle baseada em processos. Os responsáveis pela gestão acordos, contratos e serviços pode ser melhor servido por uma perspectiva de controle do ciclo de vida baseado em fases distintas. Ambos controle benefício perspectivas de sistemas pensando. Cada perspectiva de controle pode revelar padrões que podem não ser evidentes a partir do outro. ITIL V3 - Operação de Serviço - Página: 32 de 423
    • 2.4 Operação fundamentos Serviço 2.4.1 Finalidade objetivo / / objetivo O objectivo da Operação de Serviço é coordenar e executar as atividades e processos necessários para fornecer e gerenciar serviços em níveis acordados para os negócios usuários e clientes. Operação de Serviço é também responsável pela gestão contínua da tecnologia que é usada para entregar e suportar serviços. Processos bem desenhados e bem implementado será de pouco valor se o dia- a-dia operação desses processos não é bem conduzido, controlado e gerenciado. Nem será serviço melhorias será possível se dia-a-dia para monitorizar atuação, Avaliar métricos dados e recolher não são sistematicamente realizadas durante a Operação de Serviço. 2.4.2 Âmbito Operação de Serviço inclui a execução de todas as actividades em curso exigidos para entregar e suportar serviços. O escopo de Operação de Serviço inclui: • Os próprios serviços. Qualquer atividade que faz parte de um serviço está incluído na Operação de Serviço, quer seja executado pela Prestadora de Serviço, um externo fornecedor ou o usuário ou cliente desse serviço • Gestão de processos de serviços. O gerenciamento e execução de processos de gerenciamento de serviço são muitos realizada em operação de serviço, apesar de uma série de processos de ITIL (como Mudança e Gerenciamento de Capacidade) originam-se no Design de Serviços ou Transição de Serviço fase do Serviço Ciclo de Vida, Eles estão em usar continuamente em operação do serviço. Alguns processos não são incluídos especificamente na operação de serviço, tais como Estratégia Definição, o projeto real do próprio processo. Esses processos se concentrar mais no longo prazo planejamento e atividades de melhoria, que estão fora do escopo direto de Operação de Serviço, no entanto, Operação de Serviço fornece entrada e influencia estes regularmente, como parte do ciclo de vida de Gerenciamento de Serviço. • Tecnologia. Todos os serviços requerem alguma forma de tecnologia para entregá-los. Gerenciando essa tecnologia não é uma questão separada, mas uma parte integrante da gestão dos próprios serviços. Portanto, uma grande parte desta publicação está preocupada com a gestão da infra-estrutura utilizada para prestar serviços. • Pessoas. Independentemente do que serviços, processoes e tecnologia são geridos, todos eles são sobre pessoas. São as pessoas que dirigem a demanda para o organização'S serviços e produtos e são as pessoas que ITIL V3 - Operação de Serviço - Página: 33 de 423
    • decidem como isso será feito. Em última análise, são as pessoas que gerenciam a tecnologia, processos e serviços. A falha em reconhecer isto irá resultar (e resultou) na falha de Serviço de Gestão de projetos 2.4.3 Valor para os negócios Cada estágio no Serviço ITIL Ciclo de Vida fornece valor ao negócio. Por exemplo, o valor do serviço é modelado em Estratégia de Serviço; O custar do serviço é projetado, previsto e validado em Design de Serviços e Transição de Serviço, E medidas para a otimização são identificados em Melhoria de Serviço Continuada. O operação de serviço é onde estes planos, projetos e otimizações são executados e medidos. A partir de um cliente ponto de vista, Operação de Serviço é onde o valor real é visto. Há um lado para baixo a este, no entanto: • Uma vez que o serviço foi projetado e testado, é esperado para executar dentro do orçamento e Retorno sobre Investimento metas estabelecidas no início do ciclo de vida. Na realidade, porém, muito poucas organizações planejar de forma eficaz para os custos de gestão contínua dos serviços. É muito fácil de quantificar os custos de um projeto, mas muito difícil de quantificar o que o serviço vai custar depois de três anos de funcionamento. • É difícil de obter, durante o financiamento operacional fase, para corrigir projeto falhas ou imprevistos exigências - uma vez que este não fazia parte da proposta de valor original. Em muitos casos, é apenas depois de algum tempo de operação que estes problemas superfície. A maioria das organizações não tem um mecanismo formal para rever serviços operacionais para o projeto e valor. Isto é deixado para a Incidentes e Gerenciamento de Problemas para resolver - como se ele é puramente uma questão operacional. • É difícil obter financiamento adicional para ferramentas ou ações (incluindo formação), que visa melhorar a eficiência de Operação de Serviço. Isto é em parte porque eles não estão diretamente ligadas ao funçãoalidade de um serviço específico e em parte porque há uma expectativa do cliente que estes custos deveriam ter sido construído no custo do serviço desde o início. Infelizmente, a taxa da tecnologia mudar é muito elevado. Pouco depois de uma solução foi implantada que vai gerir eficazmente um conjunto de serviços, a nova tecnologia se torna disponível, que pode fazê-lo mais rápido, mais barato e mais eficaz. • Uma vez que um serviço está em funcionamento há algum tempo, torna- se parte do linha de base do que a espera do negócio Serviços de TIs. As tentativas de otimizar o serviço ou utilizar novas ferramentas para gerenciá-lo de forma mais eficaz são vistos como bem-sucedido apenas se o serviço tem sido muito problemática no passado. Em outras palavras, alguns serviços são um dado adquirido e qualquer ação para ITIL V3 - Operação de Serviço - Página: 34 de 423
    • otimizá-los é percebido como "fixação de serviços que não estão quebrados". Esta publicação sugere uma série de processos, funções e medidas que visam abordar essas áreas. 2.4.4 Otimização do desempenho do Serviço de Operação Operação de Serviço é otimizard de duas maneiras: • Longo prazo a melhoria incremental. Isto baseia-se na avaliação da atuação e saída de todos os processos de operação de serviço, funçãos e saídas ao longo do tempo. Os relatórios são analisados e uma decisão sobre se a melhoria é necessária e, em caso afirmativo, qual a melhor forma de implementá-lo através de Design de Serviços e Transição. Os exemplos incluem o desenvolvimento de um novo conjunto de ferramentas, as alterações processo projetos, a reconfiguração da infra- estrutura, etc Este tipo de melhoria é abordado em detalhes na publicação Melhoria de Serviço Continuada. • Curto prazo, a melhoria contínua de trabalho práticas dentro dos processos de serviço de operação, funções e tecnologia em si. Estes são geralmente pequenas melhorias que são implementadas sem qualquer alteração para a natureza fundamental de um processo ou de tecnologia. Exemplos incluem afinação,carga de trabalho equilíbrio, reafectação de pessoal e formação, etc Embora ambos estes são discutidos em detalhe dentro do escopo de Operação de Serviço, o Melhoria de Serviço Continuada publicação proporcionará um quadro e alternativas em que a melhoria pode ser conduzido como parte do apoio global da objetivo de negócios. 2.4.5 Processos dentro de Operação de Serviço Há uma série de Operação de Serviço chave processoes que devem ligar em conjunto para proporcionar uma estrutura de suporte eficaz geral IT. A estrutura geral é brevemente descrito aqui e, em seguida, cada um dos processos é descrito em mais detalhe no Capítulo 4. 2.4.5.1 Gestão de Eventos Gestão de Eventos monitora todos eventos que ocorrem em todo o Infra- estrutura de TI, Para monitorizar normais operação e para detectar e aumentar as condições de exceção. 2.4.5.2 Incidentes e Gestão de Problemas ITIL V3 - Operação de Serviço - Página: 35 de 423
    • Gerenciamento de Incidentes concentra-se na restauração dos serviços inesperadamente degradados ou interrompidos para usuários o mais rapidamente possível, a fim de minimizar a actividade impacto. Gerenciamento de Problemas envolve: análise de causa raiz para determinar e resolver a causa da incidentes, atividades pró-ativas para detectar e prevenir futuros problemas / incidentes e um Erro Conhecido sub-processo para permitir o rápido diagnóstico e resolução se novos incidentes ocorrem. 2.4.5.3 Cumprimento de Requisição Cumprimento de Requisição é o processo de tratamento com Solicitação de Serviços - muitos deles realmente menor, de menorrisco, Mudanças - inicialmente através da Service Desk, Mas utilizando um processo semelhante ao que separado de Gerenciamento de Incidentes mas com Cumprimento Pedido separado registros / tabelas - se necessário ligados ao incidente ou Grave problema(S) que iniciou a necessidade para a solicitação. Para ser uma solicitação de serviço, é normal que alguns pré-requisitos a serem definidos e cumpridos (por exemplo, as necessidades de ser comprovada, repetível, pré- aprovado, proceduralized). A fim de resolver um ou mais incidentes, problemas ou erros conhecidos, alguma forma de mudar pode ser necessária. Menor, muitas vezes padrão, as alterações podem ser tratadas através de um processo de Cumprimento de Requisição, mas maiores, mudanças de maior risco ou pouco frequentes devem passar por um formal Gestão da Mudança processo. 2.4.5.4 Gerenciamento de Acesso Gerenciamento de Acesso é o processo de concessão de autorização usuárioo direito de usar um serviço, Limitando o acesso a usuários não-autorizados. Ele é baseado em ser capaz de identificar com precisão os usuários autorizados e gerenciar sua própria capacidade de acessar serviços como exigido durante as diferentes fases de seus Recursos Humanos (RH) ou contratual ciclo de vida. Gerenciamento de acesso também tem sido chamado de identidade ou Direitos Gestão em algumas organizações. 2.4.6 Funções dentro de Operação de Serviço Processos por si só não vai resultar em eficaz Operação de Serviço. Uma infra- estrutura estável e adequadamente pessoas qualificadas são necessários também. Para conseguir isso, Operação de Serviço depende de vários grupos de pessoas qualificadas, todos focados em uso de processos para coincidir com a capacidade da infra-estrutura às necessidades do negócio. ITIL V3 - Operação de Serviço - Página: 36 de 423
    • Estes grupos são classificados em quatro principais funçãos, aqui e discutido em detalhes no Capítulo 6. 2.4.6.1 Service Desk O Service Desk é o principal ponto de contato para os usuários quando há uma interrupção do serviço, por Solicitação de Serviços, ou até mesmo para algumas categorias de Requisição de Mudança. O Service Desk fornece um ponto de comunicação com os usuários e um ponto de coordenação para vários grupos de TI e processos 2.4.6.2 Gestão Técnica Gestão Técnica fornece detalhadas habilidades técnicas e recursos necessários para suportar o curso operação do Infraestrutura de TI. Gestão Técnica também desempenha um papel importante na projeto, Testes, liberar e melhoria das Serviços de TIs. Em pequenas empresas, é possível gerenciar essa experiência em um único departamento, mas as grandes organizações são normalmente dividida em vários departamentos especializados tecnicamente. 2.4.6.3 Gestão de Operações de TI TI Gestão de Operações executa a diária operacional atividades necessárias para gerenciar a infra-estrutura de TI. Isso é feito de acordo com o desempenho Padrãos definido durante Design de Serviços. Em algumas organizações este é um departamento único e centralizado, enquanto em outros algumas atividades e funcionários são centralizados e alguns são fornecidos por departamentos distribuídos ou especializada. Gestão de Operações de TI tem duas funções que são únicas e são geralmente formais estruturas organizacionais. Estes são os seguintes: • Operações de TI Controle, O qual é geralmente composta por deslocars de operadores e que assegura que as tarefas rotineiras operacionais são realizadas. Controle de Operações de TI também irá fornecer centralizado monitoramento e controlar actividades, geralmente usando uma Operações Ponte ou Centro de Operações de Rede. • Facilities Management refere-se à gestão da TI física ambiente, Geralmente centros de dados ou salas de informática. Em muitas organizações técnica e Aplicação de Gestão de são co-localizado com Operações de TI em grandes centros de dados. 2.4.6.4 Gerenciamento de Aplicativos Application Management é responsável pela gestão Aplicaçãos ao longo do seu ciclo de vida. A função de gerenciamento de aplicativos suporta e mantém aplicações operacionais e também desempenha um importante papel no projeto, ITIL V3 - Operação de Serviço - Página: 37 de 423
    • teste e melhoria de aplicações que fazem parte dos serviços de TI. Gerenciamento de Aplicativos é geralmente dividida em departamentos com base no portfólio de aplicativos do organização, Permitindo assim mais fácil de especialização e de mais apoio focado. 2.4.6.5 Interfaces para outros estágios Serviço Lifecycle Management Existem vários outros processos que serão executados ou apoiados durante Operação de Serviço, Mas que são conduzidas durante outras fases do Serviço de Gestão de Ciclo de Vida. Isto será discutido na parte final do capítulo 4 e incluem: • Gestão da Mudança, Que é um importante processo que deve estar intimamente ligado ao Gerenciamento da Configuração e Gerenciamento de Liberação. Esses tópicos são cobertos principalmente no Transição de Serviço publicação. • Capacidade e Gerenciamento de Disponibilidade, Que são abordados na publicação Service Design. • Gestão Financeira, Que é coberto no Estratégia de Serviço publicação. • Gestão do Conhecimento, que é coberto na publicação Transição de Serviço. • Serviços de TI Continuidade, que é coberto no Design de Serviços publicação. • Serviço de Relatórios e Mensuração, que são cobertos no Melhoria de Serviço Continuada publicação. ITIL V3 - Operação de Serviço - Página: 38 de 423
    • 3 Operação princípios do serviço Ao considerar Operação de Serviço é tentador focar apenas no gerenciamento do dia-a-dia e tecnologia como um fim em si mesmos. No entanto, Operação de Serviço existe dentro de um contexto muito maior. Como parte do Ciclo de Vida do Gerenciamento de Serviços, é responsável pela execução e realização de processos que otimizar o custar e qualidade de serviços. Como parte do organização, É responsável por permitir o negócio para cumprir o seu objetivos. Como parte do mundo da tecnologia, que é responsável pelo bom funcionamento do componentes que os serviços de apoio. Os princípios deste capítulo são destinadas a ajudar os praticantes operação de serviço para atingir um equilíbrio entre todos estes papels e se concentrar em gerir eficazmente os aspectos do dia-a-dia, mantendo uma perspectiva de um contexto maior. ITIL V3 - Operação de Serviço - Página: 39 de 423
    • 3,1 Funções, grupos, equipes, departamentos e divisões A publicação Operação de Serviço usa vários termos para referir-se a maneira pela qual as pessoas estão organizadas para executar processos ou atividades. Existem várias definições publicadas para cada termo e não é o propósito desta publicação para entrar no debate sobre qual é a melhor definição. Por favor, note que as definições a seguir são genéricas e não prescritivos. Eles são fornecidos apenas a definir os pressupostos e para facilitar a compreensão do material. O leitor deve adaptar esses princípios para a organização práticas usado em sua própria organização. • Função: Uma função é um conceito lógico que se refere ao povo e medidas automatizadas que executam um processo definido, uma atividade ou uma combinação de processos ou atividades. Em organizações maiores, uma função pode ser dividido e realizado por diversos departamentos, equipes e grupos, ou pode ser incorporado dentro de uma única unidade organizacional (por exemplo, Service Desk). Em organizações menores, uma pessoa ou grupo pode executar múltiplas funções - por exemplo, um Gestão Técnica departamento pode também incorporar a função de Service Desk. • Grupo: Um grupo é um número de pessoas que são, de algum modo semelhante. Nesta publicação, os grupos se referem a pessoas que desempenham atividades semelhantes - embora eles possam trabalhar em tecnologia diferente ou relatório em diferentes estruturas organizacionais ou mesmo em empresas diferentes. Os grupos são geralmente não formal organização estruturas, mas são muito úteis para a definição de processos comuns em toda a organização - eg garantir que todas as pessoas que resolver incidentes completar a Grave incidente da mesma maneira. Nesta publicação "grupo" o termo não se refere a um grupo de empresas que pertencem a uma mesma entidade. • Equipe: Uma equipe é um tipo mais formal do grupo. Estas são as pessoas que trabalham em conjunto para alcançar um comum objetivo, Mas não necessariamente na estrutura mesma organização. Os membros da equipe podem ser co-localizado, no trabalho ou em vários locais diferentes e operar virtualmente. Equipes são úteis para a colaboração, ou para lidar com uma situação de natureza temporária ou transitória. Exemplos de equipes incluem projeto equipes, aplicação desenvolvimento equipes (geralmente composto por pessoas de várias unidades de negócios diferentes) e de incidentes ou problema resolução equipes. • Departamento: Departamentos são estruturas de organização formal que existem para executar um conjunto específico de atividades definidas em uma base contínua. Departamentos têm uma estrutura de relatórios hierárquica com os gestores, que geralmente são responsáveis pela execução das atividades e também para o dia-a-dia de gestão do pessoal do departamento. ITIL V3 - Operação de Serviço - Página: 40 de 423
    • • Divisão: Uma divisão refere-se a uma série de serviços que foram agrupadas, muitas vezes por geografia ou linha de produtos. A divisão é normalmente auto-suficiente e é capaz de planejar e executar todas as atividades em um cadeia de suprimentos. • Papel: Um papel refere-se a um conjunto de comportamentos ligados ou ações que são realizadas por uma pessoa da equipe ou grupo em um contexto específico. Por exemplo, um Gestão Técnica departamento de TI pode desempenhar o papel de Gerenciamento de Problemas ao diagnosticar o causa raiz de incidentes. Este mesmo departamento também se podem esperar para jogar vários outros papéis em momentos diferentes, por exemplo, pode avaliar a impacto das alterações (Gestão da Mudança de papel), gerenciar a atuação de dispositivos sob seu controle (papel Gerenciamento da Capacidade), etc A escopo do seu papel e que desencadeia-los a desempenhar esse papel são definidos pelo relevante processo e acordado por seu gerente de linha. ITIL V3 - Operação de Serviço - Página: 41 de 423
    • Alcançar 3,2 equilíbrio na Operação de Serviço Operação de Serviço é mais do que apenas a execução repetitiva de um conjunto padrão de procedimentos ou atividades. Todos funçãos, processos e atividades são projetadas para fornecer um nível e acordado de serviços, mas que tem que ser entregue em uma constante mudança ambiente. Isso forma um conflito entre a manutenção do status quo e adaptação às mudanças do negócio e ambientes tecnológicos. Um dos papéis fundamentais serviço de operação é, portanto, para lidar com este conflito e para alcançar um equilíbrio entre conjuntos conflitantes de prioridades. Esta seção da publicação destaca algumas das principais tensões e conflitos e identifica como as organizações de TI podem reconhecer que eles estão sofrendo de um desequilíbrio, tendendo mais para um extremo ou outro. Ele também proporciona algum alto nível diretrizs sobre a forma de resolver o conflito e, assim, avançar para uma abordagem de melhores práticas. Cada conflito, portanto, representa uma oportunidade de crescimento e aperfeiçoamento. 3.2.1 TI interna ver contra vista de negócios externo O conflito mais fundamental em todas as fases do ITSM Ciclo de Vida é entre a visão de TI como um conjunto de serviços de TI (a visão empresarial externo) ea visão de TI como um conjunto de tecnologia componentes (TI interna ver). • A visão externa de TI é a forma como os serviços são experimentados por sua usuários e clientes. Eles nem sempre entendem, nem se preocupam com os detalhes do que a tecnologia é usada para gerenciar esses serviços. Todos eles estão preocupados é que os serviços sejam entregues conforme necessário e acordado. • A visão interna de TI é a maneira pela qual os componentes de TI e sistemas são geridas para realizar os serviços. Desde sistemas de TI são complexas e diversas, isso muitas vezes significa que a tecnologia é gerida por várias equipes ou departamentos diferentes - cada um dos quais está focado em alcançar um bom atuação e disponibilidade de sistemas de 'suas'. Ambas as visões são necessárias quando a prestação de serviços. O organização que se concentra apenas em negócios exigências sem pensar sobre como eles estão indo entregar vai acabar fazendo promessas que não possam ser mantidos. A organização que se concentra apenas em sistemas internos, sem pensar sobre quais os serviços que suportam vai acabar com serviços caros que oferecem pouco valor. ITIL V3 - Operação de Serviço - Página: 42 de 423
    • O potencial para a papel conflito entre as vistas externas e internas é o resultado de muitas variáveis, incluindo o maturidade da organização, a sua gestão cultura, Sua história, etc Isso faz com que um equilíbrio difícil de conseguir, ea maioria das organizações tendem mais para um papel que o outro. Naturalmente, nenhuma organização será totalmente internamente ou externamente focado, mas encontra-se numa posição ao longo de um espectro entre os dois. Isto é ilustrado na Figura 3.1: Figura 3.1 Atingir um equilíbrio entre o foco externo e interno A Tabela 3.1 resume alguns exemplos das características de posições extremas nas extremidades do espectro. O objetivo desta tabela é para ajudar as organizações a identificar para não que eles estão mais próximos extrema, para identificar vida real cargos para os quais as organizações devem aspirar. Foco interno extrema Foco externo extrema Foco principal Desempenho e gestão de Infraestrutura de TI dispositivos, sistemas e pessoal, com pouca consideração para o resultado final na De serviços de TI Atingir elevados níveis de desempenho de TI serviço com pouco respeito às como ele é alcançado Métricos • Foco no desempenho técnico, sem mostrar o que isso significa para os serviços de • Interna métricas (por exemplo, a disponibilidade da rede) informou ao negócio, em vez de serviço atuação métricas. • Focalizar Externa Metrics sem mostrar o pessoal interno como estes são derivados ou como eles podem ser melhorados • Pessoal interno são esperados para elaborar as suas próprias métricas para medir o desempenho interno. ITIL V3 - Operação de Serviço - Página: 43 de 423
    • Cliente/usuário experiência • Alta consistência da entrega, mas apenas oferece uma porcentagem do que a empresa precisa. • Usa um "empurrão" abordagem para a entrega, ou seja, prefere ter um conjunto padrão de serviços para todos unidade de negócioss. • Consistência pobres de entrega • "Ele consiste de boas pessoas com boas intenções, mas nem sempre pode executar ' • De modo reativo operação. • Usa um "pull" abordagem para a entrega, ou seja, prefere oferecer serviços personalizados a pedido Operações estratégia • Operações padrão em toda a linha • Todos os novos serviços precisam se encaixar no atual arquitetura e procedimentos. • Várias equipes de entrega e tecnologias múltiplas • As novas tecnologias exigem abordagens novas operações e, muitas vezes nova Operações de TI equipes. Procedimentos e manual Concentre-se puramente em como gerenciar a tecnologia, não sobre como o seu desempenho se refere aos serviços de TI Concentra-se principalmente sobre o que precisa ser feito e quando e menos em como isso deve ser alcançado Estratégia de custo • A redução de custos alcançada puramente por meio da consolidação de tecnologia • Otimização de operacional procedimentos e recursos • Negócio impacto de custar corte freqüentemente só entendeu depois • Retorno sobre o Investimento cálculos estão focados exclusivamente na redução de custos ou "períodos de retorno. • Orçamento alocados com base na qual a unidade de negócios é percebida a ter maior necessidade • Unidades de negócio menos articulados ou vocal muitas vezes têm serviços inferiores como não há financiamento suficiente alocado para os seus serviços. Treinamento O treinamento é realizado como um aprendizado, onde a equipe de Operações novo tem que aprender a forma como as coisas têm de ser feitas, por que não • O treinamento é realizado em um projetoA projecto base • Não há cursos de treinamento padrão desde operacional procedimentos e tecnologia estão mudando constantemente. Equipe de operações • Pessoal especializado, organizado de acordo com a especialidade técnica • Equipe de trabalho no falso • Equipe generalista, organizado em parte de acordo com a técnica capacidade e, em parte, de acordo com a relação ITIL V3 - Operação de Serviço - Página: 44 de 423
    • pressuposto de que a realização técnico bom é o mesmo que bom cliente serviço. com unidade de negócios • Dependência de 'heroísmo', onde os funcionários saem de sua maneira de resolver problemas que poderiam ter sido evitadas por uma melhor interna processoes. Tabela 3.1 Exemplos de foco interno e externo extrema Isto não quer dizer que a concentração externa não é importante. Todo o ponto de Serviço de Gestão de é fornecer serviços que satisfaçam as objetivos da organização como um todo. É crítico para os serviços de estrutura em torno clientes. Ao mesmo tempo, é possível para comprometer a qualidade de serviços por não pensar sobre como eles serão entregues. Edifício Operação de Serviço com um equilíbrio entre o foco interno e externo exige uma abordagem a longo prazo, dedicado refletida em todas as fases do Serviço de ITSM Ciclo de Vida. Isso vai exigir o seguinte: • Uma compreensão de que os serviços são utilizados pela empresa e por quê. • A compreensão da importância relativa e impacto desses serviços no negócio. • Um entendimento de como a tecnologia é utilizada para fornecer De serviços de TIs. • Envolvimento de Operação de Serviço em Melhoria de Serviço Continuada projetos que visam identificar formas de entregar mais, aumentar serviço qualidade e menor custar. • Procedimentos e manuais que delineiam o papel de Operações de TI em tanto a gestão da tecnologia e da entrega de serviços de TI. • Um conjunto claramente diferenciada de métricos de informar a empresa sobre a realização dos objectivos de serviço, e de informar os gestores de TI na eficiência e eficácia de Operação de Serviço. • Todos a equipe de TI Operações entender exatamente como o atuação da tecnologia afeta a entrega de serviços de TI e, por sua vez como estas afetam o negócio e os objetivos de negócio. • Um conjunto de serviços padrão entregue de forma consistente a todos Unidade de Negócioss e um conjunto de não-padrão (por vezes personalizada) serviços prestados a unidades de negócios específicas - junto com um conjunto de Procedimento Operacional Padrãos (POPs) que pode satisfazer os dois conjuntos de exigências. • Acustar estratégia que visa equilibrar as exigências de diferentes unidades de negócio, com a redução de custos através da otimização disponíveis da tecnologia existente ou o investimento em novas tecnologias - e um entendimento da estratégia de custo por todos os envolvidos TI recursos. ITIL V3 - Operação de Serviço - Página: 45 de 423
    • • Um valor-base, em vez de baseado em custo, Retorno sobre o Investimento estratégia. • Envolvimento de Operações de TI pessoal no Design de Serviços e Transição de Serviço fases do ITSM Ciclo de Vida. • Entrada de e feedback para Melhoria de Serviço Continuada para identificar áreas onde há um desequilíbrio e os meios para identificar e aplicar melhorias. • A comunicação clara e treinamento plano para o negócio. Embora muitas organizações são bons no desenvolvimento de planos de comunicação para projetos, isso muitas vezes não se estende em sua operacional fase. 3.2.2 Estabilidade em relação a capacidade de resposta Não importa o quão boa a funcionalidade é de um De serviços de TI e não importa o quão bem ele foi concebido, será que vale muito menos se o serviço componentes não estão disponíveis ou se realizar de forma inconsistente. Isto significa que, Operação de Serviço necessidades para assegurar que a Infraestrutura de TI é estável e disponível como projetado. Ao mesmo tempo, operação de serviço precisa reconhecer que os negócios ea TI exigências mudar. Algumas dessas mudanças são evolutivas. Por exemplo, a funcionalidade, atuação e arquitetura de uma plataforma podem mudar ao longo de vários anos. Cada mudança traz consigo uma oportunidade de proporcionar melhores níveis de serviço para o negócio. Em mudanças evolutivas, é possível planejar a forma de responder à mudança e, assim, manter a estabilidade, respondendo às mudanças. Muitas mudanças, porém, acontecer muito rapidamente e às vezes sob extrema pressão. Por exemplo, uma unidade de negócios inesperadamente ganha um contrato que requer adicionais serviços de TI, mais capacidade e mais rápido tempo de respostas. A capacidade de responder a este tipo de mudança, sem afetar outros serviços é um desafio significativo. Muitas organizações de TI não são capazes de alcançar este equilíbrio e tendem a se concentrar em qualquer estabilidade da infra-estrutura de TI ou a capacidade de responder às mudanças rapidamente. ITIL V3 - Operação de Serviço - Página: 46 de 423
    • Figura 3.2 Atingir um equilíbrio entre o foco na estabilidade e capacidade de resposta A Tabela 3.2 resume alguns exemplos das características de posições em extremos do espectro. O objetivo desta tabela é para ajudar as organizações a identificar para não que eles estão mais próximos extrema, para identificar vida real cargos para os quais as organizações devem aspirar. Foco extremo na estabilidade Foco extremo na resposta Foco principal • Tecnologia • Desenvolvimento e aperfeiçoamento de técnicas de gestão de TI e processoes. • Saída para o negócio • Concorda com as alterações necessárias antes de determinar o que vai demorar para entregá-los. Típico problemas experimentado TI pode demonstrar que está cumprindo com os POPs e Acordo de Nível Operacionals (ANO), mesmo quando não há desalinhamento claro para negócios exigências A equipe de TI não estão disponíveis para definir ou executar tarefas de rotina, porque eles estão ocupados em projetos para novos serviços Crescimento da tecnologia estratégia • Estratégia de crescimento com base na análise da demanda existente na actual sistemas • Novos serviços estão resistiu e Unidade de Negócioss vezes, • Tecnologia adquirida para cada requisito de novos negócios • Usando múltiplas tecnologias e soluções ITIL V3 - Operação de Serviço - Página: 47 de 423
    • tomar posse de "seus próprios sistemas para ganhar acesso a novos serviços. para soluções semelhantes, para atender às necessidades de negócios ligeiramente diferentes. A tecnologia utilizada para entregar De serviços de TIs A tecnologia existente ou padrão a ser utilizado; serviços devem ser ajustadas para funcionar dentro de parâmetros existentes Mais de provisionamento. Nenhuma tentativa foi feita para modelar a nova serviço na infra- estrutura existente. Tecnologia nova e dedicada é adquirido para cada novo projeto Gerenciamento da Capacidade • Previsões com base em projeções de corrente carga de trabalhos • Sistema atuação é mantida em níveis consistentes através afinação e gestão da procura, E não por previsão de carga de trabalho e gestão. • Previsões com base em negócios futuros atividade para cada serviço individualmente e não levam em conta a atividade de TI ou outros serviços de TI • Cargas de trabalho existentes não são relevantes. Tabela 3.2 Exemplos de extremo foco na estabilidade e capacidade de resposta A construção de uma TI organização que alcança um equilíbrio entre a estabilidade e capacidade de resposta em Operação de Serviço exigirá as seguintes ações: • Garantir o investimento em tecnologias e processos que são adaptativas ao invés de rígida, por exemplo, virtual servidor e aplicação tecnologia e da utilização de Mudança do modelos (ver Transição de Serviço publicação). • Construir uma forte Gerenciamento de Nível de Serviço (SLM) processo que está ativo a partir do Design de Serviços fase para a Melhoria de Serviço Continuada fase do ITSM Ciclo de Vida. • Promover a integração entre SLM e os processos de design de outros serviços para garantir mapeamento adequado de requisitos de negócio para TI operacional actividades e componentes da Infraestrutura de TI. Isso torna mais fácil para modelar o efeito de mudanças e melhorias. • Iniciar mudanças na primeira fase apropriada no Ciclo de Vida de ITSM. Isso irá garantir que tanto funcional (de negócios) e capacidade de gerenciamento (TI operacional) exigências pode ser avaliado e construído ou alterado juntos. • Garantir o envolvimento da TI no negócio muda tão cedo quanto possível no mudar processo para assegurar escalabilidade, Consistência e capacidade de concretização de De serviços de TIs sustentar mudanças de negócios. ITIL V3 - Operação de Serviço - Página: 48 de 423
    • • Operação de Serviço equipes devem fornecer informações para o curso projeto e refinamento da arquiteturas e serviços de TI (ver Design de Serviços e Serviço de publicações estratégia). • Implementar e usar SLM para evitar situações onde os negócios e os gerentes de TI e pessoal de negociar informal acordos. 3.2.3 A qualidade do serviço versus custo do serviço Operação serviço é necessário para entregar consistentemente o nível acordado de serviços de TI para a sua clientes e usuários, enquanto que, ao mesmo tempo mantendo custars e recurso utilização em um nível ideal. Figura 3.3 representa o investimento realizado para entregar um serviço em níveis crescentes de qualidade. Figura 3.3 a qualidade do serviço de balanceamento e custo Na Figura 3.3, um aumento do nível de qualidade geralmente resulta em um aumento no custo do serviço, e vice-versa. No entanto, o relação nem sempre é diretamente proporcional: • Logo no início do serviço de ciclo de vida é possível conseguir aumentos significativos na qualidade de serviço, com uma quantidade relativamente pequena de dinheiro. Por exemplo, melhorar o serviço disponibilidade de 55% para 75% é bastante simples e não pode exigir um investimento enorme. • Mais tarde no ciclo de vida do serviço, mesmo pequenas melhorias na qualidade são muito caros. Por exemplo, melhorar a disponibilidade do ITIL V3 - Operação de Serviço - Página: 49 de 423
    • mesmo serviço de de 96% para 99,9% pode exigir grandes investimentos em tecnologia de alta disponibilidade e pessoal de apoio e ferramentas. Embora isso possa parecer simples, muitas organizações estão sob forte pressão para aumentar a qualidade do serviço e reduzir os seus custos. Na Figura 3.3, a relação entre custo e qualidade às vezes é inversa. É possível (normalmente dentro da gama de optimização) para aumentar a qualidade e reduzir custos. Isto é normalmente iniciado dentro de Operação de Serviço e transportados por Melhoria de Serviço Continuada. Alguns custos podem ser reduzidos gradualmente ao longo do tempo, mas as economias mais custos pode ser feita apenas uma vez. Por exemplo, uma vez que uma ferramenta de software duplicado foi eliminada, não pode ser eliminada de novo para redução de custos adicionais. Alcançar um equilíbrio ideal entre custar e qualidade (mostrado entre as linhas pontilhadas na Figura 3.3) é uma chave papel de Serviço de Gestão de. Não há indústria padrão para o que este intervalo deve ser, uma vez que cada serviço terá uma gama diferente de optimização, dependendo da natureza do serviço e do tipo de objetivo de negócio sendo atendidas. Por exemplo, a empresa pode estar preparado para gastar mais para alcançar alta disponibilidade em um serviço de missão crítica, enquanto ele está preparado para conviver com a baixa qualidade de uma ferramenta administrativa. Determinar o equilíbrio de custo e de qualidade deve ser feito durante o Estratégia de Serviço e Design de Serviços Ciclo de Vida fases, embora em muitas organizações é deixada para o Operação de Serviço equipes - muitos dos quais não têm, geralmente, todos os fatos ou a autoridade para ser capaz de fazer este tipo de decisão. Infelizmente, também é comum encontrar organizações que estão gastando grandes quantidades de dinheiro, sem realização de quaisquer melhorias claras na qualidade. Novamente, Melhoria de Serviço Continuada será capaz de identificar a causa da ineficiência, avaliar o equilíbrio ideal para esse serviço e formular um corretivo plano. Atingir o equilíbrio correto é importante. Foco muito em qualidade resultará em De serviços de TIs que oferecem mais do que o necessário, a um custo maior, e pode levar a uma discussão sobre a redução do preço dos serviços. Foco muito no custo resultará em TI entrega ou sob orçamento, Mas colocar o negócio em risco através de sub-padrão de serviços de TI. Nota especial: o quão longe é demais? Ao longo dos últimos anos, as organizações de TI estão sob pressão para cortar custos. Em muitos casos, isto resultou em otimizard e custos qualidade. Mas, noutros casos, os custos foram reduzidos até ao ponto em que passou a ITIL V3 - Operação de Serviço - Página: 50 de 423
    • padecer de qualidade. Na primeira, os sinais eram sutis - pequenos aumentos de incidente resolução vezes e um ligeiro aumento no número de incidentes. Com o tempo, porém, a situação se tornou mais grave como o pessoal trabalhava longas horas para lidar com múltiplas carga de trabalhos serviços e correu em infra-estrutura envelhecida ou ultrapassada. Não há cálculo simples para determinar quando os custos foram cortados longe demais, mas SLM bom é crucial para a tomada clientes conscientes da impacto de corte muito longe, tão reconhecer esses sinais e sintomas podem melhorar muito a organizaçãoCapacidade 's para corrigir esta situação. Exigência de Nível de Serviços - juntamente com uma compreensão clara do objeto social da serviço e os riscos potenciais - vai ajudar a garantir que o serviço é entregue ao custo adequado. Eles também ajudam a evitar "superdimensionamento" do serviço simplesmente porque o orçamento está disponível, ou "sob dimensionamento", porque a empresa não entender o gerenciamento exigências da solução. Ou resultado fará com que a insatisfação do cliente e despesa ainda mais quando a solução é re-engenharia ou retro- equipada com os requisitos que deveriam ter sido especificados durante a Design de Serviços. Figura 3.4 Atingir um equilíbrio entre o foco no custo e qualidade Tabela 3.3 apresenta alguns exemplos das características de posições em lados extremos do espectro de custo / qualidade. O objetivo desta tabela é para ajudar as organizações a identificar para não que eles estão mais próximos extrema, para identificar vida real cargos para os quais as organizações devem aspirar. Extremo foco na qualidade Foco extremo no custo Foco principal Cumprindo o nível de qualidade exigido pela empresa, independentemente do Reunião orçamento e reduzindo custars ITIL V3 - Operação de Serviço - Página: 51 de 423
    • que é preciso Típico problemas experimentado • Orçamentos crescentes • De serviços de TIs geralmente entregar mais do que é necessário para o sucesso do negócio • Crescentes exigências de maiorqualidade serviços. • Ele limita a qualidade de serviço com base no seu orçamento disponibilidade • Escaladas da empresa para obter mais serviços de TI. Gestão Financeira Ele geralmente não tem um método de comunicação do custo de serviços de TI. Contabilidade métodos baseiam-se num método de agregados (por exemplo, custo de TI por usuário). O relatório financeiro é feito puramente em valores orçamentados. Não há nenhuma maneira de ligar as atividades de TI para a entrega de serviços de TI. Tabela 3.3 Exemplos de extremo foco na qualidade e custo Alcançar um equilíbrio irá garantir a entrega do nível de serviço necessário para atender negócios exigências a uma óptima (em oposição a menor possível) o custo. Isso vai exigir o seguinte: • Um processo de Gestão Financeira e ferramentas que podem esclarecer o custo da prestação de serviços de TI, e qual o modelo de métodos alternativos de prestação de serviços em diferentes níveis de custo. Por exemplo, comparando o custo de fornecimento de um serviço de disponibilidade de 98% ou menos 99,9% de disponibilidade, ou o custo da prestação de um serviço com ou sem funcionalidade adicional. • Assegurar que as decisões em torno custo versus qualidade são feitas pelos gestores adequadas durante Estratégia de Serviço e Design de Serviços. TI operacional gerentes não são geralmente equipados para avaliar oportunidades de negócios e só deve ser solicitado a tomar decisões financeiras que estão relacionadas a alcançar a eficiência operacional. 3.2.4 reativa contra proativo Um reactivo organização é aquele que não age a menos que seja solicitado a fazê-lo por uma externa motorista, E.g. um requisito de negócio novo, uma aplicação que tem sido desenvolvido ou escalada em reclamações feitas por usuários e clientes. Uma triste realidade em muitas organizações é o foco na gestão reactiva erroneamente como o único meio para assegurar serviços que são altamente consistente e estável, ativamente desencorajar comportamento pró-ativo da equipe operacional. A ironia infeliz desta abordagem é que o investimento em esforço desanimador proativo Serviço de Gestão de pode, finalmente, aumentar o esforço e custo das atividades reativas e mais risco estabilidade e consistência nos serviços. ITIL V3 - Operação de Serviço - Página: 52 de 423
    • Uma organização pró-ativa está sempre procurando maneiras de melhorar a situação atual. Ele continuamente varredura interna e externa ambientes, procurando sinais de potencialmente impactar mudanças. Comportamento pró- ativo é geralmente visto como positivo, especialmente uma vez que permite que a organização para manter a vantagem competitiva em um ambiente em mudança. No entanto, ser muito activa podem ser caros e podem resultar em pessoal ser distraído. A necessidade de equilíbrio no comportamento reativo e proativo consegue muitas vezes o resultado ideal. Geralmente, é melhor para gerenciar serviços de TI de forma proativa, mas conseguir isso não é facilmente planejado ou alcançado. Isto porque a construção de uma organização de TI pró-ativa é dependente de muitas variáveis, incluindo: • O maturidade do organização. Quanto mais tempo a organização foi entregar um conjunto consistente de De serviços de TIs, o mais provável é entender a relação entre a TI e os negócios ea Infraestrutura de TI e serviços de TI. • O cultura da organização. Algumas organizações têm uma cultura que está focada na inovação e são mais propensos a ser proativo. Outros são mais propensos a se concentrar sobre o status quo e, como tal, são susceptíveis de resistir mudar e ter mais foco reativo. • O papel que a TI desempenha no negócio e do mandato que a TI tem de influenciar o estratégia e táticas da empresa. Por exemplo, uma empresa onde o CIO é um membro do conselho é provável que tenha uma organização de TI que é muito mais pró-ativo e ágil do que uma empresa onde a TI é vista como um administrativo despesas gerais. • O nível de integração de processos e ferramentas de gestão. Níveis superiores de integração vai facilitar um melhor conhecimento das oportunidades. • A maturidade e escopo de Gestão do Conhecimento na organização, o que é visto especialmente em organizações que têm sido capazes de armazenar e organizar dados históricos de forma eficaz - especialmente Disponibilidade e Gerenciamento de Problemas dados. De uma perspectiva de maturidade, é claro que as organizações mais novas terão prioridades diferentes e experiências de uma organização mais estabelecida - o que é melhores práticas para uma organização madura não pode atender um jovem organização. Portanto, um desequilíbrio pode resultar de uma organização ou ser menos ou mais maduro. Considere o seguinte: • Organizações menos maduras (ou organizações com novos serviços de TI ou tecnologia), geralmente, mais reativa, simplesmente porque eles não sabem todas as variáveis envolvidas na execução de seus negócios e oferecer serviços de TI. ITIL V3 - Operação de Serviço - Página: 53 de 423
    • • A equipe de TI em organizações mais recentes tendem a ser generalistas porque não está claro exatamente o que é necessário para entregar estáveis serviços de TI para o negócio. • Incidentes e problemas em organizações mais novas são bastante imprevisíveis, pois a tecnologia é relativamente nova e mudanças rapidamente. • Organizações mais maduras tendem a ser mais pró-ativa, simplesmente porque têm mais dados e relatórios disponíveis e conhecer os padrões típicos de incidentes e fluxos de trabalho. Assim, eles prevêem exceções muito mais facilmente. • O pessoal que trabalha em organizações maduras também geralmente tendem a ter relacionamentos mais estáveis entre a equipe de TI e os negócios e por isso pode ser mais proativo sobre o encontro de negócios em constante mudança exigências - isto é especialmente verdadeiro quando a TI é vista como um estratégico componente do negócio. Figura 3.5 Atingir um equilíbrio entre ser muito reativa ou proativa também ITIL V3 - Operação de Serviço - Página: 54 de 423
    • A Tabela 3.4 resume alguns exemplos das características de posições em extremos do espectro. O objetivo desta tabela é para ajudar as organizações a identificar para não que eles estão mais próximos extrema, para identificar vida real cargos para os quais as organizações devem aspirar. Extremamente reativo Extremamente proativa Foco principal Responde às necessidades de negócios e incidentes só depois que eles são relatados Antecipa negócios exigências antes de serem comunicados e problemas antes que elas ocorram Os problemas típicos experimentado • Preparando-se para oferecer novos serviços leva um longo tempo, porque cada projeto é tratado como se fosse o primeiro • Incidentes similares ocorram novamente e de novo, como não há nenhuma maneira de tendências los • Rotatividade de pessoal é alta eo moral é geralmente baixo, como a equipe de TI se manter em movimento de projeto para projeto, sem alcançar um conjunto, duradouras estável de De serviços de TIs • Dinheiro é gasto antes que os requisitos são demonstrados. Em alguns casos em que compra itens que nunca serão usados porque antecipou as exigências erradas ou porque o projeto está parado • A equipe de TI tendem a ter estado no organização por um longo tempo e tendem a assumir que eles sabem os requisitos de negócio melhor do que a empresa faz Planejamento de Capacidade Espere até que haja capacidade problemas e, em seguida, adquirir a capacidade excedente para durar até que o incidente relacionado com a capacidade próxima Antecipar problemas de capacidade e gastar dinheiro em prevenção estes - mesmo quando o cenário é improvável que isso aconteça Planejamento da Continuidade dos Serviços de TI • Não planos existir até depois de um grande evento ou desastre • Ela planeja foco na recuperação de chave sistemas, mas sem garantir que a empresa pode recuperar seus processos Over-planejamento (E sobre os gastos) de TI Opção de recuperaçãos. Geralmente recuperação imediata é fornecido para a maioria De serviços de TIs, independentemente da sua impacto ou prioridade Gestão da Mudança • As alterações são muitas vezes não registrado, ou registrado no último minuto, como Mudança de emergências • Não é tempo suficiente para o impacto adequada e custar avaliaçãos As alterações são solicitados e aplicado mesmo quando não existe uma necessidade real, isto é, uma quantidade significativa de trabalho para fixar os artigos que não são quebrados ITIL V3 - Operação de Serviço - Página: 55 de 423
    • • As alterações são pouco estudado e controlado, o que resulta num elevado número de incidentes Tabela 3.4 Exemplos de comportamento extremamente reativo e proativo Embora o comportamento pró-ativo em Operação de Serviço geralmente é bom, também há momentos em que o comportamento reativo é necessário. O papel de Operação de Serviço é, portanto, para alcançar um equilíbrio entre ser reativa e pró-ativa. Isso vai exigir: • Formal Gerenciamento de Problemas e Gerenciamento de Incidentes processos, integrada entre Operação de Serviço e Melhoria de Serviço Continuada. • A habilidade de ser capaz de priorizar falhas técnicas, bem como as demandas de negócios. Isso precisa ser feito durante a operação de serviço, mas os mecanismos precisam ser postas em prática durante Estratégia de Serviço e Design. Estes mecanismos podem incluir categorização incidente sistemas, escalada procedimentos e ferramentas para facilitar impacto avaliação para mudanças. • Dados de configuração e Gestão de Ativos para fornecer dados, quando necessário, economizando projetos do tempo e tomar decisões mais precisas. • Participação permanente do SLM na Operação de Serviço. ITIL V3 - Operação de Serviço - Página: 56 de 423
    • 3,3 prestação de serviços Todo o pessoal Operação de Serviço devem estar plenamente conscientes de que eles estão lá para "prestar serviço" para o negócio. Eles devem fornecer um oportuno (resposta rápida e entrega rápida dos exigências), profissional e cortês serviço para permitir que a empresa para realizar suas próprias atividades - de forma que o comercial cliente'S necessidades são satisfeitas eo negócio prospera. É importante que os funcionários são treinados não apenas em como entregar e apoiar De serviços de TIs, mas também na forma em que o serviço a ser fornecido. Por exemplo, funcionários que são capazes e prestar serviços de forma eficaz ainda pode causar insatisfação do cliente significativo se eles são insensíveis ou de desprezo. Por outro lado, nenhuma quantidade de ser agradável para um cliente irá ajudar se o serviço não está sendo entregue. Um elemento crítico de ser proficiente provedor de serviços está a colocar tanta ênfase no recrutamento e treinamento de pessoal para desenvolver competência em lidar com clientes e gestão relaçãos e interações como eles fazem em competências técnicas para a gestão de TI ambiente. ITIL V3 - Operação de Serviço - Página: 57 de 423
    • 3,4 a participação do pessoal de operação em Design de Serviços e Transição de Serviço É extremamente importante que o pessoal de operação de serviço estão envolvidas em Design de Serviços e Transição de Serviço e, potencialmente, também na Estratégia de Serviço, onde apropriado. Uma chave para alcançar o equilíbrio na Operação de Serviço é um conjunto eficaz de processos de design de serviço. Estes proporcionarão TI Gestão de Operações com: • Definição clara de serviço de TI objetivos e atuação critérios • Ligação de serviço de TI especificaçãos para o desempenho do Infraestrutura de TI • Definição de operacional requisitos de desempenho • Um mapeamento de serviços e tecnologia • A capacidade de modelar o efeito de mudanças na tecnologia e mudanças para as empresas exigências • Apropriado custar modelos (por exemplo, cliente ou serviço baseado) para avaliar o retorno do investimento e redução de custos estratégias. A natureza do TI Gestão de Operações envolvimento deve ser cuidadosamente posicionadas. Design de Serviços é uma fase na Serviço de Gestão de Ciclo de Vida utilizando um conjunto de processos, e não um função independente da operação do serviço. Como tal, muitas das pessoas que estão envolvidas em Design de Serviços virá de TI Gestão de Operações. Isso não só deve ser incentivado, mas Operação de Serviço pessoal deve ser medido em seu envolvimento em atividades de design de serviço - e tais atividades devem ser incluídas no descrição do trabalhos e papels, etc Isto irá ajudar a assegurar a continuidade entre os requisitos de negócios e tecnologia projeto e operação e que também irá ajudar a assegurar que o que é concebida também pode ser operado. Operações de TI equipe de Gestão também devem ser envolvidos durante Transição de Serviço para garantir a consistência e para garantir que o negócio declarado e capacidade de gerenciamento são cumpridos. Recursos devem estar disponíveis para estas actividades e o tempo requerido deve ser levado em conta, se for caso disso ITIL V3 - Operação de Serviço - Página: 58 de 423
    • 3,5 Saúde Operacional Muitas organizações acham que é útil para comparar a monitoramento e controlar de Operação de Serviço de vigilância da saúde e de controle. Neste sentido, o Infraestrutura de TI é como um organismo que tem sinais vitais que podem ser monitorados para verificar se ele está funcionando normalmente. Isto significa que não é necessário monitorizar continuamente sempre componente de cada TI sistema para assegurar que este está a funcionar. Saúde operacional pode ser determinado através do isolamento de algumas importantes "sinais vitais" em dispositivos ou serviços que são definidas como essenciais para a boa execução de um Função de Negócios Vital. Esta poderia ser a utilização de largura de banda de um segmento de rede, ou a utilização da memória em uma grande servidor. Se estes sinais estão dentro dos limites normais, o sistema é saudável e não necessita de maior atenção. Esta redução na necessidade de monitorização extensa resultará em redução de custos e operacional equipes e departamentos que estão focados em áreas apropriadas para serviço sucesso. No entanto, tal como com os organismos, é importante para verificar a sistemas mais minuciosamente ao longo do tempo, para verificar se há problemas que não afetam imediatamente os sinais vitais. Por exemplo, um disco pode estar funcionando perfeitamente, mas poderia estar chegando ao Tempo médio entre falhas (MTBF) limiar. Neste caso, o sistema deve ser retirado de serviço e dado um exame completo ou "exame de saúde". Ao mesmo tempo, deve sublinhar-se que o resultado final deve ser o funcionamento saudável do serviço como um todo. Isto significa que exames de saúde sobre os componentes deve ser equilibrada contra cheques de serviço o "fim-a-fim". A definição do que precisa ser monitorado e que é saudável em relação saudável é definida durante a Design de Serviços, especialmente Gerenciamento de Disponibilidade e SLM. Saúde operacional é dependente da capacidade de prevenir incidentes e problemas, investindo em infra-estrutura confiável e de fácil manutenção. Isto é conseguido através de boas disponibilidade projeto e Gerenciamento de Problemas pró-ativa. Ao mesmo tempo, Health operacional é também dependente da capacidade de identificar falhas e localizá-los de forma eficaz, de modo que eles têm um mínimo impacto sobre o serviço. Isso requer Incident (de preferência automático) forte e Gerenciamento de Problemas. A idéia de Saúde Operacional também levou a uma área especializada chamada "Sistemas de auto-cura. Trata-se de um aplicação de gerenciamento de disponibilidade, capacidade, conhecimento de Incidentes e Problemas e refere- se a um sistema que foi concebido para suportar as condições operacionais mais severas e para detectar, diagnosticar e recuperar a maioria dos incidentes e Erro Conhecidos. Sistemas de auto-cura são conhecidos por nomes ITIL V3 - Operação de Serviço - Página: 59 de 423
    • diferentes, por exemplo, sistemas autônomos, sistemas adaptativos e Sistemas Dinâmicos. Características dos sistemas de auto-cura incluem: • Resiliência é projetado e construído para o sistema, por exemplo, vários discos redundantes ou processadores de múltiplos. Isso protege o sistema contra hardware falha uma vez que é capaz de continuar a funcionar, utilizando o hardware repetido componente. • Software, dados e resiliência do sistema operacional também é projetado para o sistema, por exemplo, bancos de dados espelhado (onde um banco de dados é duplicado em um apoio dispositivo) e disco striping tecnologia (onde pedaços individuais de dados são distribuídos através de uma matriz de disco - de modo que resulta uma falha no disco de perda de apenas uma parte dos dados, que pode ser facilmente recuperado usando algoritmos). • A capacidade de deslocar processamento de um dispositivo físico para outro, sem qualquer interrupção do serviço. Esta poderia ser uma resposta a uma falha ou porque o dispositivo está a atingir níveis de utilização elevados (alguns sistemas são projetados para distribuir o processamento carga de trabalhos de forma contínua, para fazer o melhor uso disponível capacidade, O qual também é conhecido como virtualização). • Embutido monitoramento utilitários que permitem que o sistema para detectar eventos e para determinar se estes representam normais operaçãos ou não. • Um mecanismo de correlação (ver parágrafo 4.1.5.6 em Gestão de Eventos). Isto irá permitir que o sistema para determinar o significado de cada evento e também para determinar se há qualquer resposta a esse evento predefinido. • Um conjunto de ferramentas de diagnóstico, tais como script de diagnósticos, falta de árvores e uma base de dados de Erro Conhecidos e comum solução alternativas. Estes são utilizados tão logo um erro for detectado, para determinar a resposta adequada. • A capacidade de gerar um chamar por intervenção humana, gerando uma alertar ou a geração de um incidente. Embora o conceito de Saúde Operacional não é um conceito central do Operação de Serviço, Muitas vezes é uma metáfora útil para ajudar a determinar o que precisa ser monitorado e freqüência para realizar a manutenção preventiva. O que e quando para monitorar operacional saúde deve ser determinado em Design de Serviços, Testado e aperfeiçoado durante Transição de Serviço e otimizard em Melhoria de Serviço Continuada, Conforme necessário. ITIL V3 - Operação de Serviço - Página: 60 de 423
    • 3,6 Comunicação Uma boa comunicação é necessária com outras equipes de TI e departamentos, com usuários e clientes internos, e entre as equipes de serviço de operação e departamentos próprios. Questões muitas vezes pode ser evitado ou atenuado com comunicação adequada. Esta seção tem como objetivo resumir a comunicação que deve ocorrer em operação de serviço. Esta não é uma separada processo, Mas uma lista de verificação do tipo de comunicação que é necessário para a operação de serviço eficaz. Um princípio importante é que toda a comunicação deve ter uma finalidade ou uma acção resultante. As informações não devem ser comunicados a menos que haja um público claro. Além disso, esse público deveria ter se envolvido ativamente na determinação da necessidade de que a comunicação eo que eles vão fazer com a informação. Uma descrição mais detalhada dos tipos de comunicação típico em operação de serviço está contida no Apêndice B da presente publicação, em conjunto com uma descrição da audiência típica e as acções que se destinam a ser tomadas como resultado de cada comunicação. Estes incluem: • Rotina operacional comunicação • A comunicação entre deslocars • Relatórios de desempenho • Comunicação em projetos • Comunicação relacionada com alterações • Comunicação relacionada com exceções • Comunicação relacionada a emergências • Treinamento sobre processos novos ou personalizado e design de serviços • Comunicação de estratégia e design para Operação de Serviço equipes. Por favor, note que não há meio de comunicação definitivo, nem existe um local fixo ou de freqüência. Em algumas organizações de comunicação tem que ocorrer nas reuniões. Outras organizações preferem usar e-mail ou a comunicação inerente à sua Serviço de Gestão de ferramentas. Assim, deverá ser um política em torno da comunicação dentro de cada equipe ou departamento e para cada processo. Embora este deve ser formal, a política não deve ser complicado ou complexo. Por exemplo, um gerente pode exigir que todas as comunicações relativas a mudanças devem ser enviadas por e-mail. Enquanto isso é especificado em POPs do departamento (em qualquer forma que eles existem), não há necessidade de criar uma política separada para ele. ITIL V3 - Operação de Serviço - Página: 61 de 423
    • Embora o conteúdo típico de comunicação é bastante consistente uma vez os processos foram definidos, os meios de comunicação estão mudando a cada nova introdução da tecnologia. A lista de alternativas está crescendo e, hoje, inclui: • E-mail, ao tradicional clientes ou dispositivos móveis • Mensagens SMS • Pagers • Mensagens instantâneas e web-based 'chats' • Voz sobre Protocolo de Internet (VoIP) utilitários que podem transformar qualquer dispositivo conectado a um meio de comunicação de baixo custo • Utilitários reunião por teleconferência e virtuais, revolucionaram reuniões que estão agora realizadas através de longas distâncias • DocumentoDe partilha de serviços públicos. Os meios de comunicação em si está fora do escopo desta publicação. No entanto, os seguintes pontos devem ser observados: • A comunicação é fundamental e os meios de comunicação devem garantir que eles servem este objetivo. Por exemplo, a necessidade para uma comunicação segura pode eliminar a possibilidade de alguns dos meios acima referidos. A necessidade de qualidade pode eliminar algumas opções de VoIP. • É possível utilizar qualquer meio de comunicação, desde que todos das partes interessadass compreender como e quando a comunicação ocorrerá. 3.6.1 Reuniões Organizações diferentes formas de comunicação diferentes. Onde as organizações são distribuídos, eles tendem a confiar em e-mail e instalações de teleconferência. Organizações que possuem processos de serviços mais maduros e ferramentas de gestão tendem a confiar nas ferramentas e processos de comunicação (por exemplo, usando um Gerenciamento de Incidentes ferramenta para aumentar e acompanhar incidentes, em vez de solicitar e-mail ou telefone para chamadas de atualizações). Outras organizações preferem se comunicar utilizando reuniões. No entanto, é importante não entrar no modo pelo qual o trabalho a tempo só é feito, ou de gestão está envolvido, é durante uma reunião. Além disso, face-a-face tendem a aumentar custars (por exemplo, o tempo de viagem, passou em discussões informais, bebidas, etc), assim que os organizadores da reunião deve equilibrar o valor da reunião com o número ea identidade dos participantes e do tempo que eles passam, e chegar, a reunião. ITIL V3 - Operação de Serviço - Página: 62 de 423
    • O propósito das reuniões é comunicar de forma eficaz para um grupo de pessoas sobre um conjunto comum de objetivos ou atividades. As reuniões devem ser bem controlada e breve, eo foco deve ser a facilitar a acção. Uma boa regra é não realizar uma reunião, se a informação pode ser comunicada de forma eficaz por meios automáticos. Uma série de fatores são essenciais para o sucesso de reuniões. Embora estes possam parecer senso comum, às vezes são negligenciados: • Estabelecer e comunicar uma agenda clara para garantir que a reunião atinge seu objetivo e ajudar o facilitador evitar participantes de 'oi-jacking "da reunião. • Assegurar que as regras para participar são compreendidos. As organizações tendem a ter um conjunto formal de regras de reuniões, que variam de relativamente informal para muito formal (por exemplo, regras Roberts da Ordem). • Fazer uso de 'estacionamentos' ou notas que registro questões que não são diretamente relevantes para o objetivo da reunião, mas que podem ser chamados em caso de necessidade de discussão surge. • Ata da reunião: as regras devem ser definidas sobre quando os minutos são tomadas. Minutos são utilizados para lembrar as pessoas que estão atribuídas ações e acompanhar o andamento das ações delegadas. Eles também são úteis para garantir que multifuncionais decisões e ações são acompanhadas e seguidas por. • Use técnicas para incentivar o nível adequado de participação. Uma técnica ao discutir melhorias, por exemplo, é a "manter, parar, começar a 'técnica. Os participantes são encorajados a lista de itens que eles gostariam de manter, coisas que precisam ser parado e iniciativas ou ações que eles gostariam de ver iniciada. Exemplos de reuniões típicos são apresentados a seguir: 3.6.1.1 A reunião de Operações Reuniões operações são normalmente realizadas entre os gestores da TI operacional departamentos, equipes ou grupos, no início de cada dia de trabalho ou semana. O objetivo deste tipo de reunião é fazer com que o pessoal ciente de qualquer assunto relevante para Operações (como alteração de horários, os negócios eventos, programas de manutenção, etc) e dar uma oportunidade para o pessoal para levantar quaisquer questões de que tenham conhecimento. Esta é uma oportunidade para assegurar que todos os departamentos de um centro de dados são sincronizados. Em organizações geograficamente dispersas, pode não ser possível ter uma única reunião de Operações diária. Nestes casos, é importante para coordenar a agenda das reuniões e assegurar que cada reunião tem dois componentes: ITIL V3 - Operação de Serviço - Página: 63 de 423
    • 1. A primeira parte da reunião vai cobrir aspectos que se aplicam ao organização como um todo, por exemplo, novas políticas, mudanças que afetam todas as regiões e negócios eventos que abrangem todas as regiões. 2. A segunda parte da reunião vai cobrir aspectos que se aplicam apenas à região local, por exemplo, local operaçãohorários s, as mudanças de equipamento local, etc A reunião de Operações geralmente é presidido pelo Operações de TI Gerente ou um gerente de operações sênior e com a participação de todos os gerentes e supervisores (exceto aqueles cujos deslocars não estão em serviço). Também é útil ter pelo menos um representante do Service Desk na reunião, de modo que eles estão cientes de todas as situações que podem dar origem a incidentes. Oportunidades para melhorar os serviços ou processos devem ser capturados, se levantou, e encaminhado para a equipe responsável pela Melhoria de Serviço Continuada. 3.6.1.2 Departamento reuniões de grupo ou equipe Estas reuniões são essencialmente o mesmo que o encontro de Operações, mas destinam-se a um grupo de TI único departamento ou equipe. Cada gerente ou supervisor transmite a informação a partir da reunião de Operações que é relevante para a sua equipe. Além disso, estas reuniões também abranger o seguinte: • Uma discussão mais detalhada de incidentes, problemas e as mudanças que ainda estão sendo trabalhados, com informações sobre: • Progredir até à data • A confirmação de que ainda precisa ser feito • Tempo estimado para conclusão • Pedido de adicional recursos, se for necessário • Discussão de possíveis problemas ou preocupações • A confirmação da equipe disponibilidade para deveres roster • Confirmação de horários de férias. 3.6.1.3 reuniões com clientes De tempos em tempos, será necessário a realização de reuniões com clientes, independentemente do nível de serviço regular Comente reuniões. Os exemplos incluem: • Acompanhamento após incidentes graves. O objectivo destas reuniões é para reparar o relação com os clientes, mas também para garantir que ele tenha todas as informações necessárias para evitar a recorrência. Os ITIL V3 - Operação de Serviço - Página: 64 de 423
    • clientes também têm a oportunidade de fornecer informações sobre o negócio imprevisto impactos. Estas reuniões são úteis em concordar ações para os tipos semelhantes de incidentes que podem ocorrer no futuro. • Um forum cliente, que pode ser usado para uma variedade de finalidades, incluindo testes de ideias para novos serviços ou soluções, ou reunindo exigências para serviços novos ou revista ou procedimentos. Um fórum cliente é geralmente um encontro regular com os clientes para discutir áreas de interesse comum. ITIL V3 - Operação de Serviço - Página: 65 de 423
    • 3,7 Documentação TI Gestão de Operações e todas as técnicas e Aplicação de Gestão de equipes e departamentos estão envolvidos na criação e manutenção de uma série de documentos. Estes são detalhados nos capítulos 4, 5 e 6 da presente publicação e incluem o seguinte: • Participação na definição e manutenção de processo manuais para todos os processos em que estão envolvidos dentro Estes irão incluir processos em outras fases do IT Service Management Ciclo de Vida (E.g. Gerenciamento da Capacidade,Gestão da Mudança,Gerenciamento de Disponibilidade), Bem como para todos os processos que fazem parte da Operação de Serviço fase. • Estabelecer a sua própria técnica procedimentomanuais s. Estes devem ser mantidos atualizados e novo material deve ser adicionado como torna-se relevante, sob controle de alterações. Deve ser lembrado que os seus procedimentos devem sempre ser estruturada de forma a satisfazer o objetivos e constrangimentos definidos no nível mais alto Serviço de Gestão de processos, tais como SLM. Por exemplo, um procedimento técnico para o gerenciamento de servidors deve sempre garantir que visa alcançar o disponibilidade e atuação níveis acordados no Acordo de Nível Operacionals e Acordo de Nível de Serviços (SLAs). • Participação na criação e manutenção de planejamento documentos, por exemplo, e Capacity Plano de disponibilidades e a TI Plano de Continuidade do Serviços. • Participação na criação e manutenção do Portfólio de Serviços. Isso incluirá a quantificação custars e que institui a operacional viabilidade de cada proposta serviço. • Participação na definição e manutenção da ferramenta de Gestão de Serviços instrução de trabalhos, a fim de satisfazer relatório exigências ITIL V3 - Operação de Serviço - Página: 66 de 423
    • 4 Operação processos de serviço Os processos listados no ponto 2.4.5 são discutidos em detalhe neste capítulo. Como referência, a estrutura geral é brevemente descrito aqui e, em seguida, cada um dos processos é descrito em mais detalhe mais adiante no capítulo. Por favor, note que o papels para cada processo e as ferramentas utilizadas para cada processo são descritos nos capítulos 6 e 7, respectivamente. • Gestão de Eventos é o processo que monitoriza todos os acontecimentos que ocorrem através do Infraestrutura de TI para permitir o normal, operação e também para detectar e aumentar as condições de excepção. • Gerenciamento de Incidentes concentra-se o serviço para restaurar usuários o mais rapidamente possível, a fim de minimizar a actividade impacto. • Gerenciamento de Problemas envolve análise de causa raiz para determinar e resolver a causa de eventos e incidentes, atividades pró- ativas para detectar e prevenir futuros problemas / incidentes e um Erro Conhecido sub-processo para permitir o rápido diagnóstico e resolução se novos incidentes ocorrem. NOTA: Sem essa distinção entre incidentes e problemas, e manter incidente separado e Grave problemas, existe o perigo de que: • Incidentes será fechado também no início do ciclo de suporte global e não haverá ações tomadas para prevenir a reincidência - de modo que os mesmos incidentes terão de ser fixado e outra vez, ou • Incidentes será mantida aberta para que análise de causa raiz pode ser feito e visibilidade será perdido quando o de usuário'S serviço era, na verdade restaurard - metas de SLA para que não pode ser cumprida mesmo que o serviço foi restaurado dentro das expectativas dos usuários. Isto muitas vezes resulta de um grande número de incidentes abertos, muitos dos quais nunca serão fechado a menos que uma "purga" periódica é realizada. Isso pode ser muito desmotivador e pode impedir a visibilidade eficaz das questões atuais. • Cumprimento de Requisição envolve a administração de cliente ou solicitações de usuários que não são gerados como um incidente de um atraso de serviço ou interrupção inesperada. Algumas organizações podem escolher para lidar com esses pedidos como um 'categoria'De incidentes e gerenciar as informações através de um Gerenciamento de Incidentes sistema - mas outros podem escolher (por causa de grandes volumes ou de negócios prioridade de tais pedidos) para facilitar o fornecimento de capacidades de Cumprimento de Requisição separadamente através do Cumprimento de Requisição processo. ITIL V3 - Operação de Serviço - Página: 67 de 423
    • Tornou-se popular prática utilizar um processo formal de cumprimento de solicitação para gerenciar clientes e usuários pedidos de todos os tipos de pedidos, que incluem instalações, movimentos e suprimentos, bem como aqueles específicos para De serviços de TIs. Estes pedidos não estão geralmente ligados à mesma SLA medidas e separando o registros e o fluxo de processo está a emergir como melhores práticas em muitas organizações. • Gerenciamento de Acesso: Este é o processo de concessão de usuários autorizados o direito de usar um serviço, ao restringir o acesso a usuários não-autorizados. Ele é baseado em ser capaz de identificar com precisão os usuários autorizados e gerenciar sua própria capacidade de acessar serviços como exigido durante as diferentes fases de seus recursos humanos (RH) ou contratual ciclo de vida. Gerenciamento de acesso também tem sido chamado de identidade ou Direitos Gestão em algumas organizações. Além disso, existem vários outros processos que serão executados ou apoiados durante operação de serviço, mas que são conduzidas durante outras fases do Serviço de Gestão de Ciclo de Vida. O operacional aspectos destes processos será discutido na parte final deste capítulo e incluem: • Gestão da Mudança, Um grande processo que deve estar estreitamente ligada à Gerenciamento da Configuração e Gerenciamento de Liberação. Esses tópicos são cobertos principalmente no Transição de Serviço Publicação. • Capacidade e Gerenciamento de Disponibilidade, Os aspectos operacionais do que são abordados nesta publicação, mas que são abordados com mais detalhes no Design de Serviços publicação. • Gestão Financeira, Que é coberto no Estratégia de Serviço publicação. • Gestão do Conhecimento, Que é coberta na publicação Transição de Serviço. • Continuidade do Serviço de TI, que é coberta na publicação Service Design. • Serviço de Relatórios e Mensuração, que são abordados na publicação Melhoria de Serviço Continuada ITIL V3 - Operação de Serviço - Página: 68 de 423
    • 4.1 Gestão de Eventos Um evento pode ser definido como qualquer ocorrência detectável ou discernível que tem importância para a gestão do Infraestrutura de TI ou a entrega de De serviços de TI e avaliação do impacto um desvio poderá causar aos serviços. Os eventos são tipicamente notificações criadas por um serviço de TI, Item de Configuração (CI) ou monitoramento ferramenta. Eficaz Operação de Serviço é dependente de saber o estado da infra-estrutura e detectar qualquer desvio do normal ou esperado operação. Isto é proporcionado pelo bom monitoramento e controlar sistemas, que são baseados em dois tipos de ferramentas: • monitoramento ativo ferramentas que CIs enquete chave para determinar o seu estado e disponibilidade. Quaisquer exceções irá gerar um alertar que precisa ser comunicada para a ferramenta apropriada ou equipe para a ação • monitoramento passivo ferramentas que detectam e correlacionar operacional alertas ou comunicações geradas pela CEI. 4.1.1 Finalidade objetivo / / objetivo A capacidade de detectar eventos, entendê-los e determinar a ação de controle adequados por Gestão de Eventos. Gestão de Eventos é, portanto, a base para o Monitoramento Operacional e Controle (ver Anexo B). Além disso, se estes eventos são programados para comunicar informações operacionais, assim como avisos e excepções, eles podem ser usados como base para a automatização de rotina muitos Gestão de Operações atividades, por exemplo, a execução de scripts em dispositivos remotos, ou enviar trabalhos para o processamento, ou mesmo dinamicamente equilibrar a demanda por um serviço em vários dispositivos para melhorar atuação. Gestão de Eventos, portanto, fornece o ponto de entrada para a execução de muitos Operação de Serviço processos e atividades. Além disso, ele fornece uma forma de comparar o desempenho real e comportamento contra projeto padrãos e SLAs. Como tal, Gestão de Eventos, também fornece uma base para Garantia de Serviço e Comunicação, e melhoria dos serviços. Isso é abordado em detalhes na publicação Melhoria de Serviço Continuada. 4.1.2 Âmbito Gestão de Eventos pode ser aplicado a qualquer aspecto de Serviço de Gestão de que tem de ser controlada, e que pode ser automatizado. Estes incluem: • Item de Configuraçãos: ITIL V3 - Operação de Serviço - Página: 69 de 423
    • • Alguns CIs serão incluídos porque eles precisam ficar em um estado constante (por exemplo, um interruptor em uma rede precisa ficar e ferramentas de Gestão de Eventos confirmar isso respostas de monitoramento para 'pings'). • Alguns CIs serão incluídos porque a sua estado precisa mudar com freqüência e Gestão de Eventos pode ser usado para automatizar esse e atualizar o CMS (por exemplo, a atualização de um arquivo servidor). • Condições ambientais (por exemplo, detecção de incêndio e fumaça) • Monitoramento de licenças de software para uso para garantir ótima / legal a utilização de licença e alocação • Segurança (Por exemplo, detecção de intrusão) • Normal atividade (Por exemplo, rastrear a utilização de um aplicação ou o desempenho de um servidor). A diferença entre monitoramento e Gestão de Eventos Estas duas áreas são muito intimamente relacionados, mas ligeiramente diferente na natureza. Gestão evento é focado na geração e detecção de notificações significativas sobre o estado da Infraestrutura de TI e serviços. Embora seja verdade que o monitoramento é necessário para detectar e rastrear essas notificações, o monitoramento é mais amplo do que Gestão de Eventos. Por exemplo, os instrumentos de controlo irá verificar o estado de um dispositivo para assegurar que está a funcionar dentro de limites aceitáveis, mesmo que o dispositivo não está a gerar eventos. Em termos mais simples, Gerenciamento de Eventos trabalha com as ocorrências que são especificamente gerados a ser monitorado. Monitoramento acompanha essas ocorrências, mas que também irá procurar activamente condições que não geram eventos. 4.1.3 Valor para os negócios Gestão valor evento para o negócio é geralmente indirecto, no entanto, é possível determinar a base para o seu valor como se segue: • Gestão de Eventos oferece mecanismos para o início detecção de incidentes. Em muitos casos, é possível que o incidente a ser detectada e atribuída a um grupo apropriado para a acção antes de qualquer real serviço interrupção ocorre. • Gestão de Eventos torna possível para alguns tipos de automatizado atividade para ser monitorizada por excepção - removendo assim a necessidade de caros e recurso controlo em tempo real intensivo, enquanto reduz tempo de inatividade. ITIL V3 - Operação de Serviço - Página: 70 de 423
    • • Quando integrados em outro Serviço de Gestão de processos (tais como, por exemplo, disponibilidade, ou Gerenciamento da Capacidade), Gestão de Eventos pode sinalizar mudanças de status ou exceções que permitem que a pessoa ou equipe para realizar resposta precoce, melhorando assim a atuação do processo. Isto, por sua vez, permitirá a actividade de beneficiar de Gestão de serviço mais eficaz e mais eficiente em geral. • Gestão de Eventos oferece uma base para automatizado operaçãos, aumentando a eficiência e permitindo caros recursos humanos a serem utilizados para o trabalho mais inovador, como projetoing nova funcionalidade ou melhoria ou a definição de novas formas em que a empresa pode explorar a tecnologia para aumentar a vantagem competitiva. 4.1.4 Políticas / princípios / conceitos básicos Há muitos tipos diferentes de eventos, por exemplo: • Eventos que significam regular funcionamento: • notificação de que uma marcada carga de trabalho completou • umusuário tem conectado para usar uma aplicação • um e-mail chegou ao seu destinatário. • Eventos que significam uma excepção • um usuário tenta fazer logon em um aplicativo com a senha incorreta • uma situação inusitada ocorreu em um processo de negócio que pode indicar uma exceção que exige investigação de novos negócios (por exemplo, uma página da web alertar indica que um site de autorização de pagamento não está disponível - impactando aprovação financeira do negócio transaçãos) • CPU de um dispositivo está acima da taxa de utilização aceitável • uma varredura do PC revela a instalação de software não autorizado. • Eventos que significam incomum, mas não excepcional, operação. Estes são uma indicação de que a situação pode exigir mais perto monitoramento. Em alguns casos, a condição irá resolver-se, por exemplo, no caso de uma combinação invulgar de carga de trabalhos - a sua conclusão, a operação normal é restaurard. Em outros casos, a intervenção do operador podem ser necessários, se a situação é repetido ou se continua por muito tempo. Essas regras ou políticas são definidas nos Objectivos de monitoramento e controle para esse dispositivo ou serviço. Exemplos deste tipo de evento são: • AservidorUtilização da memória atinge até 5% da sua máxima aceitável atuação nível • O tempo de conclusão de uma transação é 10% maior do que o normal. ITIL V3 - Operação de Serviço - Página: 71 de 423
    • Duas coisas são significativos sobre os exemplos acima: • Exatamente o que constitui o funcionamento normal versus anormal, contra uma exceção? Não existe uma regra definitiva sobre isso. Por exemplo, um fabricante pode prever que um referência da utilização da memória 75% é o ideal para aplicação X. No entanto, descobriu-se que, sob as condições específicas da nossa organização,tempo de respostas começam a degradar acima utilização de 70%. A próxima seção irá explorar como esses números são determinados. • Cada conta com o envio e a recepção de uma mensagem de algum tipo. Estes são geralmente referidos como notificações de eventos e eles não acontecem por acaso. Os próximos parágrafos vai explorar exatamente como os eventos são definidos, gerado e capturado. ITIL V3 - Operação de Serviço - Página: 72 de 423
    • 4.1.5 as atividades de processo, métodos e técnicas Figura 4.1 O processo de Gestão de Eventos Figura 4.1 é uma representação de alto nível e genérico de Gestão de Eventos. Ele deve ser usado como um ponto de referência e definição, em vez de um fluxograma de Gestão real do evento. Cada atividade neste processo é descrito abaixo. ITIL V3 - Operação de Serviço - Página: 73 de 423
    • 4.1.5.1 Evento ocorre Eventos ocorrem continuamente, mas nem todos eles são detectados ou registados. Portanto, é importante que todos os envolvidos no projeto, desenvolvimento, gestão e suporte De serviços de TIs e a Infraestrutura de TI que são executados entende que tipos de evento precisa ser detectado. Isso é discutido no parágrafo 4.1.10.1, intitulado "Instrumentação". 4.1.5.2 Notificação de eventos Mais CIs são projetados para comunicar certas informações sobre si mesmos em uma de duas maneiras: • Um dispositivo é interrogado por uma ferramenta de gestão, que recolhe alguns dados segmentados. Isso é muitas vezes referido como voto. • O CI gera uma notificação quando certas condições são satisfeitas. A capacidade para produzir estas notificações tem de ser concebido e construído para o CI, por exemplo um gancho de programação inserido numa aplicação. As notificações de eventos pode ser patenteado, caso em que apenas ferramentas de gestão do fabricante pode ser utilizada para detectar eventos. Mais CIs, no entanto gerar notificações de eventos usando um aberto padrão tais como o SNMP (Simple Network Management Protocol). CIs Muitos estão configurado para gerar um conjunto padrão de eventos, com base na experiência do designer do que é necessário para operar o CI, com a capacidade de gerar outros tipos de eventos de 'ligando' o mecanismo de geração de evento relevante. Para outros tipos de ignição por compressão, de alguma forma de software "agente" terá de ser instalado, a fim de dar início ao monitoramento. Muitas vezes, esse recurso de monitoramento é livre, mas às vezes há um custar para o licenciamento da ferramenta. Em um mundo ideal, a Design de Serviços processo deve definir quais eventos precisam ser geradas e especificar como isso pode ser feito para cada tipo de IC. Durante Transição de Serviço, As opções de geração de eventos seria definido e testado. Em muitas organizações, no entanto, a definição de quais eventos geram é feito por tentativa e erro. Sistema gerentes usam o conjunto padrão de eventos como um ponto de partida e, em seguida, ajustar o IC ao longo do tempo, para incluir ou excluir eventos conforme necessário. O problema com esta abordagem é que ela só leva em conta as necessidades imediatas da equipe gerenciamento do dispositivo e não facilita a boa planejamento ou melhoria. Além disso, torna-se muito difícil de monitorar e gerenciar o serviço sobre todos os dispositivos e ITIL V3 - Operação de Serviço - Página: 74 de 423
    • funcionários. Uma abordagem para combater este problema consiste em rever o conjunto de eventos, como parte das atividades de melhoria contínua. Um princípio geral de notificação de eventos é que a mais significativa os dados que ele contém e do público mais segmentado, mais fácil é para tomar decisões sobre o evento. Operadores são frequentemente confrontados por codificada erro mensagens e não têm idéia de como responder a elas ou o que fazer com eles. Dados significativos de notificação e claramente definidos papels e responsabilidades precisam ser articulados e documentados durante Transição de Serviço Design e Serviços (ver também o parágrafo 4.1.10.1 em "Instrumentação"). Se papels e as responsabilidades não são claramente definidas, em uma ampla alertar, Ninguém sabe quem está fazendo o que e isso pode levar a coisas que estão sendo perdidas ou duplicadas esforços. 4.1.5.3 Detecção de eventos Uma vez que uma notificação de eventos foi gerado, ele será detectado por um agente rodando no mesmo sistema, ou transmitida directamente para uma ferramenta de administração especificamente concebido para ler e interpretar o significado do evento. 4.1.5.4 Evento filtragem O objetivo da filtragem é decidir se a comunicar a evento de uma ferramenta de gestão ou ignorá-lo. Se ignorado, o evento geralmente será gravada em um arquivo de log no dispositivo, mas nenhuma outra ação será tomada. A razão para a filtragem é que nem sempre é possível transformar Evento notificação fora, mesmo que uma decisão foi feita de que não é necessário para gerar esse tipo de evento. Também pode ser decidido que apenas o primeiro de uma série de repetidas Evento notificações serão transmitidos. Durante a etapa de filtragem, o primeiro nível de correlação é realizada, isto é, a determinação de se o evento é informativa, de aviso ou de exceção (veja o próximo passo). Esta correlação é feita geralmente através de um agente que reside no CI ou numa servidor para que o IC está ligado. A etapa de filtragem não é sempre necessário. Para alguns itens de configuração, cada evento é significativo e move directamente no motor de uma ferramenta de gestão de correlação de, mesmo se for duplicada. Além disso, ele pode ter sido possível desligar todos os indesejados Evento notificações. 4.1.5.5 Significado de eventos ITIL V3 - Operação de Serviço - Página: 75 de 423
    • Cada organização terá sua própria categorização da importância de um evento, Mas sugere-se que pelo menos as seguintes três categorias amplas ser representado: • Informativo: Isto refere-se a um evento que não exige qualquer acção e não representa uma excepção. Eles são normalmente armazenados no sistema ou serviço arquivos de log e mantido por um período pré- determinado. Informativa eventos são normalmente utilizados para verificar o status de um dispositivo ou serviço, ou para confirmar a conclusão bem sucedida de uma atividade. Informativa eventos também podem ser usados para gerar estatísticas (tais como o número de usuários conectado a uma aplicação durante um certo período) e como entrada para investigações (como os trabalhos que concluída com êxito antes do transação fila de processamento pendurado). Exemplos de informação eventos incluem: • Um usuário faz logon em um aplicação • Um trabalho na fila de lote concluída com êxito • Um dispositivo está online • Uma transação é concluída com êxito. • Aviso: Um aviso é uma evento que é gerado quando um serviço ou dispositivo se aproxima de um limiar. Avisos destinam-se a notificar a pessoa adequada, processo ou ferramenta para que a situação pode ser verificada eo tomadas as medidas adequadas para prevento uma exceção. Advertências não são tipicamente criados para um dispositivo falha. Embora haja algum debate sobre se a falha de um dispositivo redundante é um aviso ou uma exceção (desde que o serviço ainda está disponível). Uma boa regra é que cada falha deve ser tratado como uma exceção, já que o risco de um incidente impactando o negócio é muito maior. Exemplos de avisos são: • Utilização de memória em um servidor é atualmente a 65% e crescente. Se atingir 75%, tempo de respostas será demasiadamente longo e OLA para o departamento será ultrapassado. • A taxa de colisão em uma rede aumentou 15% em relação a última hora. • Exceção: Uma excepção significa que um serviço ou dispositivo está operando de forma anormal (no entanto, que tenha sido definido). Tipicamente, isto significa que um e OLA SLA foram violados eo negócio está sendo afetado. Exceções podem representar um total falha, Funcionalidade prejudicada ou degradadas atuação. Observe, porém, que uma exceção nem sempre representa uma incidente. Por exemplo, uma exceção pode ser gerada quando um dispositivo não autorizado for detectado na rede. Isso pode ser gerenciado usando qualquer um Grave incidente ou um Requisição de Mudança (Ou mesmo ambas), de acordo com o organizaçãoIncidentes 's e Gestão da Mudança políticas. Exemplos de exceções incluem: ITIL V3 - Operação de Serviço - Página: 76 de 423
    • • Aservidor é baixo • O tempo de resposta de um padrão transação em toda a rede reduziu-se a mais de 15 segundos • Mais de 150 usuários ter conectado ao General Ledger aplicação concorrentemente • Um segmento da rede não está respondendo às solicitações de rotina. 4.1.5.6 correlação de eventos Se um evento é significativo, uma decisão tem de ser feita sobre o que exatamente é o significado e as ações que precisam ser tomadas para lidar com isso. É aqui que o significado do evento é determinado. Correlação é normalmente feito por um "Correlação Engine ', geralmente parte de uma ferramenta de gerenciamento que compara o evento com um conjunto de critérios e regras de uma ordem prescrita. Estes critérios são freqüentemente chamados de Regras de Negócios, embora eles geralmente são bastante técnico. A idéia é que o evento pode representar algum impacto sobre a actividade e as regras pode ser utilizado para determinar o nível e tipo de impacto comercial. Um mecanismo de correlação é programado de acordo com os padrões de desempenho criados durante Design de Serviços e qualquer orientação adicional específico para a operação ambiente. Exemplos do que mecanismos de correlação levará em conta incluem: • Número de eventos similares (por exemplo, esta é a terceira vez que o mesmo usuário tenha se conectado com a senha incorreta, um aplicativo de negócios relata que houve um padrão incomum de uso de um telefone móvel que poderia indicar que o dispositivo for perdido ou roubado) • Número de CIs gerando eventos semelhantes • Se uma acção específica está associada com o código de dados ou no caso • Se o evento representa uma excepção • Uma comparação das informações em caso de utilização com um padrão máximo ou mínimo (por exemplo, o dispositivo tem uma excedido limiar?) • Se os dados adicionais é necessário para investigar o evento ainda mais, e possivelmente até mesmo uma coleção de dados por solicitação de outro sistema ou banco de dados • Categorização do evento • A atribuição de um prioridade nível ao evento. 4.1.5.7 Gatilho ITIL V3 - Operação de Serviço - Página: 77 de 423
    • Se a correlação atividade reconhece um evento, A resposta será necessária. O mecanismo utilizado para iniciar a resposta, que é chamada de um gatilho. Existem muitos tipos diferentes de disparadores, cada um desenhado especificamente para a tarefa, tem de iniciar. Alguns exemplos incluem: • Incidente Gatilhos que geram uma registro no Gerenciamento de Incidentes sistema, Iniciando assim o Gerenciamento de Incidentes processo • Alterar gatilhos que geram uma Requisição de Mudança (RFC), iniciando assim a Gestão da Mudança processo • Um gatilho resultante de um RFC aprovado que tenha sido aplicada, mas fez com que o evento ou a partir de uma alteração não autorizada que tenha sido detectado - em qualquer dos casos, este será referido Change Management para investigação • Scripts que executam ações específicas, como enviar trabalhos de grupo ou reiniciar um dispositivo • Sistemas de paginação que irá notificar uma pessoa ou equipe do evento pelo telefone celular • Gatilhos de banco de dados que restringem o acesso de um usuário aos registros ou domínios específicos, ou que criar ou excluir entradas no banco de dados. 4.1.5.8 Resposta seleção Neste ponto do processo, há uma série de opções de respostas disponíveis. É importante notar que as opções de resposta pode ser escolhido em qualquer combinação. Por exemplo, pode ser necessário para manter a entrada de log para referência futura, mas, ao mesmo tempo aumentar o evento para uma Gestão de Operações membro da equipe para a ação. As opções no fluxograma são exemplos. Diferentes organizações terão opções diferentes, e têm a certeza de ser mais detalhada. Por exemplo, haverá uma gama de respostas auto para cada tecnologia diferente. O processo de determinar qual é apropriada e a forma de executar, não estão representados neste fluxograma. Algumas das opções disponíveis são: • Evento registrado: Independentemente do que atividade é realizado, é uma boa idéia ter um registro do evento e quaisquer ações subseqüentes. O evento pode ser registrado como um registro de eventos na Gestão de Eventos ferramenta, ou pode simplesmente ser deixada como uma entrada no registro do sistema do dispositivo ou aplicação que gerou o evento. Se este for o caso, porém, é preciso que haja uma ordem permanente para o pessoal adequado Gestão de Operações para verificar os registros em uma base regular e instruções claras sobre como utilizar cada log. Também deve ser lembrado que as informações do ITIL V3 - Operação de Serviço - Página: 78 de 423
    • evento nos logs podem não ser significativos até que um incidente ocorre, e onde o Gestão Técnica pessoal usar os logs para investigar onde o incidente originou. Isto significa que o evento de Gestão procedimentos para cada sistema ou a equipe precisa definir padrãos sobre como eventos longos são mantidos nos registros antes de serem arquivados e excluídos. • Resposta automática: Alguns eventos, são bem que a resposta adequada já foi definido e automatizado. Esta é, normalmente, como resultado da boa projeto ou da experiência anterior (geralmente Gerenciamento de Problemas). O gatilho irá iniciar a ação e, em seguida, avaliar se ela foi concluída com êxito. Se não, um incidente ou Grave problema será criada. Exemplos de respostas auto incluem: • Reiniciando um dispositivo • Reiniciando um serviço • Apresentar um trabalho em lote • A alteração do parâmetro em um dispositivo • Bloqueio de um dispositivo ou aplicação para protegê-lo contra o acesso não autorizado. Nota: bloqueio de um dispositivo pode resultar em negação de serviço autorizado usuários, que pode ser explorada por um atacante deliberada - cuidado tão grande deve ser tomado quando decidir se esta é uma ação apropriada automatizado. Se esta resposta for usado, ele pode ser prudente também combinar isso com uma chamar por intervenção humana, de modo que a acção automatizada pode ser prontamente verificado e aprovado. • Alertar e intervenção humana: Se o evento requer intervenção humana, que terá de ser escalado. O objetivo do alerta é para garantir que a pessoa com as competências adequadas para lidar com o evento é notificado. O alerta vai conter todas as informações necessárias para que a pessoa para determinar a ação apropriada - incluindo a referência a qualquer documentação necessária (manuais do usuário, por exemplo). É importante notar que este não é necessariamente o mesmo que o escalada funcional de um incidente, Onde a ênfase é sobre a restauração do serviço dentro de um prazo acordado (o que pode exigir uma variedade de atividades). O alerta requer uma pessoa, ou equipe, para executar uma ação específica, possivelmente em um dispositivo específico e, possivelmente, em um momento específico, por exemplo, trocar um cartucho de toner de uma impressora quando o nível está baixo. • Incidente,problema ou mudar? Alguns eventos representam uma situação em que a resposta adequada terá de ser tratado através do incidente, problema ou Gestão da Mudança processo. Estes são discutidos abaixo, mas é importante salientar que um único incidente pode dar início a qualquer um ou uma combinação destes três processos - por exemplo, ITIL V3 - Operação de Serviço - Página: 79 de 423
    • um não-crítico servidor falha é registrado como um incidente, mas como não há solução alternativa, Um Grave problema é criada para determinar o causa raiz e resolução e um RFC é logado para mudar o local da carga de trabalho para um servidor alternativo enquanto o problema é resolvido. • Abra uma RFC: Há dois lugares no processo de Gestão de Eventos, onde um RFC podem ser criados: • Quando ocorre uma exceção: Por exemplo, uma varredura de um segmento de rede revela que dois novos dispositivos foram adicionados sem a autorização necessária. Uma forma de lidar com esta situação é o de abrir um RFC, que pode ser usado como um veículo para o processo de gestão da mudança para lidar com a exceção (como uma alternativa para o método mais convencional de abertura de um incidente que seriam encaminhadas através do Service Desk ao Gerenciamento de Mudanças). Investigação pelo Gerenciamento de Mudanças é apropriado aqui desde alterações não autorizadas implicam que o processo de Gerenciamento de Mudança não foi eficaz. • Correlação identifica que um mudar é necessário: Neste caso, o evento correlação atividade determina que a resposta adequada a um evento é algo para ser mudado. Por exemplo, um atuação limiar tiver sido atingido, e um parâmetro de um servidor principal precisa de ser ajustado. Como a atividade correlação determinar isso? Foi programado para o fazer, quer no Design de Serviços processar ou porque isso já aconteceu antes e Gerenciamento de Problemas ou Gestão de Operações atualizou o Mecanismo de Correlação de tomar esta ação. • Abra uma Grave incidente: Tal como acontece com uma RFC, um incidente pode ser gerado imediatamente quando uma exceção é detectada, ou quando o motor de correlação determina que um tipo específico ou combinação de eventos representa um incidente. Quando um registro de incidentes é aberto, as informações, tanto quanto possível, deve ser incluído - com links para os eventos em questão e, se possível uma completa script de diagnóstico. • Abrir ou vincular a um Grave problema: É raro que um registro de problema a ser aberto sem incidentes relacionados (por exemplo, como resultado de um Análise de falha de serviço (Ver Design de Serviços publicação) ou maturidade avaliação, Ou por causa de um número elevado de tentativas rede erros, apesar de um falha ainda não ocorreu). Na maioria dos casos esta etapa refere-se à ligação de um incidente a um registro de problema existente. Isso vai ajudar a Gerenciamento de Problemas equipes para reavaliar a gravidade e impacto do problema, E pode resultar numa alteração prioridade a um problema de circulação. No entanto, é possível, com algumas das ferramentas mais sofisticadas, para avaliar o impacto dos incidentes e também para elevar um registro ITIL V3 - Operação de Serviço - Página: 80 de 423
    • de problema automaticamente, quando assim o permitam, para permitir a análise de causas básicas para começar imediatamente. • Tipos especiais de incidente: Em alguns casos, um evento irá indicar uma exceção que não impactam diretamente qualquer De serviços de TI, Por exemplo, uma unidade de condicionamento de ar redundante falha, ou a entrada não autorizada para um centro de dados. Diretrizs para estes acontecimentos são as seguintes: • Um incidente deve ser registrado usando um incidente Modelo que é adequado para o tipo de excepção, por exemplo, um incidente de Operações ou Segurança Incidente (ver parágrafo 4.2.4.2 para mais detalhes de Incidentes Modelos). • O incidente deve ser escalada para o grupo que gerencia esse tipo de incidente. • Como não há interrupção, o Modelo de Incidente usado deve reflectir que esta era uma operacional em vez de emitir uma serviço questão. As estatísticas não seria normalmente reportado para os clientes ou usuários, a menos que possam ser utilizados para demonstrar que o dinheiro investido em redundância foi um bom investimento. • Estes incidentes não devem ser utilizados para calcular tempo de inatividade, E pode de facto ser utilizado para demonstrar como proactiva TI tem sido tornar os serviços disponíveis. 4.1.5.9 Rever as acções Com milhares de eventos que estão sendo gerados a cada dia, não é possível formalmente rever cada evento individual. No entanto, é importante verificar que todos os eventos significativos ou exceções foram tratadas de forma adequada, ou para acompanhar as tendências ou contagens de tipos de eventos, etc Em muitos casos, isso pode ser feito automaticamente, por exemplo votação um servidor que havia sido reiniciado usando um script automático para ver se ele está funcionando corretamente. Nos casos em que os acontecimentos tenham iniciado o incidente, problema e / ou mudar, A revisão de Acção não deve duplicar quaisquer críticas que têm sido feitos como parte desses processos. Pelo contrário, a intenção é a de assegurar que a transição entre a Gestão de Eventos processo e outros processos ocorreu como projetado e que a ação esperada, de fato, ocorrer. Isso irá garantir que incidentes, problemas ou mudanças originadas dentro Gestão de Operações não se perder entre as equipes ou departamentos. O Comente também será utilizado como entrada para a melhoria contínua ea avaliação e auditar do Gestão de Eventos processo. 4.1.5.10 evento Close ITIL V3 - Operação de Serviço - Página: 81 de 423
    • Alguns eventos irá permanecer aberto até que uma certa acção tem lugar, por exemplo, um evento que é ligado a uma abertura incidente. No entanto, a maioria dos eventos não são 'abriu' ou 'fechado'. Eventos informativos são simplesmente registrados e então usado como entrada para outros processos, como backup e Storage Management. Auto-resposta eventos irá tipicamente ser fechada através da geração de um segundo evento. Por exemplo, um dispositivo gera um evento e é reiniciado através de resposta automática -, logo que o dispositivo é sucesso de volta online, ele gera um evento que efetivamente fecha o ciclo e limpa o primeiro evento. Às vezes é muito difícil relacionar o evento aberto e as notificações perto quanto eles são em diferentes formatos. É ideal que os dispositivos na infra-estrutura produzir eventos "abertos" e "fechar" no mesmo formato e especificar a mudança de status. Isto permite que o passo de correlação no processo de facilmente adaptar as notificações de abrir e fechar. No caso de eventos que geraram um incidente, problema ou mudar, Estes devem ser formalmente encerrada com um link para o adequado registro a partir de outro processo. 4.1.6 Triggers interfaces de entrada e saída / inter-processo Gestão de Eventos pode ser iniciado por qualquer tipo de ocorrência. A chave é definir qual dessas ocorrências é importante e que precisa ser colocada em prática. Gatilhos incluem: • Exceções a qualquer nível de CI atuação definido na projeto especificaçãos, OLAs ou SOPs • As exceções a um sistema automatizado procedimento ou um processo, por exemplo, uma rotina mudar que tem sido atribuída a um construir equipe não foi concluído a tempo • Uma excepção a uma processo de negócio que está sendo monitorado pela Gerência de Eventos • A conclusão de uma tarefa ou trabalho automatizado • Aestado mudar em um dispositivo ou registro de dados • Acesso de um aplicação ou banco de dados por um usuário ou procedimento automatizado ou trabalho • Uma situação em que um dispositivo de banco de dados ou aplicações, etc atingiu um predefinido limiar de desempenho. Gestão de Eventos pode fazer interface com qualquer processo que requer monitoramento e controlar, Especialmente aqueles que não necessitam de monitorização em tempo real, mas que exigem alguma forma de intervenção após um evento ou grupo de eventos. Exemplos de interfaces com outros processos incluem: ITIL V3 - Operação de Serviço - Página: 82 de 423
    • • Interface com aplicações de negócio e / ou processos de negócios para permitir que eventos de negócios potencialmente importantes a serem detectadas e corrigidas (por exemplo, um aplicativo de negócios relata anormal atividade num clienteO relato de que podem indicar algum tipo de fraude ou segurança violação). • O principal ITSM relaçãos são com Incidente, Problema e Gerenciamento de Mudanças. Estas interfaces são descritas com algum pormenor no ponto 4.1.5.8. • Capacidade e Gerenciamento de Disponibilidade são fundamentais na definição do que eventos são significativos, o que adequado limiars deve ser e como responder a eles. Em troca, Gestão de Eventos melhorará a atuação e disponibilidade de serviços por responder a eventos quando eles ocorrem e, relatando acontecimentos reais e padrões de eventos para determinar (por comparação com as metas de SLA e KPIs) se houver algum aspecto da infra-estrutura projeto ou operação que pode ser melhorado. • Gerenciamento da Configuração é capaz de usar os eventos para determinar o status atual de qualquer IC na infra-estrutura. Comparando eventos com o autorizado linha de bases no Sistema de Gerenciamento da Configuração (CMS) vai ajudar a determinar se existe não autorizada Mudar atividade a ter lugar no organização (Ver Transição de Serviço publicação). • Gestão de Ativos (Coberto com mais detalhes no Design de Serviços e publicações de transição) pode usar o Gerenciamento de eventos para determinar o ciclo de vida estado de ativoss. Por exemplo, um evento pode ser gerado para indicar que um novo activo foi configurado com sucesso e é agora operacional. • Os eventos podem ser uma fonte rica de informações que podem ser processados para inclusão em Gestão do Conhecimento sistemas. Por exemplo, os padrões de desempenho pode ser correlacionada com a actividade e utilizado como entrada para futura concepção e estratégia decisões. • Gestão de eventos podem desempenhar um importante papel no sentido de garantir que o potencial impacto em SLAs é detectado precocemente e qualquer falhas são rectificadas, logo que possível, de modo que o impacto na serviço alvos é minimizado. 4.1.7 Gestão da Informação Informações-chave envolvidos em Gestão de Eventos inclui o seguinte: • Mensagens SNMP, que são uma forma padrão de comunicar informação técnica sobre o estado de componentes de um Infraestrutura de TI. • Gestão da Informação Bases (MIBs) de dispositivos de TI. Uma MIB é o banco de dados em cada dispositivo que contém informações sobre o dispositivo, incluindo o seu sistema operacional, o BIOS ITIL V3 - Operação de Serviço - Página: 83 de 423
    • versão,configuração dos parâmetros do sistema, etc A capacidade de interrogar MIBs e compará-los a uma norma é fundamental para ser capaz de gerar eventos. • Vendedor monitoramento ferramentas de software agente. • Motores de correlação conter regras para determinar o significado ea resposta apropriada aos eventos. Detalhes sobre este são fornecidos no parágrafo 4.1.5.6. • Não há eventos padrão Registro para todos os tipos de evento. O conteúdo exato e formato do registro dependem das ferramentas que estão sendo usadas, o que está sendo monitorado (por exemplo, um servidor e a Gestão da Mudança ferramentas terá dados muito diferentes e, provavelmente, usar um formato diferente). No entanto, existem alguns dados-chave que é normalmente exigido em cada evento para ser útil em análise. Deve incluem tipicamente o: • Dispositivo • Componente • Tipo de falha • Data / hora • Parâmetros em exceção • Valor. 4.1.8 Métricas Para cada período de medição em questão, o métricos para verificar o eficácia e eficiência do Gestão de Eventos processo deve incluir o seguinte: • Número de eventos por categoria • Número de eventos por significado • Número e porcentagem de eventos que necessitaram de intervenção humana e se esta foi realizada • Número e porcentagem de eventos que resultou em incidentes ou mudanças • Número e porcentagem de eventos provocados por existir problemas ou erros conhecidos. Isto pode resultar numa alteração na prioridade de trabalho em que o problema ou Erro Conhecido • Número e porcentagem de eventos repetidos ou duplicados. Isso vai ajudar na afinação do Mecanismo de Correlação de eliminar a geração de eventos desnecessário e pode também ser utilizada para auxiliar no projeto de melhor funcionalidade evento geração em novos serviços • Número e porcentagem de eventos indicando atuação problemas (por exemplo, o crescimento do número de vezes que um aplicação excedeu a sua transação limiars nos últimos seis meses) • Número e porcentagem de eventos indicando potencial disponibilidade questões (failovers por exemplo, para dispositivos alternativos, ou excessivo carga de trabalho swapping) • Número e percentual de cada tipo de evento por plataforma ou aplicação ITIL V3 - Operação de Serviço - Página: 84 de 423
    • • Número e proporção de eventos em comparação com o número de incidentes. 4.1.9 Desafios, Fatores Críticos de Sucesso e riscos 4.1.9.1 Desafios Há um número de desafios que podem ser encontrados: • Um desafio inicial pode ser a obtenção de financiamento para as ferramentas necessárias e esforço necessários para instalar e explorar os benefícios das ferramentas. • Um dos maiores desafios é definir o nível correto de filtragem. Definir o nível de filtragem incorretamente pode resultar em um ser inundado com relativamente insignificante eventos, ou não ser capaz de detectar eventos relativamente importantes, até que seja tarde demais. • A implantação do necessário monitoramento agentes em toda a infraestrutura de TI inteira pode ser uma tarefa difícil e demorada atividade exigindo um compromisso contínuo por um longo período de tempo - há um perigo de que as atividades podem surgir outras que poderiam desviar recursos e atrasar o lançamento. • Adquirir as habilidades necessárias pode ser demorado e caro. 4.1.9.2 Fatores Críticos de Sucesso A fim de obter o financiamento necessário um Business Case convincente deve ser preparado mostrando como os benefícios da efetiva Gestão de Eventos podem ultrapassar de longe a custars - dando um retorno positivo sobre o investimento. Um dos mais importantes é QCA atingir o nível correto de filtragem. Isto é complicado pelo facto de a importância das alterações eventos. Por exemplo, um usuário login em um sistema hoje é normal, mas se o usuário deixa o organização e tenta entrar é uma segurança violação. Há três chaves para o nível correcto de filtragem, da seguinte forma: • Integrar a Gestão de evento em toda a Serviço de Gestão de processos sempre que possível. Isto assegurará que apenas os eventos significativos para estes processos são descritos. • Concepção de novos serviços com Gestão de Eventos em mente (isto é discutido em detalhes no parágrafo 4.1.10). • Tentativa e erro. Não importa o quão completamente Gestão de Eventos é preparado, haverá aulas de eventos que não são devidamente filtrados. Gestão de Eventos deve, portanto, incluir um formal processo para avaliar a eficácia de filtragem. ITIL V3 - Operação de Serviço - Página: 85 de 423
    • Adequado planejamento é necessário para a distribuição do software do agente de monitoramento em toda a infra-estrutura de TI inteiro. Isto deve ser considerado como um projeto com prazos realistas e recursos adequados sendo alocado e protegidos durante todo o período de duração do projeto. 4.1.9.3 Riscos A chave riscos são realmente os já mencionados acima: a incapacidade de obter financiamento adequado, garantindo o nível correto de filtragem, ea falha para manter a dinâmica na implementação de agentes de controlo necessárias em todo o Infraestrutura de TI. Se algum destes riscos não são os destinatários que poderia adversamente impacto sobre o sucesso da Gestão de Eventos. 4.1.10 Projeto de Gestão de Eventos Gestão de Eventos eficaz não é projetado, uma vez por serviço foi implantado em Operações. Desde Gestão de Eventos é a base para o acompanhamento da atuação e disponibilidade de um serviço, as metas exatas e mecanismos de monitoramento devem ser especificadas e acordadas durante a disponibilidade e Gerenciamento da Capacidade processos (ver Design de Serviços publicação). No entanto, isso não significa que a Gestão de Eventos foi projetado por um grupo de controle remoto sistema desenvolvedores e, em seguida, liberado para Gestão de Operações juntamente com o sistema que tem de ser gerida. Também não quer dizer que, uma vez desenvolvido e acordado, Gestão de Eventos se torna estática - dia-a-dia operaçãos vai definir adicional eventos, prioridades, alertars e outras melhorias que irão alimentar através da Melhoria Contínua processo volta Estratégia de Serviço,Design de Serviços etc Operação de Serviço funçãos deverão participar na projeto do serviço e como ela é medida (ver secção 3.4). Para Gestão de Eventos, As áreas de concepção específicos incluem o seguinte. 4.1.10.1 Instrumentação Instrumentação é a definição do que pode ser monitorado sobre CIs e da maneira em que o seu comportamento pode ser afetado. Em outras palavras, a instrumentação é sobre como definir e projetar exatamente como monitorar e controlar o Infraestrutura de TI e De serviços de TIs. Instrumentação é parte de um conjunto de decisões que precisam ser feitas e, em parte, sobre a criação de mecanismos para executar essas decisões. Decisões que precisam ser tomadas incluem: ITIL V3 - Operação de Serviço - Página: 86 de 423
    • • O que precisa ser monitorado? • Que tipo de acompanhamento é necessária (por exemplo, ativa ou passiva; atuação ou saída)? • Quando precisamos de gerar um evento? • Que tipo de informação deve ser comunicada no evento? • Quem são as mensagens destinados? Mecanismos que precisam ser projetados incluem: • Como os eventos ser gerados? • O IC já tem mecanismos de geração de eventos como um recurso padrão e, em caso afirmativo, qual destes será utilizado? São suficientes ou não o CI precisa ser personalizado para incluir mecanismos adicionais ou informações? • Os dados que serão usados para preencher o Evento Registro? • São eventos gerados automaticamente ou se o CI tem que ser buscado? • Onde vai ser eventos registrados e armazenados? • Como os dados complementares ser recolhidas? Nota: Uma interface forte existe aqui com o aplicação'S design. Todas as aplicações devem ser codificadas de tal maneira que significativa e detalhado erro mensagens / códigos são gerados no ponto exato de falha - De modo que estes podem ser incluídos no evento e permitir rápida diagnóstico e resolução da causa subjacente. A necessidade da inclusão e teste de mensagens de erro do tipo é descrita em mais detalhe no Transição de Serviço publicação. 4.1.10.2 mensagens de erro Mensagens de erro é importante para todos componentes (hardware, software, redes, etc.) É particularmente importante que todos os aplicativos são projetados para suportar Gestão de Eventos. Isso pode incluir o fornecimento de mensagens de erro significativo e / ou códigos que indicam claramente o ponto específico de falha ea causa mais provável. Em tais casos, o teste de novo aplicaçãos deve incluir o teste de precisão evento geração. Novas tecnologias como Java Management Extensions (JMX) ou HawkNL ™ fornecer as ferramentas para a construção de distribuídos, baseados na web, soluções modulares e dinâmica para a gestão e monitoramento dispositivos, aplicações e serviçoOrientados por redes. Estes podem ser usados para reduzir ou eliminar a necessidade de os programadores para incluir erro mensagens dentro do código - permitindo um nível importante de normalização e de código- independência. 4.1.10.3 de detecção de eventos e mecanismos de alerta ITIL V3 - Operação de Serviço - Página: 87 de 423
    • Bom Gestão de Eventos projeto também incluem a concepção e população das ferramentas utilizadas para filtrar, correlacionar e escalar Eventos. O Mecanismo de Correlação especificamente terá de ser preenchido com as regras e critérios que irão determinar o significado e subseqüente ação para cada tipo de evento. Projeto completo do evento detecção e alertar mecanismos requer o seguinte: • Conhecimento do negócio em relação para qualquer processo de negócioes a ser gerido através de Gestão de Eventos • Conhecimento detalhado do Exigência de Nível de Serviços do serviço a ser suportado por cada CI • Conhecimento de quem vai ser o apoio à CI • Conhecimento do que constitui normal e anormal operação da CI • Conhecimento do significado de vários eventos semelhantes (na CI mesmo ou semelhante vários CIs • Uma compreensão do que eles precisam saber para apoiar o CI efetivamente • Informações que podem ajudar na diagnóstico de problemas com o CI • Familiaridade com incidente códigos de prioridade e categorização de modo que, se é necessário criar um Grave incidente, Esses códigos podem ser fornecidos • O conhecimento de outros CIs que pode ser dependente da CI afectado, ou os IC da qual depende • Disponibilidade de Erro Conhecido informações de fornecedores ou de experiência anterior. 4.1.10.4 Identificação de limiares Limiars mesmos não estão definidos e gerenciados através de Gerenciamento de Eventos. No entanto, a menos que estas sejam devidamente projetado e comunicado durante a instrumentação processo, Será difícil determinar qual o nível de atuação é apropriada para cada IC. Além disso, a maioria dos limiares não são constantes. Eles consistem tipicamente de uma série de variáveis relacionadas. Por exemplo, o número máximo de concorrentes usuários antes tempo de resposta retarda vai variar dependendo do que outros trabalhos estão ativos no servidor. Este conhecimento é muitas vezes só ganhou por experiência, o que significa que os motores de correlação tem que ser continuamente atento e atualizado através do processo de Melhoria de Serviço Continuada. ITIL V3 - Operação de Serviço - Página: 88 de 423
    • 4.2 Gestão de Incidentes Em ITIL terminologia, um 'incidente'É definido como: Uma interrupção não planejada a um De serviços de TI ou redução do qualidade de um serviço de TI. Falha de um item de configuração que ainda não tenha impacto serviço É também um incidente, por exemplo falha de um disco a partir de um conjunto de espelho. Gerenciamento de Incidentes é o processo para lidar com todos os incidentes, o que pode incluir falhas, perguntas ou perguntas relatados pela usuários (usualmente através de um telefone chamar ao Service Desk), Pela equipe técnica, ou automaticamente detectado e reportado pelo evento monitoramento ferramentas. 4.2.1 Finalidade objetivo / / objetivo O principal objetivo do processo de Gerenciamento de Incidentes é restaurar normal operação de serviço o mais rapidamente possível e minimizar os efeitos adversos impacto em operações comerciais, Garantindo assim que os melhores níveis possíveis de qualidade de serviço e disponibilidade são mantidos. 'Operação de serviço Normal' é definida aqui como operação de serviço dentro SLA limites. 4.2.2 Âmbito Gerenciamento de Incidentes inclui qualquer evento que perturbe, ou o que poderia interromper, um serviço. Isso inclui eventos que são comunicados diretamente pelos usuários, seja por meio da Central de Serviços ou através de uma interface de Gestão de Eventos a ferramentas de gerenciamento de incidentes. Os incidentes podem também ser comunicados e / ou registrados pela equipe técnica (se, por exemplo, eles percebem algo desagradável com um hardware ou rede componente eles podem denunciar ou fazer um incidente e remetê-lo para o Posto de Serviço). Isso não significa, entretanto, que todos os eventos são incidentes. Muitas classes de eventos não estão relacionados a interrupções em tudo, mas são indicadores de operação normal ou são simplesmente informativa (ver secção 4.1). Embora ambos os incidentes e solicitação de serviços são relatados para o Service Desk, isso não significa que eles são os mesmos. Solicitações de serviço não representam uma interrupção do serviço acordado, mas são uma maneira de atender a cliente'S precisa e pode ser uma abordagem meta acordada em um SLA. Solicitações de serviços são tratados pelo Cumprimento de Requisição processo (ver secção 4.3). ITIL V3 - Operação de Serviço - Página: 89 de 423
    • 4.2.3 Valor para os negócios O valor do Gerenciamento de Incidentes inclui: • A capacidade de detectar e resolver incidentes o que resulta em menor tempo de inatividade para o negócio, o que por sua vez significa uma maior disponibilidade do serviço. Isto significa que a actividade é capaz de explorar a funcionalidade do serviço, como desenhado. • A capacidade de alinhar a TI atividade às prioridades comerciais em tempo real. Isto é porque Gerenciamento de Incidentes inclui a capacidade de identificar as prioridades de negócios e alocar dinamicamente recursos conforme necessário. • A capacidade de identificar potenciais melhorias aos serviços. Isto acontece como resultado da compreensão do que constitui um incidente e também de estar em contacto com as actividades de negócio operacional pessoal. • O Service Desk pode, durante seu tratamento de incidentes, identificar adicional serviço ou formação exigências encontradas em TI ou o negócio. Gerenciamento de Incidentes é altamente visível para o negócio, e por isso é mais fácil de demonstrar o seu valor do que a maioria das áreas em Operação de Serviço. Por esta razão, Gerenciamento de Incidentes é muitas vezes um dos primeiros processos a serem implementadas em Serviço de Gestão de projetos. A vantagem de fazer isso é que Gerenciamento de Incidentes pode ser usado para destacar outras áreas que precisam de atenção - proporcionando assim uma justificativa para as despesas com a implementação de outros processos. 4.2.4 Políticas / princípios / conceitos básicos Há algumas coisas básicas que precisam ser levados em conta quando se considera e decidiu Gerenciamento de Incidentes. Estes são tratados nesta seção. 4.2.4.1 Prazos Prazos deve ser aprovada para todas as fases de tratamento de incidente (estes irão diferir dependendo da prioridade nível do incidente) - com base na resposta global e incidente resolução alvos dentro de SLAs - e capturados como alvos dentro Olas e Subjacente Contratos (UCs). Todos grupo de apoios deve ser plenamente consciente destes prazos. As ferramentas de gerenciamento de serviços devem ser usadas para automatizar prazos e aumentar o incidente como necessário com base na regras pré-definidas. 4.2.4.2 Modelos de Incidentes ITIL V3 - Operação de Serviço - Página: 90 de 423
    • Muitos incidentes não são novos - eles envolvem lidar com algo que já aconteceu antes e pode acontecer de novo. Por esta razão, muitas organizações vai encontrá-lo útil para pré-definir Incident 'padrão' Modelos - e aplicá-los aos incidentes adequadas quando eles ocorrem. Um modelo de Incidentes é uma forma de pré-definir os passos que devem ser tomadas para lidar com uma processo (Neste caso, um processo para tratar um tipo particular de incidente) de uma forma acordado. Ferramentas de suporte pode então ser utilizado para administrar o processo desejado. Isso irá garantir que 'padrão' incidentes são tratados em um caminho pré-definido e dentro de prazos pré-definidos. Incidentes que requerem um tratamento especializado pode ser tratada desta forma (por exemplo, segurançaIncidentes relacionados podem ser encaminhadas para Gestão de Segurança da Informação e capacidade- Ou atuaçãoIncidentes relacionados que seriam encaminhadas para Gerenciamento da Capacidade. O Modelo de Incidente deve incluir: • Os passos que devem ser tomadas para lidar com o incidente • A ordem cronológica estas etapas devem ser tomadas, com quaisquer dependências ou co-processamento definidos • Responsabilidades; quem deve fazer o que • Prazos e limiars para a conclusão das ações • Escalada procedimentos; que deve ser contactado e quando • Qualquer necessárias evidências de preservação de atividades (particularmente relevante para segurança- E capacidadeRelacionada incidentes). O modelos deve ser entrada para as ferramentas de manipulação de incidente de suporte a ser utilizado e, em seguida, as ferramentas devem automatizar o tratamento, gestão e escalada do processo. 4.2.4.3 grandes incidentes Um separado procedimento, Com prazos mais curtos e maiores urgência, Deve ser utilizado para 'principais' incidentes. A definição do que constitui um incidente grave deve ser acordado e, idealmente, mapeado para a priorização incidente geral sistema - De tal forma que eles serão tratados através do incidente de grandes proporções processo. Nota: As pessoas às vezes usam terminologia solta e / ou confundir um incidente grave com uma problema. Na realidade, um incidente continua a ser um incidente para sempre - pode crescer em impacto ou prioridade para se tornar um grande incidente, mas um incidente nunca 'se torna' um problema. Um ITIL V3 - Operação de Serviço - Página: 91 de 423
    • problema é a causa subjacente de um ou mais incidentes e continua a ser uma entidade separada sempre! Alguns incidentes menor prioridade também pode ter de ser tratado por este processo - devido ao impacto potencial - e algumas grandes incidentes pode não precisar de ser tratada desta forma, se a causa e resoluçãos são óbvias e do processo de incidente normal pode facilmente lidar dentro da meta acordada resolução vezes - desde que o impacto é baixo! Sempre que necessário, o procedimento de incidente grave deve incluir o estabelecimento dinâmico de uma equipe grande incidente separado, sob a liderança direta do Gerente de Incidentes, formulada para se concentrar sobre este incidente só para garantir que adequada recursos e foco são fornecidos para encontrar uma solução rápida. Se o Service Desk Gerente também é o cumprimento da papel do Gerente de Incidentes (digamos em um pequeno organização), Então uma pessoa separada pode precisar de ser designado para liderar a equipa de investigação principal incidente -, de modo a evitar o conflito de tempo ou prioridades - mas, em última análise deve informar o Gerente de Incidentes. Se a causa do incidente tem de ser investigada, ao mesmo tempo, então o Gestor de Problemas estaria envolvido bem mas o Gestor de Incidentes deve assegurar que serviço restauração e causa subjacente são mantidos separados. Durante todo, o Service Desk seria garantir que todas as atividades são registradas e usuários sejam plenamente informados do progresso. 4.2.5 As atividades de processo, métodos e técnicas O processo a ser seguido durante a gestão de um incidente é mostrado na figura 4.2. O processo inclui as seguintes etapas. ITIL V3 - Operação de Serviço - Página: 92 de 423
    • Figura 4.2 Incidente de fluxo de processo de Gestão de 4.2.5.1 identificação de incidentes ITIL V3 - Operação de Serviço - Página: 93 de 423
    • Trabalho não pode começar a lidar com um incidente até que seja conhecido que um incidente. É geralmente inaceitável, a partir de um perspectiva de negócios, Esperar até que um usuário é impactado e os contatos do Service Desk. Na medida do possível, todas as chaves componentes devem ser monitoradas para que falhas ou potenciais falhas são detectadas cedo para que a Gerenciamento de Incidentes processo pode ser iniciado rapidamente. Idealmente, os incidentes devem ser resolvidos antes que eles tenham um impacto sobre os usuários! Por favor, consulte a secção 4.1 para mais detalhes. 4.2.5.2 registro de incidentes Todos incidentes deve ser totalmente registradas e data / hora marcada, independentemente de eles são criados através de um Service Desk telefone chamar ou se detectada automaticamente através de um evento alertar. Nota: Se o Service Desk e / ou pessoal de apoio visitar o clientes para lidar com um incidente, eles podem ser convidados para lidar com novos incidentes ", enquanto eles estão lá". É importante que, se isso for feito, uma separada Grave incidente é registrado para cada incidente adicional tratado - para garantir que uma histórica registro é mantido e crédito é dado para o trabalho realizado. Toda a informação relevante sobre a natureza do incidente devem ser registrados, de forma que um registro histórico completo é mantida - e de modo que se o incidente tem de ser encaminhado para outro grupo de apoio(S), que terá todas as informações relevantes para a mão para ajudá-los. A informação necessária para cada incidente é provável que inclua: • Número de referência único • Categorização incidente (muitas vezes dividido em entre dois e quatro níveis de sub-categorias) • Incidente urgência • Incidente impacto • Priorização incidente • Data / hora da gravação • Nome / ID da pessoa e / ou grupo a gravação do incidente • Método de notificação (telefone, automático, e-mail, pessoalmente, etc) • Nome do departamento / / telefone / localização de usuário • Call-back método (e-mail, telefone, etc) • A descrição dos sintomas • Incidente estado (Ativo, esperando, fechado, Etc) • Relacionado CI • Grupo de apoio / pessoa para a qual o incidente é alocado • Relacionado problema/Erro Conhecido ITIL V3 - Operação de Serviço - Página: 94 de 423
    • • Atividades realizadas para resolver o incidente • Resolução data e hora • Fecho categoria • Data e hora de encerramento. Nota: Se o Service Desk não funcionar 24/7 e responsabilidade de primeira linha incidente registro e manipulação de passes para outro grupo, como Operações de TI ou suporte de rede, fora do horário de Service Desk, em seguida, estes funcionários precisam estar igualmente rigorosa sobre o registro de detalhes do incidente. Formação integral e consciência tem de ser fornecida para esse pessoal sobre esta questão. 4.2.5.3 categorização de incidentes Parte do registro inicial deve ser adequado para alocar incidente categorização de codificação para que o tipo exato do chamar é gravada. Isto será importante mais tarde quando se olha para tipos de incidentes / freqüências para estabelecer tendências para o uso em Gerenciamento de Problemas,Gestão de Fornecedores e outras atividades de ITSM. Por favor, note que a seleção para Solicitação de Serviços neste processo não implica que Solicitações de serviços são incidentes. Este é simplesmente o reconhecimento do fato de que solicitações de serviço são, por vezes incorretamente registrada como incidentes (por exemplo, um usuário incorretamente entra o pedido como incidente a partir da interface web). Esta verificação será detectar tais solicitações e garantir que eles são passados para o Cumprimento de Requisição processo. Multi-nível categorização está disponível na maioria das ferramentas - geralmente a três ou quatro níveis de complexidade. Por exemplo, um incidente podem ser categorizados como mostrado na Figura 4.3. ITIL V3 - Operação de Serviço - Página: 95 de 423
    • Figura 4.3 categorização incidente Multi-nível Todas as organizações são únicos e, portanto, é difícil dar uma orientação genérica sobre as categorias de organização Deve usar-se, em especial aos níveis mais baixos. No entanto, não é uma técnica que pode ser usada para ajudar a alcançar uma organização de um conjunto completo e correcto das categorias - caso se parte do zero! Os passos envolvem: 1. Segure um de brainstorming sessão entre o relevante grupo de apoios, envolvendo a Autoridade SD e gestores de incidentes e problemas. 2. Use esta sessão para decidir o "melhor palpite" categorias de nível superior - e incluir um 'outro' categoria. Configurar as ferramentas relevantes de registro para usar essas categorias por um período experimental. 3. Use as categorias por um período experimental de curta duração (tempo suficiente para que várias centenas de incidentes a cair em cada categoria, mas não muito tempo que uma análise vai demorar muito tempo para executar). 4. Faça uma análise dos incidentes registrados durante o período experimental. O número de incidentes registrados em cada categoria de nível superior irá confirmar se as categorias valem a pena - e uma análise ITIL V3 - Operação de Serviço - Página: 96 de 423
    • mais detalhada da categoria "outros" deve permitir a identificação de quaisquer adicionais de nível superior categorias que serão necessários. 5. Uma análise de distribuição dos incidentes em cada categoria de nível mais alto deve ser usado para determinar as categorias de nível inferior que serão necessárias. 6. Comente e repetir estas actividades após um período adicional - de, digamos, um a três meses - e novamente regularmente para garantir que eles permaneçam relevantes. Esteja ciente de que quaisquer mudanças significativas para categorização pode causar algumas dificuldades para comunicação de incidentes de tendências ou de gestão - então eles devem ser estabilizados, a menos que as mudanças são realmente necessárias. Se um esquema de categorização existente está em uso, mas não é pensado de forma satisfatória, a idéia básica da técnica sugerida acima pode ser usado para rever e alterar o regime existente. NOTA: Às vezes, as informações disponíveis no momento de um incidente é registrado pode ser incompleto, enganosas ou incorretas. Portanto, é importante que a categorização do incidente é verificada e atualizada, se necessário, no momento da chamada de encerramento (em separado fecho campo de categorização, de forma a não danificar a categorização original) - consulte o parágrafo 4.2.5.9. 4.2.5.4 priorização de Incidentes Outro aspecto importante de registrar todos os incidente é concordar e alocar um código de priorização apropriada - como isso vai determinar como o incidente é tratado tanto por ferramentas de apoio e pessoal de apoio. Priorização pode normalmente ser determinado tendo em conta tanto o urgência do incidente (o quão rápido a empresa precisa de um resolução) E o nível de impacto que está causando. Uma indicação do impacto é frequentemente (mas não sempre) o número de usuárioestá sendo afetado. Em alguns casos, e muito importante, a perda de serviço para um único usuário pode ter um impacto grande negócio - tudo depende de quem está tentando fazer o que - para os números por si só não é suficiente para avaliar global prioridade! Outros fatores que também podem contribuir para os níveis de impacto são: • Risco para a vida ou saúde • O número de serviços afectados - pode ser de vários serviços • O nível das perdas financeiras • Efeito sobre reputação empresarial • Brechas regulatórias ou legislativas. ITIL V3 - Operação de Serviço - Página: 97 de 423
    • Uma forma eficaz de cálculo destes elementos e derivando um nível de prioridade geral para cada incidente é dado na Tabela 4.1: Impacto Alto Médio Baixo Alto 1 2 3 Urgência Médio 2 3 4 Baixo 3 4 5 Código de prioridade Descrição Tempo de resolução alvo 1 Crítico 1 hora 2 Alto 8 horas 3 Médio 24 horas 4 Baixo 48 horas 5 Planejamento Planejado Tabela 4.1 sistema de prioridades simples codificação Em todos os casos, orientação clara - com exemplos práticos - deve ser fornecida para todo o pessoal de apoio que lhes permitam determinar a urgência correta e níveis de impacto, então a prioridade correta é alocado. Tais orientações devem ser produzidos durante nível de serviço negociações. No entanto, deve notar-se que haverá ocasiões em que, por causa da oportunidade de negócio particular ou o que quer, os níveis de prioridade normal tem que ser substituído. Quando um usuário está convencido de que o nível de prioridade de um incidente deve exceder normais diretrizs, o Service Desk devem cumprir tal pedido - e que, posteriormente passa a ser incorreta isso pode ser resolvido como um problema de nível off-line de gestão, em vez de uma disputa que ocorre quando o usuário está usando o telefone. Algumas organizações podem também reconhecer VIPs (altos executivos, funcionários, diplomatas, políticos, etc), cujos incidentes seriam tratados em um maior prioridade do que o normal - mas, nesses casos, este é o melhor servidos e documentado dentro do guidance fornecido ao Service Desk pessoal sobre como aplicar os níveis de prioridade, por isso são todos conscientes das regras acordadas para VIPs, e que cai nesta categoria. Deve notar-se que um incidentePrioridade 's pode ser dinâmico - se as circunstâncias mudarem, ou se um incidente não for resolvida dentro SLA vezes alvo, em seguida, a prioridade deve ser alterado para refletir a nova situação. ITIL V3 - Operação de Serviço - Página: 98 de 423
    • Nota: algumas ferramentas podem ter restrições que dificultam automaticamente para calcular atuação contra SLA alvos se uma prioridade é alterado durante o tempo de vida de um incidente. No entanto, se as circunstâncias mudam, a mudança de prioridade deve ser feito - e, se necessário ajustes manuais feitos para ferramentas de relatórios. Idealmente, as ferramentas com tais restrições não devem ser selecionados. 4.2.5.5 O diagnóstico inicial Se o incidente foi encaminhado através do Service Desk, o Analista de Service Desk deve realizar inicial diagnóstico, Tipicamente enquanto o usuário ainda está no telefone - se o chamar é levantada desta maneira - para tentar descobrir todos os sintomas do incidente e determinar exatamente o que deu errado e como corrigi-lo. É nesta fase que script de diagnósticos e erro conhecido informação pode ser mais valiosa do que permite o diagnóstico precoce e preciso. Se possível, o Analista de Service Desk vai resolver o incidente, enquanto o usuário ainda está no telefone - e fechar o incidente se o resolução é bem sucedida. Se o Analista de Service Desk não pode resolver o incidente, enquanto o usuário ainda está no telefone, mas há uma perspectiva de que o Service Desk pode ser capaz de fazê-lo no prazo acordado sem a ajuda de outra grupo de apoios, o analista deve informar o utilizador sobre as suas intenções, dar ao usuário o número de referência incidente e tentar encontrar uma solução. 4.2.5.6 escalada de incidentes • Escalada funcional. Tão logo torna-se claro que o Service Desk é incapaz de resolver o incidente em si (ou quando os tempos alvo para primeiro- ponto resolução foram ultrapassados -! Que ocorrer primeiro), o incidente deve ser imediatamente encaminhado para um apoio adicional. Se o organização tem um grupo de apoio de segundo nível e Service Desk acredita que o incidente pode ser resolvido por esse grupo, deve referir-se o incidente para eles. Se é óbvio que o incidente terá mais profundo conhecimento técnico - ou quando o grupo de segundo nível, não tem sido capaz de resolver o incidente dentro de vezes acordado (o que ocorrer primeiro), o incidente deve ser imediatamente encaminhado para o terceiro adequado nível apoiar grupo. Observe que os grupos de terceiro nível de suporte podem ser internos - mas eles também podem ser terceiros, tais como software fornecedors ou hardware fabricantes ou mantenedores. As regras para a escalada e tratamento de incidentes devem ser acordados na Olas e UCs com grupos de apoio interno e externo, respectivamente. ITIL V3 - Operação de Serviço - Página: 99 de 423
    • Nota: Propriedade de Incidentes permanece com o Service Desk! Independentemente de onde um incidente é referido durante a sua vida, a propriedade do incidente permanece com o Service Desk em todos os momentos. O Service Desk permanece responsável pelo controle do progresso, mantendo os usuários informados e, finalmente, para a Incidentes Fecho. • Escalada hierárquica. Se os incidentes são de natureza grave (por exemplo Prioridade 1 incidentes), os gerentes de TI apropriadas deve ser notificado, para fins informativos, pelo menos. Escalada hierárquica também é utilizado se a investigação "e Diagnóstico'E'Resolução e Recuperação'Passos estão demorando muito ou provando muito difícil. Hierárquica escalada devem continuar até a cadeia de gestão para que os gerentes seniores estão conscientes e podem ser preparadas e tomar as medidas necessárias, tais como alocação adicional recursos ou envolvendo fornecedors / mantenedores. Escalada hierárquica também é usado quando há disputa sobre a quem o incidente é alocado. Escalada hierárquica pode, naturalmente, ser iniciada pelo afectada usuários ou cliente gestão, como entenderem - é por isso que é importante que os gerentes de TI estão cientes, para que possam prever e preparar-se para qualquer escalada tal. Os níveis exatos e prazos para escalonamento funcional e hierárquica precisa ser aprovada, tendo em conta SLA alvos, e incorporados em ferramentas de apoio, que podem então ser usados para polícia e controlar o fluxo do processo dentro de prazos acordados. O Service Desk deve manter o usuário informado de qualquer escalada relevante que tem lugar e garantir a Grave incidente é atualizado de acordo para manter uma história cheia de ações. Nota sobre alocação de Incidentes Pode haver muitos incidentes numa fila com o mesmo prioridade nível - por isso vai ser o trabalho do Service Desk e / ou Gerenciamento de Incidentes pessoal inicialmente, em conjunto com os gestores das diversas grupo de apoios para que os incidentes são escalados, para decidir a ordem em que os incidentes devem ser pego e trabalhado ativamente. Esses gerentes devem garantir que os incidentes são tratados de modo verdadeiro negócio prioridade e que os funcionários não estão autorizados a "cereja-pick 'dos incidentes que escolher! 4.2.5.7 Investigação e Diagnóstico No caso de incidentes em que o usuário está apenas em busca de informações, o Service Desk deve ser capaz de fornecer esta muito rapidamente e resolver a ITIL V3 - Operação de Serviço - Página: 100 de 423
    • solicitação de serviço - mas se um culpa está sendo relatado, este é um incidente e é provável que requerem algum grau de investigação e diagnóstico. Cada um dos grupos de apoio envolvidos com o tratamento de incidentes irá investigar e diagnosticar o que está errado - e todas essas atividades (incluindo detalhes de quaisquer medidas tomadas para tentar resolver ou recriar o incidente) devem ser devidamente documentados no registro de incidente para que um histórico completo registro de todas as actividades é mantida em todos os momentos. Nota: O tempo valioso muitas vezes pode ser perdido se investigação e acção de diagnóstico (ou mesmo resolução ou recuperação ações) são executadas em série. Sempre que possível, essas atividades devem ser realizadas em paralelo para reduzir prazos gerais - e ferramentas de apoio devem ser concebidos e / ou selecionados para permitir isso. No entanto, cuidados devem ser tomados para coordenar as atividades, atividades especialmente de resolução ou de recuperação, caso contrário, as ações de diferentes grupos podem entrar em conflito ou complicar ainda mais a resolução! Esta investigação é provável que incluem ações como: • Estabelecer exatamente o que deu errado ou sendo procurado pelo usuário • Compreender a ordem cronológica de eventos • Confirmando o pleno impacto do incidente, incluindo o número e variedade de usuários afetados • Identificar quaisquer eventos que possam ter provocado o incidente (por exemplo, uma recente mudar, Alguma ação do usuário?) • Buscas conhecimento procurando ocorrências anteriores por pesquisar anterior Incidente/Grave problemas e / ou Banco de Dados de erro conhecidos ou fabricantes '/fornecedors 'logs de erros ou bancos de dados de Conhecimento. 4.2.5.8 Resolução e Recuperação Quando um potencial resolução foi identificado, este deve ser aplicado e testado. As ações específicas a serem realizadas e as pessoas que serão envolvidas na tomada de recuperação acções podem variar, dependendo da natureza do culpa - Mas pode envolver: • Pedindo o usuário para realizar atividades direcionadas em seu topo própria mesa ou o equipamento remoto • O Service Desk implementar a resolução ou centralmente (por exemplo, reiniciar um servidor) Ou remotamente usando o software para assumir o controle do computador do usuário para diagnosticar e implementar uma resolução ITIL V3 - Operação de Serviço - Página: 101 de 423
    • • Especialista grupo de apoioestá sendo solicitado a implementar ações de recuperação específicas (por exemplo suporte de rede reconfigurar um roteador) • Um fornecedor de terceiros ou mantenedor sendo solicitados a resolver a falha. Mesmo quando uma resolução foi encontrado, testes suficientes devem ser realizados para garantir que a ação de recuperação é completa e que a serviço foi totalmente restaurard para o utilizador (es). NOTA: em alguns casos, pode ser necessário que dois ou mais grupos de tomar separadas, embora talvez coordenadas as acções de recuperação, para uma resolução global a ser implementado. Em tais casos, Gestão de Incidentes deve coordenar as actividades e estabelecer contactos com todas as partes envolvidas. Independentemente das medidas tomadas, ou que faz deles, o Grave incidente deve ser atualizado de acordo com todas as informações e detalhes para que uma história cheia é mantido. O grupo deve passar resolver o incidente de volta para o Service Desk para fecho ação. 4.2.5.9 Fechamento de Incidentes O Service Desk deve verificar se o incidente está totalmente resolvido e que os usuários estão satisfeitos e dispostos a aceitar o incidente pode ser fechado. O Service Desk também deve verificar o seguinte: • Categorização encerramento. Verificar e confirmar que a categorização incidente inicial foi correta ou, onde a categorização posteriormente acabou por ser incorreta, atualizar o registro para que uma categorização fechamento correto é registrada para o incidente - que procuram aconselhar ou orientação do grupo de Resolução (s), se necessário. • Pesquisa de satisfação do usuário. Realizar uma pesquisa de satisfação do usuário de call-back ou e-mail para o percentual acordado de incidentes. • Documentação do incidente. Perseguir todos os detalhes pendentes e garantir que o registro de incidentes é totalmente documentado para que um registro completo histórico em um nível suficiente de detalhe é completa. • Em curso ou recorrentes problema? Determinar (em conjunto com os grupos resolvedor) se é provável que o incidente poderia ocorrer e decidir se qualquer acção preventiva é necessária para evitar isto. Em conjunto com a Gerenciamento de Problemas, Levantar um registro de problema em todos esses casos para que a ação preventiva é iniciada. ITIL V3 - Operação de Serviço - Página: 102 de 423
    • • Formal fecho. Encerrar formalmente o Grave incidente. Nota: Algumas organizações podem optar por utilizar um período de fechamento automático em específico, ou mesmo todos, incidentes (por exemplo incidente será automaticamente fechado depois de dois dias úteis se mais contato é feito pela usuário). Onde esta abordagem deve ser considerado, ele deve primeiro ser totalmente discutido e acordado com os usuários - e amplamente divulgado para que todos os usuários e equipe de TI estão cientes disso. Pode ser inapropriado para usar este método para certos tipos de incidentes - como incidente graves ou aqueles que envolvem VIPs, etc Regras para reabertura incidentes Apesar de todo o cuidado adequado, haverá ocasiões em que incidentes se repetir, apesar de terem sido formalmente fechado. Por causa de tais casos, é aconselhável ter regras pré-definidas sobre se e quando um incidente pode ser reaberto. Pode fazer sentido, por exemplo, a concordar que, se persistir o incidente no prazo de um dia útil, então ele pode ser reaberto -, mas que para além deste ponto um novo incidente deve ser levantada, mas ligado ao incidente anterior (s). O tempo exato limiar/ Regras podem variar entre organizações individuais - mas regras claras devem ser acordados e documentados e orientação dada a todos Service Desk pessoal, de modo que a uniformidade é aplicada. 4.2.6 Triggers interfaces de entrada e saída / inter-processo Incidentes pode ser acionado de diversas maneiras. A rota mais comum é quando um usuário toca o Posto de Serviço ou completa um web-based tela incidente registro, mas cada vez mais incidentes são criados automaticamente através Gestão de Eventos ferramentas. A equipe técnica pode notar potencial falhas e levantar um incidente, ou pedir o Service Desk para o fazer, de modo que a culpa podem ser abordados. Alguns incidentes podem também surgir no início do fornecedors - que pode enviar alguma forma de notificação de uma dificuldade potencial ou real que precisa de atenção. As interfaces com Gerenciamento de Incidentes incluem: • Gerenciamento de Problemas: Gerenciamento de Incidentes faz parte do total processo de tratar problemas no organização. Os incidentes são muitas vezes causados por problemas subjacentes, que devem ser resolvidos para evitar que o incidente se repita. Gerenciamento de Incidentes fornece um ponto onde estes são relatados. • Gerenciamento da Configuração fornece os dados utilizados para identificar e progredir incidentes. Uma das utilizações da CMS é identificar equipamento defeituoso e para avaliar a impacto de um incidente. É ITIL V3 - Operação de Serviço - Página: 103 de 423
    • também usado para identificar os utilizadores afectados por problemas potenciais. O CMS também contém informações sobre as categorias de incidente deve ser atribuído a que grupo de apoio. Por sua vez, Gerenciamento de Incidentes pode manter a estado de CIs com defeito. Ele também pode ajudar Gerenciamento de Configuração para auditar a infra-estrutura quando se trabalha para resolver um incidente. • Gestão da Mudança: Sempre que um mudar é necessário para implementar um solução alternativa ou resolução, este terá que ser registrada como um RFC e progrediu através do Gerenciamento de Mudança. Por sua vez, Gerenciamento de Incidentes é capaz de detectar e resolver os incidentes que surgem de mudanças fracassadas. • Gerenciamento da Capacidade: Gerenciamento de Incidentes fornece um gatilho para atuação monitoramento onde parece haver uma atuação problema. Gerenciamento da Capacidade pode desenvolver soluções para incidentes. • Gerenciamento de Disponibilidade; usará dados Gerenciamento de Incidentes para determinar a disponibilidade de De serviços de TIs e olhar para onde o incidente ciclo de vida pode ser melhorada. • SLM: A capacidade de resolver os incidentes em uma hora especificada é uma parte fundamental de entregar um nível acordado de serviço. Gerenciamento de Incidentes permite SLM para definir respostas mensuráveis para as interrupções de serviço. Ele também fornece relatórios que permitem a SLM rever SLAs objetivamente e regularmente. Em particular, Gerenciamento de Incidentes é capaz de ajudar a definir onde os serviços estão em seu ponto mais baixo, de modo que SLM pode definir ações como parte da Melhoria de Serviço Programa (SIP) - consulte o Melhoria de Serviço Continuada publicação para mais detalhes. SLM define os níveis aceitáveis de serviço em que obras de gerenciamento de incidentes, incluindo: • Incidente tempo de respostas • Impacto definições • Alvo vezes fix • Definições de serviço, que são mapeados para usuários • Regras para serviços requerentes • Expectativas para fornecer feedback para usuários. 4.2.7 Gestão da Informação A maioria das informações utilizadas no Gerenciamento de Incidentes vem das seguintes fontes: • As ferramentas de gerenciamento de incidentes, Que contêm informações sobre: • Incidente e problema história • Categorias de incidentes • Medidas tomadas para resolver os incidentes ITIL V3 - Operação de Serviço - Página: 104 de 423
    • • Script de diagnósticos, que pode ajudar os analistas de primeira linha para resolver o incidente, ou pelo menos reunir informações que irão ajudar os analistas de segunda ou terceira linha resolvê-lo mais rápido. • Grave incidentes, Que incluem os seguintes dados: • Número de referência único • Incidente classificação • Data e hora da gravação e quaisquer atividades subseqüentes • Nome e identidade da pessoa gravar e atualizar o registro de incidentes • Nome /organização/ Detalhes de contato do usuário afetado (s) • Descrição dos sintomas de incidentes • Detalhes de quaisquer medidas tomadas para tentar diagnosticar, solucionar ou recriar o incidente • Incidente categoria,impacto,urgência e prioridade • Relação com outros incidentes, problemas, alterações ou Erro Conhecidos • Fecho detalhes, incluindo o tempo, categoria, As medidas tomadas e identidade de pessoa fechando a registro. Gerenciamento de Incidentes também exige o acesso ao CMS. Isso irá ajudá-lo a identificar os CIs afetados pelo incidente e também para estimar o impacto do incidente. O Banco de Dados de erro conhecido fornece informações valiosas sobre possível resoluçãos e solução alternativas. Isso é discutido em detalhes no parágrafo 4.4.7.2. 4.2.8 Métricas O métricos que devem ser monitorados e reportados para julgar o eficiência e eficácia do Gerenciamento de Incidentes processo, Ea sua operação, Irão incluir: • Número total de incidentes (como um controlar medida) • Distribuição dos incidentes em cada fase (por exemplo, registrado, trabalho em andamento,fechado etc) • Tamanho do backlog de incidentes atual • Número e percentual de incidente graves • O tempo médio para conseguir a resolução de incidentes ou evasão, discriminadas por código de impacto • Percentual de incidentes tratados dentro concordaram tempo de resposta (Incidentes de tempo de resposta alvos podem ser especificados nos SLAs, por exemplo, por impacto e urgência códigos) • Média custar por incidente • Número de incidentes reabertas e como uma percentagem do total ITIL V3 - Operação de Serviço - Página: 105 de 423
    • • Número e percentual de incidentes atribuídos incorretamente • Número e percentual de incidentes classificados incorretamente • Percentual de Incidentes fechada pelo Service Desk sem referência a outros níveis de apoio (muitas vezes referido como "o primeiro ponto de contato") • Número e porcentagem de incidentes processados por agente Service Desk • Número e percentagem de casos resolvidos remotamente, sem a necessidade de uma visita • Número de incidentes tratados por cada incidente Modelo • Distribuição dos incidentes por hora do dia, para ajudar a identificar e garantir picos de correspondência recursos. Os relatórios devem ser produzidos sob a autoridade do Gerente de Incidentes, que deverá elaborar um calendário e lista de distribuição, em colaboração com o Service Desk e grupo de apoiomanipulação de incidentes s. As listas de distribuição deve incluir pelo menos De serviços de TIs Gestão e especialista grupo de apoios. Considere também tornando os dados disponíveis para usuários e clientes, por exemplo, através de relatórios de SLA. 4.2.9 Desafios, Fatores Críticos de Sucesso e riscos 4.2.9.1 Desafios Os seguintes desafios irão existir para o sucesso Gerenciamento de Incidentes: • A capacidade de detectar incidentes tão cedo quanto possível. Isso exigirá educação da usuárioincidentes s relatórios, o uso de Super Users (ver parágrafo 6.2.4.5) e do configuração de Gestão de Eventos ferramentas. • Convencer todo o pessoal (equipes técnicas, bem como usuários) que todos os incidentes devem ser registrados, e incentivar o uso de auto- ajuda baseado na web capacidades (que pode acelerar a assistência e reduzir recursos exigências). • Disponibilidade de informações sobre problemas e Erro Conhecidos. Isso vai permitir que a equipe de Gerenciamento de Incidentes de aprender com incidentes anteriores e também para acompanhar o estado de resoluçãos. • Integração no CMS para determinar relaçãos entre IC e para se referir à história de CIs ao realizar suporte de primeira linha. • Integração na SLM processo. Isso vai ajudar Gerenciamento de Incidentes corretamente para avaliar a impacto e prioridade de incidentes e auxilia na definição e execução escalada procedimentos. SLM também serão beneficiados com as informações aprendidas durante o Gerenciamento de Incidentes, por exemplo, para determinar se nível de serviço atuação metas são realistas e realizáveis. ITIL V3 - Operação de Serviço - Página: 106 de 423
    • 4.2.9.2 Fatores Críticos de Sucesso Os seguintes fatores serão fundamentais para a Gestão de Incidentes de sucesso: • Um bom Service Desk é a chave para o Gerenciamento de Incidentes de sucesso • Objectivos claramente definidos que trabalhar para - conforme definido no SLA • Adequado clienteOrientada para o pessoal de apoio e tecnicamente treinamento com os níveis de habilidade corretos, em todas as fases do processo de • Ferramentas de apoio integrados de conduzir e controlar o processo de • Olas e UCs que são capazes de influenciar e moldar o comportamento correto de todo o pessoal de apoio. 4.2.9.3 Riscos O riscos para Gestão de Incidentes de sucesso são realmente semelhantes a alguns dos desafios e no verso de alguns dos Fator Crítico de Sucessos mencionados acima. Eles incluem: • Sendo inundados com incidentes que não podem ser tratados dentro de prazos aceitáveis devido à falta de disposição ou devidamente treinados recursos • Incidentes atolando e não progrediu como pretendido, porque de ferramentas de suporte inadequados para levantar alertars e progresso pronta • Falta de fontes de informação adequados e / ou oportuna porque de ferramentas inadequadas ou falta de integração • Descasamentos de objetivos ou ações por causa de OLAs mal alinhados ou não-existente e / ou UCs. ITIL V3 - Operação de Serviço - Página: 107 de 423
    • 4,3 Cumprimento de Requisição O termo "Solicitação de Serviço'É utilizado como uma designação genérica para muitos tipos diferentes de exigências que são colocadas em cima do Departamento de TI pela usuários. Muitos deles são realmente pequenas mudanças - baixo risco, Que ocorrem com frequência, baixo custar, Etc (por exemplo, um pedido para alterar uma senha, um pedido para instalar um software adicional aplicação em uma estação de trabalho especial, um pedido para mudar alguns itens de equipamentos de mesa) ou talvez apenas uma questão solicitando informações -, mas a sua escala e freqüentes, de baixo risco natureza significa que eles são melhor tratadas em separado por uma processo, Em vez de serem autorizados a congestionar e obstruir o incidente normal e Gestão da Mudança processos. Finalidade 4.3.1 meta / / objetivo Cumprimento de Requisição é o processo de lidar com solicitações de serviço dos usuários. O objetivos do processo de Cumprimento de Requisição incluem: • Para fornecer um canal para que os usuários solicitar e receber serviços de padrão para que uma aprovação pré-definida e qualificação processo existe • Para fornecer informações aos usuários e clientes sobre o disponibilidade de serviços e os procedimento para a obtenção • Para fonte e entregar o componentes de pedidos padrão de serviços (por exemplo, licenças de software e mídia) • Para ajudar com informações gerais, reclamações ou comentários. 4.3.2 Âmbito O processo necessário para satisfazer um pedido variará dependendo exactamente o que está a ser pedido - mas pode ser geralmente dividido em um conjunto de actividades que têm de ser executadas. Algumas organizações vai ser confortável para que as solicitações de serviço ser tratado por meio de sua Gerenciamento de Incidentes processos (e ferramentas) - com solicitações de serviço que está sendo tratado como um tipo particular de 'incidente'(Utilizando uma classificação de alto nível sistema identificar os "incidentes" que estão em Solicitações de Serviço fato). Notar, contudo, que há uma diferença significativa aqui - um incidente é geralmente uma imprevista evento enquanto que uma solicitação de serviço geralmente é algo que pode e deve ser planejado! Portanto, numa organização onde um grande número de solicitações de serviço têm que ser tratados e onde as ações a serem tomadas para o cumprimento desses pedidos são muito variados ou especializados, pode ser apropriado para ITIL V3 - Operação de Serviço - Página: 108 de 423
    • lidar com solicitações de serviço como um fluxo de trabalho totalmente separada - e para gravar e gerenciá-los como um separado registro tipo. Isto pode ser particularmente apropriado se a organização optou por alargar o escopo do Service Desk para expandir apenas relacionados a TI questões e usar a mesa como um ponto focal para outros tipos ou solicitação de serviço - por exemplo, um pedido para atender a uma copiadora ou mesmo indo tão longe a ponto de incluir, por exemplo, a construção de questões de gestão, tais como a necessidade de substituir uma montagem de luz ou reparar um vazamento no encanamento. Nota: em última análise, caberá a cada organização decidir e documentar o que ele vai lidar com pedido através do processo de Cumprimento de Requisição e que outros terão que passar por Change Management mais formal. Sempre haverá áreas cinzentas que impedem a orientação genérica de ser útil prescrito. 4.3.3 Valor para os negócios O valor de Cumprimento de Requisição é fornecer acesso rápido e eficaz aos serviços padrão que funcionários da empresa pode usar para melhorar sua produtividade ou a qualidade de serviço de negócios e produtos. Cumprimento de Requisição efetivamente reduz a burocracia na solicitação e recebimento de acesso a serviços novos ou já existentes, reduzindo assim o custar da prestação destes serviços. Centralizando cumprimento também aumenta o nível de controlar sobre esses serviços. Este por sua vez, pode ajudar a reduzir custos através da negociação centralizada com fornecedors, e pode também ajudar a reduzir o custo do suporte. 4.3.4 Políticas / princípios / conceitos básicos Muitos Solicitação de Serviços será frequentemente recorrente, portanto, um pré-definido processo fluxo (a modelo) Pode ser concebido de modo a incluir as etapas necessárias para cumprir o pedido, a pessoas físicas ou grupo de apoios envolvidos prazos, alvo e escalada caminhos. Solicitações de serviços geralmente ser satisfeitas através da implementação de um Mudança Padrão (Veja a Transição de Serviço publicação para obter mais detalhes sobre Alterações padrão). A posse de solicitações de serviço reside com o Service Desk, Que monitora, escalada, expedições e muitas vezes cumpre a usuário pedido. 4.3.4.1 Modelos Pedido Algumas solicitações de serviço irá ocorrer com freqüência e vai exigir lidar de uma forma consistente, a fim de atender concordou nível de serviços. Para apoiar este, muitas organizações desejam criar modelos pré-definidos pedido ITIL V3 - Operação de Serviço - Página: 109 de 423
    • (que normalmente incluem algum tipo de pré-aprovação por Gestão da Mudança). Isto é similar em conceito à idéia de Modelos de Incidentes já descritos no parágrafo 4.2.4.2, mas aplicada a solicitações de serviço. 4.3.5 as atividades de processo, métodos e técnicas 4.3.5.1 seleção do menu Cumprimento de Requisição oferece grandes oportunidades de auto-ajuda práticas, onde os usuários podem gerar uma solicitação de serviço usando a tecnologia que links em Serviço de Gestão de ferramentas. Idealmente, os usuários devem ser oferecido um 'seleção menu' tipo através de uma interface web, para que eles possam escolher e detalhes de entrada de solicitações de serviço a partir de uma lista pré-definidas, onde as expectativas apropriadas pode ser definido, dando entrega de destino e / ou implementação metas / datas (em linha com as metas de SLA). Onde as organizações estão oferecendo uma auto-ajuda de suporte de TI capacidade para os usuários, não faria sentido para combinar isso com um Cumprimento de Requisição sistema como descrito. Ferramentas especializadas web para oferecer este tipo de experiência "carrinho de compras" pode ser utilizado em conjunto com interfaces diretamente para o back-end ferramentas integradas de ITSM, ou outra mais geral processo de negócio automação ou Enterprise Resource Planning (ERP), ferramentas que podem ser utilizadas para o gerenciamento das atividades de Cumprimento de Requisição. 4.3.5.2 aprovação Financeiro Um importante passo extra que é provável que seja necessário quando se lida com um solicitação de serviço é a de aprovação financeira. A maioria das solicitações terão alguma forma de implicações financeiras, independentemente do tipo de acordos comerciais no local. O custo de cumprir o pedido deve primeiro ser estabelecida. Pode ser possível concordar preços fixos para "padrão" - e pedidos de aprovação prévia para tais pedidos pode ser dado como parte do organização'S anual global gestão financeira. Em todos os outros casos, uma estimativa do custo deve ser produzido e apresentado ao usuário para aprovação financeira (o usuário pode precisar de procurar aprovação a sua gestão / cadeia financeira). Se a aprovação for dada, além de cumprir o pedido, a processo Deve também incluir carregamento (Faturamento ou a tarifação) para o trabalho feito - se a carga está no local. 4.3.5.3 aprovação Outros Em alguns casos a autorização adicional pode ser necessária - como relacionados à conformidade ou aprovação mais ampla de negócios. ITIL V3 - Operação de Serviço - Página: 110 de 423
    • Cumprimento de Requisição deve ter a capacidade de definir e verificar essas aprovações, quando necessário. 4.3.5.4 Cumprimento O real cumprimento atividade irá depender da natureza do Solicitação de Serviço. Alguns pedidos mais simples pode ser preenchido pelo Service Desk, Atuando como suporte de primeira linha, Enquanto outros terão de ser encaminhados para grupos de especialistas e / ou fornecedors para o cumprimento. Algumas organizações podem ter grupos especializados de atendimento (para 'pegar, embalar e despachar ") - ou pode ter alguns terceirizados de atendimento atividades para um fornecedor de terceiros (s). O Service Desk deve monitorar e perseguir o progresso e manter usuários informado durante todo, independentemente da fonte de realização real. 4.3.5.5 Encerramento Quando a solicitação de serviço foi cumprido deve ser remetido ao Service Desk para fecho. O Service Desk devem passar pelo processo de encerramento mesmo como descrito anteriormente no ponto 4.2.5.9 - verificar se o usuário está satisfeito com o resultado. 4.3.6 Triggers interfaces de entrada e saída / inter-processo A maioria dos pedidos será acionado, quer através de um usuário chamando o Service Desk ou um usuário de completar alguma forma de auto-ajuda baseado na web tela de entrada para fazer seu pedido. Este último, muitas vezes, envolvem uma seleção de uma carteira de pedidos disponíveis types.The interfaces primárias com Cumprimento de Requisição incluem: • Service Desk /Gerenciamento de Incidentes: Solicitações de serviços pode vir em muitos através do Service Desk e pode ser inicialmente tratado através do processo de Gerenciamento de Incidentes. Algumas organizações podem escolher que todos os pedidos são tratados por esta via - mas outros podem optar por ter um processo separado, por razões já discutidas anteriormente neste capítulo. • A forte ligação também é necessário entre Cumprimento de Requisição, Solte, Ativos e Gerenciamento da Configuração - Como alguns pedidos será para o desenvolvimento de novo ou atualizado componentes que pode ser implantado automaticamente. Em tais casos, a "libertação" pode ser pré-definido, construído e testado, mas só implantada a pedido por aqueles que querem a "libertação". Após a implantação, o CMS terá que ser atualizado para refletir a mudar. Se for o caso, os cheques de licença de software / atualizações também será necessário. ITIL V3 - Operação de Serviço - Página: 111 de 423
    • Se for caso disso, será necessário relacionar Pedidos relacionados a TI de serviço para qualquer incidentes ou problemas que iniciaram a necessidade para o pedido (como seria o caso em qualquer outro tipo de modificação). 4.3.7 Gestão da Informação Cumprimento de Requisição depende das informações das seguintes fontes: • As solicitações de serviço conterá informações sobre: • O que serviço está sendo solicitado • Que tenha solicitado e autorizado o serviço • Que processo será usada para executar o pedido • A quem foi atribuído e que medidas foram tomadas • A data ea hora em que o pedido foi registrado, bem como a data e hora de todas as ações tomadas • Detalhes encerramento. • Pedidos de Alteração: Em alguns casos, a Cumprimento de Requisição processo será iniciado por um RFC. Isto é típico em que o Solicitação de Serviço refere-se a um IC • O Portfólio de Serviços, Para permitir que o escopo de solicitação de serviço concordou em ser identificado • Políticas de Segurança irá prescrever qualquer controle a ser executado ou cumprido aquando da prestação do serviço, por exemplo garantia de que o solicitante está autorizado a acessar o serviço, ou que o software está licenciado. 4.3.8 Métricas O métricos necessária para julgar a eficácia e eficiência de Cumprimento de Requisição irá incluir o seguinte (cada métrica precisa ser discriminadas por tipo de pedido, dentro do prazo): • O número total de solicitações de serviço (como um controlar medida) • Composição da solicitação de serviços, em cada fase (e.g. logged WIP, fechado, Etc) • O tamanho da carteira atual de pedidos de serviço pendentes • A média de tempo para lidar com cada tipo de solicitação de serviço • O número ea porcentagem de solicitações de serviço concluído dentro de vezes alvo acordados • A média custar por tipo de solicitação de serviço • Nível de cliente satisfação com o tratamento de solicitações de serviço (medido em alguma forma de pesquisa de satisfação). 4.3.9 Desafios, Fatores Críticos de Sucesso e riscos 4.3.9.1 Desafios ITIL V3 - Operação de Serviço - Página: 112 de 423
    • Os seguintes desafios serão enfrentados ao introduzir Cumprimento de Requisição: • Claramente definir e documentar o tipo de solicitações que serão tratadas no processo de Cumprimento de Requisição (e aqueles que quer passar pelo Service Desk e ser tratado como um incidente ou aqueles que precisam passar por formais Gestão da Mudança) - Para que todos os partidos são absolutamente clara sobre o alcance. • Estabelecimento de auto-ajuda de front-end capacidades que permitem a usuários para interagir com sucesso com o Cumprimento de Requisição processo. 4.3.9.2 Fatores Críticos de Sucesso A realização de pedido depende do seguinte Fator Crítico de Sucessos: • Acordo de que os serviços serão normalizados e que está autorizado a solicitá-los. O custar destes serviços também deve ser acordado. Isto pode ser feito como parte do processo de SLM. Qualquer variaçãos dos serviços também deve ser definido. • Publicação dos serviços aos usuários, como parte do Catálogo de Serviços. É importante que essa parte do Catálogo de Serviços deve ser facilmente acessados, talvez na Intranet, e deve ser reconhecida como a primeira fonte de informação para os usuários que buscam acesso a um serviço. • Definição de um padrão cumprimento procedimento para cada um dos serviços a ser solicitados. Isto inclui todas as políticas de aquisição e capacidade de gerar ordens de compra e ordens de serviço • Aúnico ponto de contato que pode ser usado para solicitar o serviço. Isso é muitas vezes fornecido pelo Service Desk ou por meio de um pedido de intranet, mas pode ser por meio de um pedido automatizado directamente para o cumprimento de solicitação ou aquisição sistema. • De auto-atendimento ferramentas necessárias para fornecer uma interface de front-end para os usuários. É essencial que estes integração com as ferramentas de back-end de atendimento, muitas vezes geridos através de Incidente ou Gestão da Mudança. 4.3.9.3 Riscos Riscos que podem ser encontrados com Cumprimento de Requisição incluem: • Mal definidas escopo, Onde as pessoas não são claras sobre o que exatamente o processo é esperado para lidar com • Interfaces de usuário mal projetadas ou implementadas para que os usuários têm dificuldade em obter os pedidos que eles precisam ITIL V3 - Operação de Serviço - Página: 113 de 423
    • • Mal projetados ou operados de back-end processos de atendimento, que são incapazes de lidar com o volume ou a natureza dos pedidos que estão sendo feitos • Inadequado monitoramento de modo que as capacidades exactas métricos não podem ser recolhidas. ITIL V3 - Operação de Serviço - Página: 114 de 423
    • 4,4 Gerenciamento de Problemas ITIL define um "problema'Como a causa de um ou mais incidentes. 4.4.1 Finalidade objetivo / / objetivo Gerenciamento de Problemas é o processo responsável pela gestão do ciclo de vida de todos os problemas. O primário objetivos de Gerenciamento de Problemas são para evitar problemas e incidentes resultantes de acontecer, para eliminar incidentes recorrentes e minimizar o impacto de incidentes que não podem ser evitados. 4.4.2 Âmbito Gerenciamento de Problemas inclui as atividades necessárias para diagnosticar o causa raiz de incidentes e determinar o resolução para aqueles problemas. Também é responsável por assegurar que a resolução é implementado através da adequada controlar procedimentos, especialmente Gestão da Mudança e Gerenciamento de Liberação. Gerenciamento de Problemas também vai manter as informações sobre os problemas e apropriado solução alternativas e resoluções, de modo que os organização é capaz de reduzir o número e impacto de incidentes ao longo do tempo. A este respeito, Gestão de Problemas tem uma interface com forte Gestão do Conhecimento, E ferramentas como o Banco de Dados de erro conhecido serão utilizados para ambos. Apesar de Incidentes e Gestão de Problemas são processos separados, eles estão intimamente relacionados e geralmente usam as mesmas ferramentas, e podem usar categorização semelhante, impacto e prioridade codificação sistemas. Isto irá assegurar a comunicação eficaz ao lidar com incidentes e problemas relacionados. 4.4.3 Valor para os negócios Gerenciamento de Problemas trabalha em conjunto com Gerenciamento de Incidentes e Gestão da Mudança para garantir que De serviços de TI disponibilidade e qualidade são aumentados. Quando os incidentes são resolvidos, informações sobre a resolução é gravado. Com o tempo, esta informação é utilizada para acelerar o tempo de resolução e identificar soluções permanentes, reduzindo o número eo tempo de resolução de incidentes. Isto resulta em menos tempo de inatividade e menos interrupções dos sistemas críticos de negócio. Valor adicional é derivado a partir do seguinte: ITIL V3 - Operação de Serviço - Página: 115 de 423
    • • Maior disponibilidade de serviços de TI • Maior produtividade do negócio ea equipe de TI • Redução das despesas em soluções ou correções que não funcionam • Redução em custar esforço em combate a incêndios ou resolver incidentes repetidos. 4.4.4 Políticas / princípios / conceitos básicos Existem alguns conceitos importantes de Gerenciamento de Problemas que devem ser levados em conta desde o início. Estes incluem: 4.4.4.1 Modelos de problemas Muitos problemas será única e vai exigir gerir de forma individual -, mas é possível que alguns incidentes possam ocorrer por causa de problemas dormentes ou subjacente (por exemplo, onde o custo de uma resolução permanente será elevada e uma decisão foi tomada não ir em frente com uma solução cara - mas para "viver com o problema). Bem como a criação de um Grave erro conhecido no banco de dados de erros conhecidos (ver parágrafo 4.4.5.7) para garantir mais rápido diagnóstico, A criação de um Problema Modelo para lidar com esses problemas no futuro pode ser útil. Isto é muito similar em conceito à idéia de Modelos de incidentes já descritos no parágrafo 4.2.4.2, mas aplicada a problemas, bem como incidentes. 4.4.5 as atividades de processo, métodos e técnicas Gestão problema consiste em dois processos principais: • Reativo Gerenciamento de Problemas, O qual é geralmente executado como parte da operação de serviço - e é, portanto, abrangidos nesta publicação • Gerenciamento de Problemas pró-ativa que é iniciada em Operação de Serviço, Mas geralmente conduzido como parte da Melhoria de Serviço Continuada. O Gerenciamento de Problemas reativa processo é mostrada na Figura 4.4. Este é um gráfico simplificada para mostrar o fluxo de processo normal, mas na realidade, alguns estados pode ser iterativo ou variações podem ter que ser feitas, a fim de lidar com situações particulares. ITIL V3 - Operação de Serviço - Página: 116 de 423
    • Figura 4.4 problema de fluxo de processo de Gestão de 4.4.5.1 detecção de problemas É provável que as múltiplas formas de detectar problemas vai existir em todas as organizações. Estas incluem: ITIL V3 - Operação de Serviço - Página: 117 de 423
    • • Suspeita ou detecção de uma causa de um ou mais incidentes pela central de serviços, o que resulta numa Grave problema sendo levantadas - a mesa pode ter resolvido o incidente mas não determinou uma causa definitiva e suspeita que é provável que volte a ocorrer, então vai levantar um registro de problema para permitir que a causa subjacente para ser resolvido. Alternativamente, pode ser imediatamente óbvio desde o início que um incidente, ou incidentes, foi causado por um problema importante, portanto, um registro de problema será levantado sem demora. • Análise de um incidente por um técnico grupo de apoio o que revela que existe um problema subjacente, ou seja susceptível de existir. • Detecção automática de uma infra-estrutura ou aplicação culpa, Usando evento/alertar ferramentas automaticamente para levantar um incidente que pode revelar a necessidade de um registro de problema. • A notificação de um fornecedor ou contratante que existe um problema que tem de ser resolvido. • Análise de incidentes como parte de Gerenciamento de Problemas pró- ativa - Resultando na necessidade de levantar um registro de problema, de modo que a falha subjacente pode ser investigada. Análise frequente e regular de dados de incidentes e problemas devem ser realizados para identificar as tendências que se tornam perceptíveis. Isso vai exigir categorização significativo e detalhado de incidentes / problemas e apresentação de relatórios regulares de padrões e áreas de grande ocorrência. 'Top 10' de relatórios, com drill-down capacidades para níveis mais baixos, é útil na identificação de tendências. Mais detalhes de como detectado tendências devem ser manipulados são incluídos na publicação Melhoria de Serviço Continuada. 4.4.5.2 registro Problema Independentemente do detecção método, todos os detalhes relevantes do problema devem ser registrados para que um histórico completo registro existe. Esta deve ser a data ea hora estampadas para permitir adequada controlar e escalada. Uma referência cruzada deve ser feito para o incidente (s) que iniciou o registro de problema - e todos os detalhes relevantes devem ser copiados do Grave incidente(S) para o registro de problema. É difícil ser exato, como casos podem variar, mas geralmente isso irá incluir detalhes, tais como: • Usuário detalhes • Detalhes do serviço • Detalhes do equipamento • Data / hora inicialmente logado ITIL V3 - Operação de Serviço - Página: 118 de 423
    • • Prioridade e detalhes de categorização • Descrição incidente • Detalhes de todos diagnóstico ou tentativa de recuperação ações tomadas. 4.4.5.3 Categorização Problema Os problemas devem ser classificados na mesma maneira como incidentes (e é aconselhável utilizar os mesmos códigos sistema) De modo que a verdadeira natureza da problema pode ser facilmente rastreada no futuro e significativa gestão da informação podem ser obtidos. 4.4.5.4 Priorização de Problemas Os problemas devem ser priorizados na mesma forma e pelas mesmas razões como incidentes - mas a frequência e impacto de incidentes relacionados também devem ser levados em conta. A codificação sistema descrita anteriormente na Tabela 4.1 (que combina com impacto urgência para dar um nível de prioridade global) pode ser usado para dar prioridade problemas da mesma forma que ele pode ser utilizado em caso de incidentes, embora as definições e orientação para suportar pessoal sobre o que constitui um problema, e as respectivas serviço alvos em cada nível, tem, obviamente, ser concebido em separado. Prioritização problema deve também ter em conta a gravidade dos problemas. Gravidade neste contexto refere-se a quão sério é o problema do ponto de vista de infra-estrutura, por exemplo: • O sistema pode ser recuperado, ou ele precisa ser substituído? • Quanto vai custar? • Quantas pessoas, com o que habilidades, que serão necessários para corrigir o problema? • Quanto tempo vai demorar para resolver o problema? • Quão extenso é o problema (por exemplo, quantos são afetados CIs)? 4.4.5.5 Investigação e Diagnóstico de Problemas Uma investigação deve ser conduzida para tentar diagnosticar o causa raiz do problema - a velocidade e natureza desta investigação irá variar dependendo da severidade do impacto, e urgência do problema - mas o nível apropriado de recursos e perícia deve ser aplicada para encontrar um resolução proporcional ao código atribuída prioridade e o alvo de serviço no local para que o nível de prioridade. Há uma série de técnicas de resolução de problemas úteis que podem ser usados para ajudar a diagnosticar e resolver problemas - e estes devem ser ITIL V3 - Operação de Serviço - Página: 119 de 423
    • utilizadas como apropriado. Tais técnicas são descritas em mais detalhe mais adiante nesta secção. O CMS deve ser usada para ajudar a determinar o nível de impacto e para ajudar a identificar e diagnosticar o ponto exacto de falha. O Know banco de dados de erros (BDEC) também deve ser acessado e problema de correspondência de técnicas (como pesquisas por palavras-chave) deve ser usado para ver se o problema ocorreu antes e, em caso afirmativo, para encontrar a resolução. Muitas vezes, é valiosa para tentar recriar o fracasso, de modo a entender o que deu errado, e então tentar várias formas de encontrar o mais adequado e rentável resolução ao problema. Para fazer isso de forma eficaz, sem causar mais perturbações ao usuários, uma teste sistema Será necessário que espelha a ambiente de produção. Há muitos problemas de análise, diagnóstico e técnicas de resolução de pesquisas disponíveis e muito tem sido feito nesta área. Algumas das técnicas mais úteis e freqüentemente usados incluem: • Análise cronológica: Ao lidar com um problema difícil, muitas vezes há relatos conflitantes sobre o que exatamente aconteceu e quando. É, portanto, muito útil brevemente para documentar todos os eventos em ordem cronológica - para fornecer um cronograma de eventos. Isso muitas vezes faz com que seja possível ver os eventos que pode ter sido provocado por outros - ou para descontar quaisquer reivindicações que não são suportados pela seqüência de eventos. • Análise de Valor dor: Este é o lugar onde uma visão mais ampla é tomado da impacto de um incidente ou problema ou incidente / problema tipo. Em vez de apenas analisar o número de incidentes / problemas de um determinado tipo em um determinado período, uma análise mais profunda é feito para determinar exatamente qual o nível de dor foi causada ao organização/ Negócio por estes incidentes / problemas. A fórmula pode ser concebido para calcular este nível de dor. Normalmente, isso pode incluir tendo em conta: • O número de pessoas afetadas • A duração do tempo de inatividade causado • O custar para o negócio (se este pode ser facilmente calculada ou estimada). Ao tomar todos esses fatores em conta, uma imagem muito mais detalhada dos incidentes / problemas ou incidentes / problemas tipos que estão causando mais dor pode ser determinado - para permitir um foco melhor sobre as coisas que realmente importam e merecem maior prioridade na resolução ITIL V3 - Operação de Serviço - Página: 120 de 423
    • • Kepner e Tregoe: Charles Kepner e Benjamin Tregoe desenvolveu uma maneira útil de análise do problema, que pode ser usado formalmente para investigar mais profundamente enraizados problemas. Eles definida pelas seguintes etapas: • definindo o problema • descrevendo o problema em termos de identidade, localização, tempo e tamanho • determinar eventuais causas • testando a causa mais provável • verificar a verdadeira causa. O método é descrito em maior detalhe no Apêndice C. • Brainstorming: Muitas vezes pode ser valiosa para reunir as pessoas relevantes, seja fisicamente ou por meios electrónicos, e para "debater" o problema - com pessoas jogando idéias sobre o que a causa potencial pode ser e possíveis ações para resolver o problema. Sessões de brainstorming pode ser muito construtiva e inovadora, mas é igualmente importante que alguém, talvez Gestor do Problema, documenta a resultado e as ações acordadas e mantém um grau de controlar na sessão (s). • Diagrama de Ishikawas: Kaoru Ishikawa (1915-1989), um líder em japonês qualidade controle, desenvolveu um método de documentar as causas e efeitos que podem ser úteis para ajudar a identificar onde algo pode estar errado, ou ser melhorado. Tal esquema é tipicamente o resultado de um de brainstorming sessão em que solucionadores de problemas pode oferecer sugestões. O objectivo principal é representado pelo tronco do diagrama, e os factores principais são representados como ramos. Factores secundários são então adicionados como hastes, e assim por diante. Criando o diagrama estimula a discussão e muitas vezes leva a uma maior compreensão de um complexo problema. Um diagrama de exemplo é dado no Apêndice D. • Análise de Pareto: Esta é uma técnica de separação de importantes causas potenciais de questões mais triviais. Os seguintes passos devem ser tomados: 1. Faça uma tabela listando as causas e sua freqüência como uma porcentagem. 2. Organize as linhas na ordem decrescente de importância das causas, ou seja, a causa mais importante primeiro. 3. Adicionar uma coluna de percentagem cumulativa para a mesa. Por esta etapa, o gráfico deve ser algo como a Tabela 4.2, que ilustra 10 causas de rede falha num organização. Falhas na rede ITIL V3 - Operação de Serviço - Página: 121 de 423
    • Causas Percentagem do total Computação Acumulativo % Controlador de Rede 35 0% 35 35 Corrupção de arquivo 26 35% 26% 61 Resolução de conflitos 19 61% 19% 80 Servidor OS 6 80% 6% 86 Scripting erro 5 86% 5% 91 Não testado mudar 3 91% 3% 94 Erro do operador 2 94% 2% 96 Falha de backup 2 96% 2% 98 Tentativas de intrusão 1 98% 1% 99 Falha de disco 1 99% 1% 100 Tabela 4.2 Pareto ranking de causa 4. Criar um gráfico de barras com as causas, na ordem de sua porcentagem do total. 5. Sobrepor um gráfico de linha das percentagens cumulativas. O gráfico completo é ilustrado na Figura 4.5. 6. Desenhar linha a 80% em relação ao eixo y paralelo ao eixo x. Em seguida, cair na linha, no ponto de intersecção com a curva sobre o eixo x. Este ponto do eixo x separa as causas importantes e causas triviais. Esta linha é representada como uma linha tracejada na Figura 4.5. ITIL V3 - Operação de Serviço - Página: 122 de 423
    • Figura 4.5 Importantes causas contra trivial A partir deste gráfico, é claro, para ver que há três causas principais para a rede falha no organização. Estes devem, por conseguinte, ser dirigida em primeiro lugar. 4.4.5.6 Soluções Alternativas Em alguns casos, pode ser possível encontrar um solução alternativa aos incidentes causados pela problema - Forma temporária de superar as dificuldades. Por exemplo, uma alteração manual pode ser feita a um ficheiro de entrada para permitir que um programa de completar com sucesso o seu ITIL V3 - Operação de Serviço - Página: 123 de 423
    • funcionamento e permitir a facturação processo para completar satisfatoriamente, mas é importante que o trabalho de um permanente resolução continua quando tal se justifique - neste exemplo, a razão para o arquivo se tornar corrompido, em primeiro lugar deve ser encontrada e corrigida para evitar que isso aconteça novamente. Nos casos em que uma solução é encontrada, por isso é importante que o registro de problema permanece em aberto, e os detalhes da solução são sempre documentado dentro do Grave problema. 4.4.5.7 Levantando um registro de Erro Conhecido Logo que o diagnóstico está completa, e em particular quando a solução foi encontrado (ainda que isto pode não ser ainda uma resolução permanente), uma Grave erro conhecido devem ser levantadas e colocadas na Banco de Dados de erro conhecido - De modo que, se mais incidentes ou problemas, eles podem ser identificados e a serviço restaurarD mais rapidamente. No entanto, em alguns casos, pode ser vantajoso aumentar a Gravar Erro Conhecido ainda mais cedo no processo global - apenas para efeitos de informação, por exemplo, - o mesmo que o diagnóstico não pode ser completa ou uma solução encontrada, por isso não é aconselhável para definir um questão processual concreta exatamente quando um registro de Erro Conhecido deve ser levantada. Isso deve ser feito tão logo torna-se útil para o fazer! A base de dados de erro conhecido e a forma como deve ser usada são descritas em mais pormenor no ponto 4.4.7.2. 4.4.5.8 A resolução de problemas Idealmente, assim que uma solução foi encontrado, deverá ser aplicada para resolver o problema - mas na realidade salvaguardas podem ser necessários para assegurar que este não causa dificuldades adicionais. Se algum mudar em termos de funcionalidade é necessária isto exigirá um RFC para ser levantada e aprovados antes a resolução pode ser aplicado. Se o problema é muito grave e uma correção urgente é necessária por razões de negócios, então uma RFC de emergência deve ser tratado pelo Emergency Change Advisory Board (ECAB). Caso contrário, o RFC deve seguir o estabelecido Gestão da Mudança processo para esse tipo de mudança - ea resolução deve ser aplicada apenas quando a mudança foi aprovada e agendada para liberar. Enquanto isso, o BDEC deve ser usado para ajudar a resolver rapidamente quaisquer outras ocorrências de incidentes / problemas que ocorrem. Nota: Pode haver alguns problemas para os quais um Business Case para a resolução não pode ser justificado (por exemplo, onde o impacto é limitado, mas o custar de resolução seria extremamente elevado). Nesses casos, uma decisão ITIL V3 - Operação de Serviço - Página: 124 de 423
    • pode ser tomada para deixar o Grave problema abrir, mas de usar uma descrição solução no registro de erro Conhecido para detectar e resolver quaisquer recorrências rapidamente. Cuidados devem ser tomados para usar o código apropriado para marcar o registro de problema aberto para que ele não conta contra o atuação da equipa de execução do processo e de forma que o retrabalho não autorizado não ocorre. 4.4.5.9 Encerramento Problema Quando qualquer mudar foi concluído (e com sucesso revered), e a resolução tem sido aplicada, o Grave problema Deve ser formalmente fechado - Como no caso de ocorrerem relacionado Grave incidentes que ainda estão abertos. A verificação deve ser executada neste momento para garantir que o registro contém uma descrição histórico completo de todos eventos - e se não, o registro deve ser atualizado. O estado de qualquer relacionado Grave erro conhecido deve ser atualizado para mostra que a resolução tenha sido aplicada. 4.4.5.10 Revisão grande problema Depois de todos os grandes problema (Conforme determinado pela organização'S prioridade sistema), Enquanto ainda estão frescas as memórias de análise deverá ser conduzida para aprender quaisquer lições para o futuro. Especificamente, a revisão deverá analisar: • Essas coisas que foram feitas corretamente • Essas coisas que foram feitas erradas • O que poderia ser feito melhor no futuro • Como prevenir a recorrência • Se houve qualquer responsabilidade de terceiros e se as ações de acompanhamento são necessários. Estas revisões podem ser usados como parte de atividades de treinamento e conscientização para os funcionários de apoio - e as lições aprendidas devem ser documentados em apropriada procedimentos, instrução de trabalhos, script de diagnósticos ou registros de erro conhecidas. O Gestor de Problemas facilita a sessão e documentos todas as ações acordadas. O conhecimento aprendido com a revisão deve ser incorporado em uma serviço rever reunião com o empresa cliente para assegurar a cliente está ciente das ações e os planos para evitar futuras incidente graves ocorra. Isso ajuda a melhorar a satisfação do cliente e assegurar o negócio que Operação de Serviços está a lidar com incidentes de maior responsabilidade e trabalhando ativamente para evitar que se repitam no futuro. ITIL V3 - Operação de Serviço - Página: 125 de 423
    • 4.4.5.11 Os erros detectados no ambiente de desenvolvimento É raro para qualquer novo aplicaçãos, ou sistemas de software liberars para ser completamente erroLivre. É mais provável que, durante o teste de tais novas aplicações, sistemas ou versões de um sistema de prioridades serão utilizados para erradicar o mais sério culpas, mas é possível que pequenas falhas não são rectificadas - muitas vezes por causa do equilíbrio que tem de ser feita entre o fornecimento de novas funcionalidades para o negócio, o mais rapidamente possível e garantir código totalmente livre de falhas ou componentes. Quando uma decisão é feita para lançar algo para o ambiente de produção que inclui deficiências conhecidas, estes devem ser registrados como Erros Conhecidos no BDEC, juntamente com detalhes de solução alternativas ou atividades de resolução. Deve haver um passo formal no teste de sinal fora-de que assegura que esta transferência ocorre sempre (ver Transição de Serviço publicação). A experiência tem mostrado, se isso não acontecer, ele vai levar a um apoio muito maior custars quando o usuários começar a sentir as falhas e aumentar os incidentes que têm de voltar a ser diagnosticado e resolvido tudo de novo! 4.4.6 Triggers interfaces de entrada e saída / inter-processo A grande maioria dos Grave problemas será desencadeada em reação a um ou mais incidentes, e muitos vão ser levantada ou iniciada através equipe de Service Desk. Registros outro problema, e os correspondentes Registros de erro conhecido, pode ser desencadeada em testes, particularmente as últimas fases de testes, como Usuário Teste de aceitação / Trials (UAT), se for tomada a decisão de ir em frente com um liberar mesmo que alguns culpas são conhecidos. Fornecedores podem desencadear a necessidade de algum Grave problemas através da notificação de possíveis falhas ou deficiências conhecidas em seus produtos ou serviços (por exemplo, um aviso pode ser dado em relação ao uso de um CI em particular e um registro de problema pode ser aumentado para facilitar a investigação pela equipe técnica da condição de CIs no prazo o organização'S Infraestrutura de TI). O primário relação entre Incidentes e Gerenciamento de Problemas foi discutido em pormenor nos pontos 4.2.6 e 4.4.5.1. Outras interfaces-chave incluem o seguinte: • Transição de Serviço • Gestão da Mudança: Gerenciamento de Problemas assegura que todo resoluçãos ou solução alternativas que requerem um mudar a um CI são submetidas através do Gerenciamento de Mudança através de um RFC. Gestão da Mudança irá monitorar o progresso dessas alterações e manter Gerenciamento de Problemas ITIL V3 - Operação de Serviço - Página: 126 de 423
    • aconselhou. Gerenciamento de Problemas também está envolvido em corrigir a situação causada pelas mudanças fracassadas. • Gerenciamento da Configuração: Gerenciamento de Problemas usa o CMS para identificar CIs com defeito e também para determinar a impacto de problemas e resoluçãos. O CMS também pode ser utilizado para formar a base para a BDEC e manter ou integrar-se com os registos de problemas. • Gerenciamento de Liberação e Implantação: É responsável por rolando correções de problemas fora no viver ambiente. Ela também ajuda a assegurar que o associado erro conhecidos são transferidos do desenvolvimento Banco de Dados de erro conhecido no banco de dados de erro vivos conhecidos. Gerenciamento de Problemas irá auxiliar na resolução de problemas causados por falhas durante o processo de liberação. • Design de Serviços • Gerenciamento de Disponibilidade: Está envolvido com a determinação de como reduzir tempo de inatividade e aumentar a produtividade. Como tal, tem uma estreita relação com a Gestão de Problemas, especialmente as áreas pró-ativas. Grande parte da gestão da informação disponível no Gerenciamento de Problemas será comunicada ao Gerenciamento de Disponibilidade. • Gerenciamento da Capacidade: Alguns problemas requerem investigação pelas equipes de capacidade de gestão e técnicas, por exemplo, atuação questões. Gerenciamento da Capacidade irá também ajudar a avaliar as medidas pró-ativas. Gerenciamento de Problema fornece informações gerenciais em relação ao qualidade das decisões tomadas durante o Planejamento de Capacidade processo. • De serviços de TI Continuidade: Problema atos de gestão como um ponto de entrada Gerenciamento da Continuidade do Serviço onde um problema significativo não for resolvido antes de começar a ter um grande impacto sobre o negócio. • Melhoria de Serviço Continuada • Gerenciamento de Nível de Serviço: A ocorrência de incidentes e problemas afeta o nível de prestação de serviços medidos pela SLM. Gerenciamento de Problemas contribui para melhorias na nível de serviços, e suas informações de gestão é utilizado como a base de uma parte do SLA rever componentes. SLM também fornece parâmetros dentro dos quais obras Problema de gestão, como impacto informação e os efeitos sobre os serviços de propostas de resoluções e medidas pró-ativas. • Estratégia de Serviço • Gestão Financeira: Auxilia na avaliação do impacto das propostas resoluçãos ou solução alternativas, bem como Análise de Valor dor. Gerenciamento de Problema fornece gestão da informação sobre o custar de resolver e prevenir problemas, que é usado ITIL V3 - Operação de Serviço - Página: 127 de 423
    • como entrada para o orçamentação e contabilidade sistemas e Custo Total de Propriedade cálculos. 4.4.7 Gestão da Informação 4.4.7.1 CMS O CMS vai realizar detalhes de todo o componentes da Infraestrutura de TI bem como o relaçãos entre estes componentes. Ele vai atuar como uma fonte valiosa para o problema diagnóstico e para avaliar o impacto dos problemas (por exemplo, se este disco é baixo, os dados que estão no disco, o que serviços usar esses dados, o que usuários usar esses serviços?). Como ele também irá realizar detalhes das atividades anteriores, ele também pode ser usado como uma fonte valiosa de dados históricos para ajudar a identificar as tendências ou fraquezas potenciais - uma parte essencial do Gerenciamento de Problemas pró-ativa (Ver Melhoria de Serviço Continuada publicação). 4.4.7.2 Banco de Dados Erro Conhecido A finalidade de um Banco de Dados de erro conhecido é permitir o armazenamento de conhecimento prévio de incidentes e problemas - e como eles foram superados - para permitir mais rápido diagnóstico e resolução se repitam. O Grave erro conhecido deve manter detalhes exatos da culpa e os sintomas que ocorreram, juntamente com detalhes precisos de qualquer ação ou solução alternativa de resolução que podem ser tomadas para restaurar o serviço e / ou resolver o problema. Um incidente contagem também será útil para determinar a frequência com que os incidentes são susceptíveis de se repetir e influenciar as prioridades, etc Deve notar-se que um Business Case para uma solução permanente para alguns problemas pode não existir. Por exemplo, se um problema não provocar perturbações graves e existe uma solução e / ou o custar de resolver o problema supera de longe os benefícios de uma solução permanente - então uma decisão pode ser tomada a tolerar a existência do problema. No entanto, será ainda desejável diagnosticar e implementar uma solução tão rapidamente quanto possível, que é onde o BDEC pode ser de ajuda. É essencial que os dados colocados na base de dados podem ser recuperados rapidamente e com precisão. O Gerente de problema deve ser totalmente treinado e familiarizado com os métodos de pesquisa / algoritmos usados pelo banco de dados selecionado e deve garantir que, quando cuidadosamente novo registros são adicionados, os principais critérios relevantes da pesquisa são corretamente incluído. ITIL V3 - Operação de Serviço - Página: 128 de 423
    • Cuidados devem ser tomados para evitar a duplicação de registros (ou seja, o mesmo problema descrito em duas ou mais formas como registros separados). Para evitar isso, o Gerenciador de problema deve ser a única pessoa capaz de entrar em um novo recorde. Outro grupo de apoios deve ser permitida, e até incentivado, para propor novos registros, mas estes devem ser controlados pelo Gerente problema antes de entrar no BDEC. Em grandes organizações, onde Gerenciamento de Problemas agentes existir em vários locais, mas um único BDEC é usado (recomendado!), um procedimento deve ser acordado entre todos os funcionários Gerenciamento de Problema para garantir que essa duplicação não pode ocorrer. Isso pode envolver a designação de apenas um membro da equipe como Gerente BDEC central. A BDEC deve ser utilizado durante as fases de diagnóstico de incidentes e problemas para tentar acelerar a resolução processo - E novos registos deve ser adicionado tão rapidamente quanto possível quando um novo problema foi identificado e diagnosticadas. Toda a equipe de suporte deve ser bem treinados e familiarizados com o valor que o BDEC pode oferecer e da forma como deve ser usado. Eles devem ser capazes prontamente para recuperar e utilizar os dados. Nota: Algumas ferramentas / implementações podem optar por delinear Erro Conhecidos simplesmente pela alteração de um campo no original Grave problema. Isto é aceitável, desde que o mesmo nível de funcionalidade está disponível. A BDEC, como o CMS, faz parte de um grande Serviço do Sistema de Gestão do Conhecimento (SKMS) ilustrado na Figura 4.6. Mais informação sobre os SKMS pode ser encontrada na Transição de Serviço publicação. ITIL V3 - Operação de Serviço - Página: 129 de 423
    • Figura 4.6 Serviço do Sistema de Gestão do Conhecimento 4.4.8 Métricas A seguir métricos devem ser usados para avaliar a eficácia e eficiência do Gerenciamento de Problemas processo, Ou seu operação: • O número total de problemas registados no período (como uma medida de controlo) • O percentual de problemas resolvidos dentro SLA metas (ea porcentagem que não são!) • O número ea porcentagem de problemas que ultrapassou a sua meta resolução vezes • O acúmulo de problemas pendentes e da tendência (estática, reduzindo ou aumentando?) • A média custar de tratamento de um problema • O número de grandes problemas (aberto e fechado e backlog) • A percentagem de grande problema Comentes realizados com sucesso • O número de Erro Conhecidos adicionados ao BDEC • A precisão da percentagem BDEC (a partir de auditars da base de dados) • O percentual de Comentários grande problema concluída com sucesso e no tempo. Todas as medidas devem ser discriminadas por categoria,impacto, Gravidade, urgência e prioridade e comparados com períodos anteriores. ITIL V3 - Operação de Serviço - Página: 130 de 423
    • 4.4.9 Desafios, Fatores Críticos de Sucesso e riscos Um grande dependência para Gerenciamento de Problemas é o estabelecimento de um processo eficaz de Gestão de Incidentes e ferramentas. Isto irá assegurar que os problemas são identificados, logo que possível, e que à medida que o trabalho é feito em grande parte pré-qualificação quanto possível. No entanto, é também crucial que os dois processos têm interfaces formais e de trabalho comum práticas. Isso significa o seguinte: • Ligando ferramentas de gerenciamento de incidentes e problemas • A capacidade de se relacionar e de Incidentes Grave problemas • O pessoal de segunda e terceira linha deve ter um bom trabalho relação com a equipe na primeira linha • Certificar-se de que o negócio impacto é bem compreendida por todo o pessoal que trabalha no problema resolução. Além disso, é importante que Gerenciamento de Problemas é capaz de usar todo o conhecimento e Gerenciamento de Configuração recursos disponível. Outra CSF é a formação contínua de pessoal técnico em ambos os aspectos técnicos do seu trabalho, bem como as implicações de negócios de serviços que suportam e os processos que eles usam ITIL V3 - Operação de Serviço - Página: 131 de 423
    • 4,5 Gerenciamento de Acesso Gerenciamento de Acesso é o processo de concessão de autorização usuárioo direito de usar um serviço, Enquanto impedindo o acesso a usuários não- autorizados. Também tem sido referido como Direitos Gestão ou Gestão de Identidade em diferentes organizações. 4.5.1 Finalidade objetivo / / objetivo Gerenciamento de Acesso prevê o direito de que os usuários possam usar um serviço ou grupo de serviços. É, portanto, a execução de políticas e ações definidas no Segurança e Gerenciamento de Disponibilidade. 4.5.2 Âmbito Gerenciamento de Acesso é efetivamente a execução de disponibilidade e Gestão de Segurança da Informação, Na medida em que permite que o organização para administrar o confidencialidade,disponibilidade e integridade de dados da organização e de propriedade intelectual. Gerenciamento de Acesso garante que os usuários têm o direito de usar um serviço, mas não garante que esse acesso está disponível em todos os momentos acordados - esta é fornecida pelo Gerenciamento de Disponibilidade. Gerenciamento de Acesso é um processo que é executado por todos os técnicos e Aplicação de Gestão de funçãos e não é geralmente uma função separada. No entanto, não é provável que seja um único controlar ponto de coordenação, geralmente em TI Gestão de Operações ou sobre o Service Desk. Gestão de acesso pode ser iniciada por um Solicitação de Serviço através do Service Desk. 4.5.3 Valor para os negócios Access Management fornece o seguinte valor: • Acesso controlado aos serviços garante que a organização é capaz de manter de forma mais eficaz o confidencialidade de suas informações • Os funcionários têm o nível de direito de acesso a executar as suas tarefas de forma eficaz • Há menos probabilidade de erros feitos na entrada de dados ou na utilização de um serviço crítico por um utilizador inexperiente (por exemplo, produção controlar sistemas) • A capacidade de auditar utilização dos serviços e traçar o abuso de serviços ITIL V3 - Operação de Serviço - Página: 132 de 423
    • • A capacidade mais facilmente para revogar o acesso direitos quando necessário - uma importante segurança consideração • Pode ser necessária para regulamentar observância (Por exemplo, SOX, HIPAA, COBIT). 4.5.4 Políticas / princípios / conceitos básicos Gerenciamento de Acesso é o processo que permite usuários para utilizar os serviços que estão documentados no Catálogo de Serviços. É composto pelos seguintes conceitos básicos: • Acesso se refere ao nível e extensão da funcionalidade de um serviço ou de dados que um usuário tem o direito de usar. • Identidade refere-se à informação sobre eles que os distingue como um indivíduo e que verifica a sua estado dentro do organização. Por definição, a identidade de um usuário é único para o usuário. (Isto é abordado com mais detalhe no ponto 4.5.7.1.) • Direitos (Também chamados de privilégios) referem-se às configurações reais em que um usuário é fornecido acesso a um serviço ou grupo de serviços. Direitos típicos, ou níveis de acesso, incluem ler, escrever, executar, alterar, excluir. • Serviços ou grupos de serviços. A maioria dos usuários não usam apenas um serviço, E os usuários que executam um conjunto semelhante de atividades irá usar um conjunto semelhante de serviços. Em vez de fornecer acesso a cada serviço para cada usuário separadamente, é mais eficiente para ser capaz de conceder a cada usuário - ou um grupo de usuários - o acesso a todo o conjunto de serviços que eles têm o direito de usar, ao mesmo tempo. (Isto é discutido em mais pormenor no ponto 4.5.7.2.) • Serviços de Diretório refere-se a um tipo específico de ferramenta que é utilizada para gerenciar o acesso e direitos. Estes são discutidos na seção 5.8. 4.5.5 as atividades de processo, métodos e técnicas 4.5.5.1 Solicitação de acesso De acesso (ou restrição) pode ser solicitado através de um qualquer número de mecanismos, incluindo: • Um pedido padrão gerada pelo Recursos Humanos sistema. Isso geralmente é feito sempre que uma pessoa for contratado, promovido, transferido ou quando deixam a empresa • ARequisição de Mudança • ASolicitação de Serviço apresentadas através do Cumprimento de Requisição sistema ITIL V3 - Operação de Serviço - Página: 133 de 423
    • • Ao executar um script pré-autorizado ou opção (por exemplo, o download de um aplicação a partir de uma preparação servidor como e quando ela é necessária). Regras para o pedido de acesso são normalmente documentados como parte do Catálogo de Serviços. 4.5.5.2 Verificação Gestão de acesso precisa verificar cada pedido de acesso a uma De serviços de TI a partir de duas perspectivas: • Que o usuário solicitar o acesso é que eles dizem que são • Que eles têm um legítimo exigência para esse serviço. O primeiro categoria é geralmente obtida pelo usuário fornecendo o seu nome de usuário e senha. Dependendo da organização segurança políticas, o uso do nome de usuário e senha são geralmente aceitos como prova de que a pessoa é um legítimo usuário. No entanto, para os serviços mais sensíveis identificação adicional pode ser necessária (uso, biométricos de uma chave de acesso eletrônico ou dispositivo de criptografia, etc.) A segunda categoria vai exigir algum independente verificação, Que não seja o pedido do utilizador. Por exemplo: • Notificação de Recursos Humanos que a pessoa é um funcionário novo e requer tanto um nome de usuário e acesso a um conjunto padrão de serviços • Notificação de Recursos Humanos que o usuário tenha sido promovido e requer acesso a adicional recursos • Autorização a partir de uma (adequada definida no processo) Gerente • Apresentação de um Solicitação de Serviço (Com provas), através da Service Desk • Apresentação de um RFC (com provas) através de Change Management, ou a execução de um pré-definido Mudança Padrão • Apolítica afirmando que o usuário pode ter acesso a um serviço opcional, se eles precisarem. Para novos serviços, a Alteração do registro deve especificar quais usuários ou grupos de usuários terão acesso ao serviço. Gerenciamento de Acesso Em seguida, verifique se todos os usuários ainda são válidos e fornecer automaticamente o acesso, conforme especificado no RFC. 4.5.5.3 Prever direitos ITIL V3 - Operação de Serviço - Página: 134 de 423
    • Gerenciamento de Acesso não decide quem tem acesso a que De serviços de TIs. Em vez disso, Gestão de Acesso executa as políticas e regulamentos definidos durante Estratégia de Serviço e Design de Serviços. Gerenciamento de Acesso impõe decisões para restringir ou fornecer acesso, em vez de tomar a decisão. Assim que um usuário tenha sido verificada, Gestão de Acesso irá fornecer o usuário com direitos utilizar o requerido serviço. Na maioria dos casos, isso vai resultar em um pedido para cada equipe ou departamento envolvido no apoio que o serviço para tomar as medidas necessárias. Se possível, essas tarefas devem ser automatizadas. Quanto mais papels e grupos que existem, o mais provável é que o conflito do papel irá surgir. Conflito papel neste contexto se refere a uma situação em que dois papéis ou grupos específicos, se pertencer a um único usuário, vai criar problemas com a separação de funções ou conflito de interesse. Exemplos incluem: • Um papel requer acesso detalhado, enquanto um outro papel que impede o acesso • Dois papéis permitir que um usuário para executar duas tarefas que não devem ser combinados (por exemplo, um empreiteiro pode registrar sua folha de tempo para uma projeto e aprovar todos os pagamentos no trabalho para o mesmo projeto). Conflito papel pode ser evitada pela criação cuidadosa de funções e grupos, mas mais frequentemente são causadas por políticas e decisões tomadas fora do Operação de Serviço - Seja pela empresa ou por diferentes equipes de projeto de trabalho durante Design de Serviços. Em cada caso, o conflito deve ser documentado e encaminhado para a das partes interessadass para resolver. Sempre funções e grupos são definidos, é possível que eles poderiam ser definidas de forma demasiado ampla ou demasiado restritiva. Haverá sempre os usuários que precisam de algo um pouco diferente dos papéis pré-definidos. Nestes casos, é possível a utilização de papéis padrão e, em seguida, adicionar ou subtrair direitos específicos, conforme necessário - semelhante ao conceito de linhas de base e Variantes em Gerenciamento da Configuração (Ver Transição de Serviço publicação). No entanto, a decisão de fazer isso não está nas mãos do indivíduo operacional funcionários. Cada exceção deve ser coordenado pela Gerência de Acesso e aprovado através do processo de origem. Gerenciamento de Acesso deve realizar um regular rever do papels e grupos que ele criou e gerenciar para garantir que eles são apropriados para os serviços que ele oferece e apóia - e obsoletos ou indesejados papéis / grupos devem ser removidos. ITIL V3 - Operação de Serviço - Página: 135 de 423
    • 4.5.5.4 status de identidade de Monitoramento Como usuárioO trabalho na organização, Seus papéis mudam e assim também fazer as suas necessidades de acesso aos serviços. Exemplos de alterações incluem: • Mudanças de emprego. Neste caso, o utilizador terá possivelmente necessidade de acesso a serviços diferentes ou adicionais. • Promoções ou rebaixamentos. O usuário provavelmente vai usar o mesmo conjunto de serviços, mas terá acesso a diferentes níveis de funcionalidade ou dados. • Transferências. Nesta situação, o utilizador pode ter acesso a exactamente o mesmo conjunto de serviços, mas de uma região diferente, com trabalho diferente práticas e diferentes conjuntos de dados. • Demissão ou morte. De acesso precisa de ser completamente removida para impedir que o nome de utilizador a ser utilizado como um segurança brecha. • Aposentadoria. Em muitas organizações, um empregado que se aposenta ainda pode ter acesso a um conjunto limitado de serviços, incluindo benefícios sistemas ou sistemas que lhes permitem adquirir os produtos da empresa a uma taxa reduzida. • Ação disciplinar. Em alguns casos, a organização exigirá uma restrição temporária para impedir o utilizador de aceder a alguns ou a todos os serviços que normalmente têm acesso. Deve haver um recurso no processo e ferramentas para fazer isso, ao invés de ter que excluir e restabelecer o acesso do usuário direitos. • Demissões. Se um trabalhador é demitido ou contratado, ou quando uma ação legal seja tomada contra um cliente (Por exemplo, para falta de pagamento para produtos comprados na internet), o acesso deve ser revogada imediatamente. Além disso, gerenciamento de acesso, trabalhando em conjunto com a Gestão de Segurança da Informação, deve tomar medidas activas para prevenir e detectar ações maliciosas contra a organização daquele usuário. Gerenciamento de Acesso deve entender e documentar o usuário típico Ciclo de Vida para cada tipo de usuário e usá-lo para automatizar o processo. As ferramentas de gerenciamento de acesso deve fornecer recursos que permitem que um usuário para ser movida de um estado para outro, ou de um grupo para outro, de forma fácil e com um auditar trilha. 4.5.5.5 acesso acompanhamento e rastreamento Gestão de acesso não só deve responder às solicitações. Também é responsável por garantir que os direitos que eles têm prestado estão sendo usados corretamente. ITIL V3 - Operação de Serviço - Página: 136 de 423
    • A este respeito, monitorização e controlo de acesso devem ser incluídos no monitoramento atividades de todos os técnicos e Aplicação de Gestão de funçãos e tudo Operação de Serviço processos. As exceções devem ser tratadas por Gerenciamento de Incidentes, Possivelmente usando Incident Modelos projetado especificamente para lidar com o abuso de direitos de acesso. Deve notar-se que a visibilidade de tais acções deve ser restrito. Tornar esta informação disponível a todos os que têm acesso ao Gerenciamento de Incidentes sistema irá expor vulnerabilidades. Gestão de Segurança da Informação desempenha um papel vital papel para detectar o acesso não autorizado e comparando-o com o direitos que foram fornecidos pela Gerenciamento de Acesso. Isso vai exigir o envolvimento de gerenciamento de acesso na definição dos parâmetros para uso em ferramentas de detecção de intrusão. Gerenciamento de acesso também pode ser necessária para fornecer um registro de acesso para serviços específicos durante as investigações forenses. Se um usuário é suspeito de violação de política, Uso inadequado de recursos, ou utilização fraudulenta de dados, gerenciamento de acesso pode ser obrigado a fornecer provas de datas, horas e até mesmo conteúdo de acesso do usuário aos serviços específicos. Isto é normalmente fornecido pelo Operacional pessoal de que serviço, Mas trabalhando como parte do Gerenciamento de Acesso processo. 4.5.5.6 Remoção ou restritiva de direitos Assim como Access Management fornece direitos Para usar um serviço, também é responsável pela revogação de tais direitos. Novamente, isto não é uma decisão de que faz por si próprio. Em vez disso, ele irá executar as decisões e políticas feitas durante Estratégia de Serviço e decisões de design e também de gestores no organização. Removendo o acesso geralmente é feito nas seguintes circunstâncias: • Morte • Renúncia • Demissão • Quando o usuário mudou os papéis e não requer mais o acesso ao serviço • Transferência ou viajar para uma área onde o acesso regional diferente se aplica. Em outros casos, não é necessário para remover o acesso, mas apenas para proporcionar restrições mais severas. Estas podem incluir a redução do nível de ITIL V3 - Operação de Serviço - Página: 137 de 423
    • tempo, ou a duração do acesso. Situações em que o acesso deve ser restrito incluem: • Quando o usuário mudou de função ou foi rebaixado e já não requer o mesmo nível de acesso • Quando o usuário está sob investigação, mas ainda requer acesso a serviços básicos, tais como e-mail. Neste caso seu e-mail pode ser objecto de digitalização adicional (mas isso precisa ser tratado com muito cuidado e em total conformidade com a organização do política de segurança) • Quando um usuário está fora da organização em uma missão temporária e não vai exigir o acesso a esse serviço por algum tempo. 4.5.6 Triggers interfaces de entrada e saída / inter-processo Gerenciamento de Acesso é desencadeada por um pedido de um ou mais usuários para acessar um serviço ou grupo de serviços. Isto poderia ser provenientes de qualquer dos seguintes: • Uma RFC. Este é mais freqüentemente usado para apresentações em grande escala de serviços ou atualizações onde o direitos de um número significativo de usuários precisam ser atualizados como parte do projeto. • ASolicitação de Serviço. Isso geralmente é iniciado através do Service Desk, Ou diretamente no Cumprimento de Requisição sistema, E executado pelo técnico relevante ou Aplicação de Gestão de equipes. • A pedido dos humanos adequados pessoal Gestão de Recursos (que deve ser canalizada através do Service Desk). Isto é normalmente gerada, como parte do processo para contratação, promoção, realocação e rescisão ou aposentadoria. • O pedido do gerente de um departamento, que poderia ser a realização de um RH papel, Ou que poderia ter tomado a decisão de começar a usar um serviço pela primeira vez. Gerenciamento de Acesso deve ser ligada aos processos de Recursos Humanos para verificar a usuário'S identificar, bem como para garantir que eles têm direito aos serviços que estão sendo solicitadas. Gestão de Segurança da Informação é uma tecla motorista para Gerenciamento de Acesso vez que irá proporcionar o segurança e as políticas de proteção de dados e ferramentas necessárias para executar Gerenciamento de Acesso. Gestão da Mudança desempenha um importante papel como meio para controlar os pedidos de acesso reais. Isto é porque qualquer pedido de acesso a um serviço é uma mudar, Embora seja geralmente processada como um Mudança Padrão ou Solicitação de Serviço (Possivelmente usando uma modelo) Uma vez que os critérios de acesso foram acordados por SLM. ITIL V3 - Operação de Serviço - Página: 138 de 423
    • SLM mantém a acordos para o acesso a cada serviço. Isso irá incluir os critérios de quem tem direito de acesso a cada serviço, o que o custar de que o acesso será, se o nível adequado e que o acesso será concedido a diferentes tipos de usuário (por exemplo, gerentes ou funcionários). Há também uma forte relação entre a Gestão de Acesso e Gerenciamento da Configuração. O CMS pode ser usado para armazenamento de dados e interrogados para determinar os detalhes de acesso atuais. 4.5.7 Gestão da Informação 4.5.7.1 Identidade O identidade de um usuário é a informação sobre eles que os distingue como um indivíduo e que verifica seu status dentro da organização. Por definição, a identidade de um usuário é único para o usuário. Uma vez que há casos em que dois usuários compartilham um pedaço comum de informação (por exemplo, eles têm o mesmo nome), a identidade é geralmente estabelecido usando mais do que um pedaço de informação, por exemplo: • Nome • Endereço • Detalhes de contato, por exemplo, de telefone, endereço de e-mail, etc • Documentação física, por exemplo, carteira de motorista, passaporte, certidão de casamento, etc • Os números que se referem a um documento ou uma entrada numa base de dados, por exemplo, número de funcionários, número de contribuinte, número de identidade do governo, o número de carteira de motorista, etc • A informação biométrica, por exemplo, impressões digitais, imagens da retina, padrões de reconhecimento de voz, DNA, etc • Data de validade (se aplicável). A identidade do usuário é fornecida para qualquer pessoa com um legítimo exigência para acessar De serviços de TIs ou informação organizacional. Estas podem incluir: • Funcionários • Empreiteiros • Vendedor pessoal (por exemplo, gerente de contass, pessoal de apoio, etc) • Clientes (especialmente na compra de produtos ou serviços através da Internet). A maioria das organizações vai verificar uma usuário'S identidade antes de se juntar a organização solicitando um subconjunto da informação acima. O mais ITIL V3 - Operação de Serviço - Página: 139 de 423
    • seguro a organização, os tipos mais informações são necessárias e quanto mais completamente eles são verificados. Muitas organizações serão confrontados com a necessidade de acesso direitos para pessoal temporário ou ocasional ou contratantes /fornecedors. A gestão do acesso a esse pessoal muitas vezes se torna problemático - o acesso de fechamento após o uso é muitas vezes tão difícil de gerir, ou mais, do que proporcionar acesso inicialmente. Bem definido procedimentos entre TI e RH deve ser estabelecido que incluem prova de falhas cheques que garantem direitos de acesso são removidos imediatamente que já não se justificam ou requerido. Quando um usuário tem acesso a um aplicação, Que já deveria ter sido estabelecido pela organização (geralmente os Recursos Humanos ou Segurança Departamento) que o usuário é quem dizem que são. Neste ponto, todas as informações que está arquivado eo arquivo está associado a uma identidade corporativa, geralmente um número de empregado ou contratante e uma identidade que pode ser usado para acessar corporativo recursos e informações, geralmente uma identidade de usuário ou 'username' e uma senha de associado. 4.5.7.2 Os usuários, grupos, funções e grupos de serviço Enquanto cada usuário tem uma identidade individual, e cada De serviços de TI pode ser visto como uma entidade em seu próprio direito, muitas vezes é útil para agrupá-los de modo que eles podem ser gerenciados mais facilmente. Às vezes, os termos "perfil do usuário"Ou" modelo de usuário 'ou' usuário papel'São usados para descrever este tipo de agrupamento. A maioria das organizações tem um conjunto padrão de serviços para todos os usuários individuais, independentemente da sua posição ou emprego (excluindo clientes - que não têm qualquer visibilidade aos serviços e processos internos). Estas incluem serviços como mensagens, automação de escritório, suporte a desktop, telefonia, etc Novos usuários são automaticamente fornecidos com direitos de usar esses serviços. No entanto, a maioria dos usuários também têm algum papel especializado que eles desempenham. Por exemplo, para além dos serviços padrão, o utilizador também executa uma função de gestão de marketing, o que requer que eles têm acesso a alguns especializada de marketing e financeiros modelagem ferramentas e dados. Alguns grupos podem ter única exigências - como campo ou trabalhadores domésticos que podem ter que discar ou usar Virtual Private Network (VPN), com implicações de segurança que podem ter de ser mais bem gerenciado. ITIL V3 - Operação de Serviço - Página: 140 de 423
    • Para tornar mais fácil para Gerenciamento de Acesso para fornecer os direitos apropriados, ele usa um catálogo de todas as funções na organização e quais os serviços que suportam cada função. Este catálogo de funções deverá ser compilado e mantido pela Administração Acesso em conjunto com o RH e, muitas vezes, ser automatizado no Serviço de Diretórios ferramentas (ver secção 5.8). Além de jogar diferentes papéis, os usuários também podem pertencer a diferentes grupos. Por exemplo, todos os contratantes são obrigados a registrar seus quadros de horários em um cartão de tempo dedicado Sistema, Que não é usado pelos funcionários. Gerenciamento de Acesso irá avaliar todas as funções que um usuário desempenha, bem como os grupos que eles pertencem e garantir que eles fornecem direitos de usar todos os serviços associados. Nota: Todos os dados sobre os usuários estarão sujeitos a legislação de protecção de dados (isso existe na maioria das localizações geográficas de uma forma ou outra) por isso deve ser tratada e protegida como parte dos procedimentos de segurança da organização. 4.5.8 Métricas Métricos que podem ser usados para medir a eficiência e eficácia de Gerenciamento de Acesso incluem: • Número de pedidos de acesso (Solicitação de Serviço, RFC, etc) • Instâncias de acesso concedido, por serviço,usuário, Departamento, etc • Instâncias de acesso concedida pelo departamento ou individuais concessão de direitos • Número de incidentes que requerem uma redefinição do acesso direitos • Número de incidentes causados por configurações de acesso incorretas. 4.5.9 Desafios, Fatores Críticos de Sucesso e riscos Condições para sucesso Gerenciamento de Acesso incluem: • A capacidade de verificar a identidade de um usuário (que a pessoa é que eles dizem que são) • A capacidade de verificar a identidade da pessoa que aprova ou organismo • A capacidade de verificar que um utilizador se qualifica para o acesso a um serviço específico • A capacidade de vincular os direitos de acesso múltiplo a um usuário individual • A capacidade para determinar o estado do utilizador em qualquer altura (por exemplo, para determinar se eles ainda são empregados do organização quando fazer logon em um sistema) ITIL V3 - Operação de Serviço - Página: 141 de 423
    • • A capacidade de gerenciar mudanças acesso de um usuário exigências • A capacidade de restringir direitos de acesso a usuários não autorizados • Um banco de dados de todos os usuários e os direitos que foram concedidos. ITIL V3 - Operação de Serviço - Página: 142 de 423
    • 4,6 As atividades operacionais de processos cobertos de fases do ciclo de vida de outros 4.6.1 Gestão da Mudança Gestão da Mudança é primeiramente coberta no Transição de Serviço publicação, mas há alguns aspectos da gestão da mudança que Operação de Serviço funcionários estarão envolvidos em uma base dia-a-dia. Estes incluem: • Levantar e submeter RFCs como necessário para tratar de questões operação de serviço • Participação em reuniões ou CAB CAB / CE para garantir que a Operação de Serviço riscos, questões e opiniões são tidas em conta • Mudanças de execução, dirigidos pelo Gerenciamento de Mudanças, onde envolvem Operação de Serviço componente ou serviços • Fazendo as mudanças como dirigido por Gestão da Mudança onde eles envolvem Operação de Serviço componente ou serviços • Ajudar a definir e manter alterar modelos relativas à Operação de Serviço componentes ou serviços • Receber alteração de horários e garantir que todo o pessoal Operação de Serviço estão cientes e preparados para todas as alterações relevantes • Usando o Gerenciamento de Mudança processo por norma, operacionalTipo muda. 4.6.2 Gerenciamento da Configuração Gerenciamento da Configuração é primeiramente coberta no Transição de Serviço publicação, mas há alguns aspectos do Gerenciamento de Configuração que o pessoal Operação de Serviço serão envolvidos em uma base dia-a-dia. Estes incluem: • Gerenciamento de Configuração informar de quaisquer discrepâncias encontradas entre qualquer CIs e do CMS • Fazendo as alterações necessárias para corrigir eventuais discrepâncias, sob a autoridade do Gerenciamento da Configuração, Onde se envolve quaisquer componentes do serviço de operação ou serviços. Responsabilidade pela actualização do CMS permanece com gerenciamento de configuração, mas em alguns casos equipe de operações pode ser solicitado, sob a direção de Gerenciamento de Configuração, para atualizar relaçãos, ou até mesmo para adicionar novo CIS ou marca CIS como 'eliminados' no CMS, se essas atualizações são relacionadas às atividades operacionais efetivamente realizadas pela equipe de Operações. ITIL V3 - Operação de Serviço - Página: 143 de 423
    • 4.6.3 Gerenciamento de Liberação e Implantação Gerenciamento de Liberação e Implantação é principalmente coberta na publicação Transição de Serviço, mas há alguns aspectos deste processo que o pessoal Operação de Serviço será envolvido em uma base dia-a-dia. Estes podem incluir: • Reais ações de implementação em relação ao desenvolvimento de novo liberars, sob a direção de Gerenciamento de Liberação e Implantação, onde eles se relacionam com os componentes de serviço de operação ou serviços • A participação no planejamento estágios de grandes lançamentos para aconselhar sobre questões operação de serviço • A movimentação física de instituições de crédito de / para o DML como necessário para cumprir seu operacional papels - ao aderir ao lançamento relevante e Gestão de Implantação procedimentos, como garantir que todos os itens são devidamente reservado e para trás dentro 4.6.4 Gerenciamento da Capacidade Gerenciamento da Capacidade deveria operar em três níveis: Gerenciamento da Capacidade de negócios,Gerenciamento da Capacidade de serviço e Recurso Gerenciamento da Capacidade. • Gerenciamento da Capacidade de negócios envolve o trabalho com a empresa para planejar e antecipar tanto de longo prazo estratégico questões e de curto prazo tático iniciativas que possam vir a ter um impacto em TI capacidade. • Gerenciamento da Capacidade de serviço é sobre a compreensão das características de cada um dos De serviços de TIs, e, em seguida, a exigência de que os diferentes tipos de usuários ou transaçãos ter sobre a infra-estrutura subjacente - e como estes variam ao longo do tempo e pode ser afetado pelo negócio mudar. • Recurso Gerenciamento da Capacidade envolve a compreensão da atuação características e capacidades e níveis de utilização de correntes de todos os aspectos técnicos componentes (IC) que compõem o Infraestrutura de TI, E prever a impacto de quaisquer alterações ou tendências. Muitas dessas atividades são de caráter estratégico ou de longo prazo planejamento natureza e são abordados na Estratégia de Serviço, Design de Serviços e Transição de Serviço publicações. No entanto, há um número de operacional Capacidade de actividades de gestão que devem ser executadas em uma base regular e contínua, como parte de Operação de Serviço. Estes incluem os seguintes. ITIL V3 - Operação de Serviço - Página: 144 de 423
    • 4.6.4.1 Capacidade e Performance Monitoring Todos componentes da Infraestrutura de TI deve ser continuamente monitorado (em conjunto com Gestão de Eventos) De modo que qualquer potencial problemas ou tendências podem ser identificadas antes falhas ou atuação degradação ocorre. Idealmente, tais monitoramento deve ser automatizada e limiars deve ser definido de modo que a exceção alertars são criados em tempo de permitir adequada evitando ou recuperação ação a ser tomada antes do impacto adverso ocorre. Os componentes e os elementos a serem monitorizadas irá variar dependendo da infra-estrutura a ser utilizado, mas será tipicamente incluem: • Utilização da CPU (global e discriminadas por sistema/serviço uso) • Utilização de memória • Taxas de ES (física e buffer) e utilização de dispositivo • Comprimento da fila (máxima e média) • Utilização arquivo de armazenamento (discos, partições segmentos) • Aplicaçãos (rendimento taxas, taxas de falha) • Bancos de dados (utilização, registro fechaduras, indexação, de contenção) • Rede transação taxas, erro e repetir as taxas de • Transação tempo de resposta • Duração perfis lote • Internet / intranet do site / página taxas de acerto • Internet tempos de resposta (externos e internos para firewalls) • Número de sistema / aplicação de log-ons e usuários simultâneos • Número de nós de rede em uso, e os níveis de utilização. Existem diferentes tipos de ferramentas de monitoramento necessários para coletar e interpretar dados em cada nível. Por exemplo, algumas ferramentas permitem o desempenho de transações de negócios a ser monitorado, enquanto outros vão monitorar CI comportamento. Gerenciamento da Capacidade deve configurar e calibrar alarme limiars (quando necessário, em conjunto com Gestão de Eventos, Como é muitas vezes ferramentas de monitorização de eventos que podem ser utilizados), de modo que a correcta alertar níveis são estabelecidos, e que qualquer filtragem é estabelecido como necessário de modo a que apenas significativo eventos são levantadas. Sem essa filtragem é possível que a "informação apenas 'alertas podem obscurecer alertas mais significativos que exigem atenção imediata. Além disso, é possível que grave falhas para causar "alerta tempestades" devido a volumes muito altos de alertas repetidos, que novamente deve ser filtrada para que as mensagens mais significativas não são obscurecidos. ITIL V3 - Operação de Serviço - Página: 145 de 423
    • Pode ser apropriado para uso externo, de terceiros, monitoramento capacidades para alguns itens de configuração ou componentes da Infraestrutura de TI (Por exemplo, sites de Internet Key / páginas). Gestão de capacidade deve ser envolvido em ajudar especificar e selecionar qualquer capacidade de acompanhamento e na integração dos resultados ou eventuais alertas com acompanhamento outro e manipulação sistemas. Gerenciamento da Capacidade de trabalhar com todas as medidas adequadas grupo de apoios para tomar decisões sobre onde os alarmes são encaminhadas e em escalada caminhos e prazos. As indicações deverão ser registrados no Service Desk bem como para o pessoal de apoio apropriado, de modo que adequado Grave incidentes pode ser levantado para uma permanente registro do evento existe - e equipe de Service Desk ter uma visão de como o grupo de apoio(S) está lidando com a culpa e pode intervir se necessário. Fabricantes alegou atuação capacidades e concordou meta de nível de serviços, juntamente com o desempenho histórico real monitorados e os dados de capacidade, devem ser utilizados para definir níveis de alerta. Isto pode necessitar de ser um processo iterativo processo inicialmente, realizar alguns ajustes de tentativa e erro, até que os níveis corretos sejam alcançados. Nota: Gerenciamento da Capacidade pode ter que se envolver no capacidade exigências e capacidades de IT Service Management. Se o organização A equipe tem bastante serviço para lidar com a taxa de incidentes; se a estrutura CAB pode lidar com o número de mudanças que está sendo solicitada a rever e aprovar, se ferramentas de suporte pode lidar com o volume de dados que estão sendo coletados são questões capacidade de gestão, que a equipe de Gestão de Capacidade podem ser feitas para ajudar a investigar e responder. 4.6.4.2 capacidade ou manipulação desempenho incidentes relacionados Se um alerta é acionado, ou um incidente é gerado no Service Desk, causada por uma capacidade de corrente ou em curso ou Gestão de Desempenho problema, Gerenciamento de Capacidade deve envolver-se para identificar a causa e encontrar uma resolução. Trabalhando em conjunto com a adequada suporte técnico grupos, e ao lado Gerenciamento de Problemas, Todas as investigações necessárias devem ser realizados para detectar exatamente o que deu errado eo que é necessário para corrigir a situação. Pode ser necessário mudar a monitorização mais detalhada durante a fase de investigação para determinar a causa exata. O monitoramento é geralmente definida em um "fundo" nível em circunstâncias normais devido à grande quantidade de dados que podem ser gerados e evitar colocar muito alto um fardo sobre a infra-estrutura de TI - mas quando as dificuldades específicas ITIL V3 - Operação de Serviço - Página: 146 de 423
    • estão sendo investigados monitoramento mais detalhado pode ser necessária para identificar a causa exata. Quando uma solução ou uma solução potencial, foi encontrado, as alterações necessárias para resolver o problema deve ser aprovada através formais Gestão da Mudança antes da implementação. Se a falha está causando graves perturbações e uma resolução de urgência é necessária, urgente mudar processo deve ser usado. É muito importante que não "afinação"Ocorre sem submissão através do Gerenciamento de Mudança, pois mesmo aparentemente pequenos ajustes muitas vezes pode ter grandes efeitos cumulativos - por vezes em toda a infraestrutura de TI inteira. 4.6.4.3 Capacidade e tendências de desempenho Gerenciamento da Capacidade tem um papel a desempenhar na identificação de qualquer capacidade ou as tendências de desempenho como eles se tornam perceptíveis. Mais pormenores sobre as acções necessárias para resolver tais tendências estão incluídos no Melhoria de Serviço Continuada publicação. 4.6.4.4 Armazenamento de dados de gerenciamento de capacidade Grandes quantidades de dados são usualmente gerados através capacidade e atuação monitoramento. Monitoramento de metros e tabelas de apenas alguns poucos kbytes cada um pode crescido rapidamente em arquivos enormes se muitos componentes estão a ser monitorizados em intervalos relativamente curtos. Outro problema com o controlo muito curto prazo é de que não é possível a obtenção de uma informação significativa sem olhar ao longo de um período mais longo. Por exemplo, um único instantâneo de um processador irá mostrar o dispositivo a ser ou "ocupado" ou "inactivo" - mas um resumo sobre, por exemplo, um período de 5 minutos irá mostrar o nível médio de utilização durante o mesmo período, o que é um tanto medida mais significativa se o dispositivo é capaz de trabalhar confortavelmente, ou se o desempenho potencial problemas são prováveis de ocorrer. Em qualquer organização é provável que os instrumentos de controlo utilizados irá variar muito - com uma combinação de sistemaFerramentas específicas, muitos deles parte do sistema operacional básico, e ferramentas especializadas de monitoramento a ser utilizados. A fim de coordenar os dados que estão sendo gerados e permitir a retenção de dados úteis para fins de análise e tendências, alguma forma de repositório central de dados para a realização desta resumo é necessário: um Gerenciamento da Capacidade Sistema de Informação (CMIS). O formato, localização e projeto dessa base de dados deve ser planejado e implementado com antecedência - ver o Design de Serviços publicação para ITIL V3 - Operação de Serviço - Página: 147 de 423
    • mais detalhes - mas haverá algum operacional para lidar com aspectos, tais como limpeza de banco de dados e apoios. 4.6.4.5 Gerenciamento da Demanda Gerenciamento da Demanda é o nome dado a uma série de técnicas que podem ser usadas para modificar a procura de um determinado recurso ou serviço. Algumas técnicas de gestão da procura pode ser planejado com antecedência, e estes são abordados com mais detalhes na publicação Service Design. No entanto, há outros aspectos da gestão da procura, que são de natureza mais operacional, exigindo mais curto prazo a ação. Se, por exemplo, o desempenho de um determinado serviço, está a causar preocupação, a curto prazo e restrições simultaneidade de usuários são necessárias para permitir melhorias de desempenho para um pequeno grupo restrito, em seguida, Operação de Serviço funçãos terá que tomar medidas para implementar tais restrições - geralmente acompanhada de acções concorrentes para implementar o registro fora de usuários que estiveram inativos por um período de tempo acordado para liberar recursos para outros. 4.6.4.6 Workload Management Pode haver ocasiões em que a otimização dos recursos de infra-estrutura é necessária para manter ou melhorar o desempenho ou rendimento. Isso muitas vezes pode ser feito através de Workload Gestão, que é um termo genérico para cobrir tais ações como: • Reprogramação de um determinado serviço ou carga de trabalho para executar em um horário diferente do dia, ou do dia da semana, etc (geralmente longe do pico vezes para fora do pico janelas) - que, muitas vezes, significa ter que fazer ajustes para trabalho de agendamento de software. • Mover um serviço ou carga de trabalho de um local ou conjunto de CIs para outro - muitas vezes para equilibrar a utilização ou tráfego. • Virtualização técnica: criação e utilização de sistemas de virtualização para permitir o movimento de processamento em torno da infra-estrutura para dar um melhor desempenho /resiliência de um modo dinâmico. • Limitar ou mover demanda de recursos por meio de técnicas de gestão da demanda (ver acima e também a publicação de Desenho de Serviço). Só será possível gerenciar cargas de trabalho de forma eficaz se existe um bom entendimento de que as cargas de trabalho será executado em que momento e quanto a utilização de recursos cada lugares de carga de trabalho sobre a infra- estrutura de TI. Diligente monitoramento e análise de carga de trabalhos é necessário, portanto, uma base operacional em andamento. ITIL V3 - Operação de Serviço - Página: 148 de 423
    • 4.6.4.7 Modelação e aplicações de dimensionamento Modelagem e / ou dimensionamento de novos serviços e / ou aplicaçãos devem, se adequado, ser feito durante o planejamento fases e de transição - ver a Design de Serviços e Transição de Serviço publicações. No entanto, o Operação de Serviço funçãos têm uma papel a desempenhar na avaliação da precisão das previsões e realimentando quaisquer problemas ou discrepâncias. 4.6.4.8 Planejamento de Capacidade Durante Design de Serviços e Transição de Serviço, o capacidade exigências de De serviços de TIs são calculados. A prospectiva plano de capacidade deve ser mantido e atualizado regularmente e Operação de Serviço terá um papel a desempenhar. Tal plano deve olhar para a frente até dois anos ou mais, mas deve ser revered regularmente a cada três a 12 meses, dependendo da volatilidade e dos recursos disponíveis. O plano deve ser ligada ao organizaçãoO ciclo de planejamento financeiro, de modo que qualquer despesa necessária para atualizações de infra-estrutura, melhorias ou adições podem ser incluídos no orçamento estimativas e aprovados com antecedência. O plano deve prever o futuro, mas também deve examinar e informar sobre as previsões anteriores, particularmente para dar alguma confiança nas previsões futuras. Onde as discrepâncias foram encontradas, elas devem ser explicadas e medidas correctivas futuro descrito. O Plano de Capacidade pode geralmente cobrem: • Atuais detalhes de desempenho e utilização, com as recentes tendências para todos os itens de configuração chave, incluindo • Redes de backbone • LANs • Mainframes (se ainda utilizado) • Chave servidors • Principais dispositivos de armazenamento de dados • Equipamentos selecionados desktop (representante) e laptop • Principais sites • Bases de dados-chave • Chave aplicaçãos • Operacional capacidade - eletricidade espaço, capacidade, ambientais (ar-condicionado), com peso de piso, a geração de calor e saída, a demanda elétrica e abastecimento de água e etc • Meios magnéticos. • Estimado atuação e utilização para todos os CIs tal durante o período de planejamento (por exemplo, os próximos três meses) ITIL V3 - Operação de Serviço - Página: 149 de 423
    • • Os dados comparativos com as estimativas anteriores - para permitir que a confiança nas estimativas futuras para ser julgado • Relatórios sobre qualquer específico capacidade dificuldades encontradas no período passado, com detalhes de recuperação e as ações preventivas tomadas para o futuro • Pormenores de quaisquer atualizações necessárias ou dos contratos necessários e previstos para o futuro, com indicativos custars e prazos. • Quaisquer riscos capacidade potencial que provavelmente - com sugerido contramedidas caso venham a ocorrer. 4.6.5 Gerenciamento de Disponibilidade Durante Design de Serviços e Transição de Serviço,De serviços de TIs são concebidos para disponibilidade e recuperação. Operação de Serviço é responsável por realmente fazer o serviço de TI disponíveis para o especificado usuários no momento necessário e nos níveis acordados. Durante operação de serviço as equipes de TI e usuários estão na melhor posição para detectar se os serviços realmente cumprir o acordado exigências, e se o projeto destes serviços é eficaz. O que parece ser uma boa idéia durante a fase de projeto não pode realmente ser prático ou ótima. A experiência dos usuários e operacional funçãos faz uma entrada principal para a melhoria contínua dos serviços existentes e do design. No entanto, há um número de desafios com acesso a este conhecimento: • A maioria das experiências das equipes operacionais e os usuários são ou informal, ou se espalhar através de múltiplas fontes. • O processo para recolha e tratamento destes dados precisa ser formalizado. • Usuários e do pessoal operacional geralmente são totalmente ocupado com suas atividades regulares e tarefas e é muito difícil para eles se envolver em regular planejamento e atividades de design. Um argumento freqüentemente feita aqui é que se o projeto é melhorada, as equipes operacionais serão menos ocupado resolvendo problemas e, portanto, têm mais tempo para se envolver em atividades de projeto. No entanto, prática mostra que, assim como o pessoal são liberados, eles muitas vezes se tornam o alvo de exercícios de redução de efectivos. Dito isto, há três principais oportunidades para o pessoal operacional a ser envolvidos em Melhoria de disponibilidade, uma vez que estes são geralmente vistos como parte da sua responsabilidade em curso: • Comente das atividades de manutenção. Design de Serviços irá definir as programações de manutenção detalhada e actividades, que são ITIL V3 - Operação de Serviço - Página: 150 de 423
    • necessários para mantê-lo funcionando serviços no nível requerido de atuação e disponibilidade. Comparação regular de atividades reais de manutenção e horas com a planos vai destacar as áreas potenciais de melhoria. Uma das fontes dessas informações é uma revisão de se Objetivo de manutenção do serviços foram atendidas e, se não, por que não. • Principais opiniões problema. Problemas podem ser o resultado de qualquer número de factores, um dos quais é má concepção. Opiniões problema, portanto, pode incluir oportunidades para identificar melhorias para o design de serviços de TI, que incluem disponibilidade e melhoria da capacidade. • Envolvimento em iniciativas específicas, utilizando técnicas como a Análise de Falhas de Serviço (SFA), Componente Análise de Impacto falha (ACIA), ou Análise da Árvore de Falhas (FTA) ou como membros de Observation técnica (TO) atividades - como parte do acompanhamento às principais problemas ou como parte de um processo contínuo serviço melhoria programa, Em colaboração com a dedicada Gerenciamento de Disponibilidade pessoal. Estes Gerenciamento de Disponibilidade técnicas são explicadas em mais detalhe no Design de Serviços publicação. Pode haver ocasiões em que Operacional Equipe se precisa tempo de inatividade de um ou mais serviços para que possam realizar suas atividades operacionais ou de manutenção - que pode impacto sobre a disponibilidade se não for devidamente programado e controlado. Em tais casos, deve entrar em contacto com SLM e equipe de gerenciamento de disponibilidade - que vai negociar com os usuários de negócios /, muitas vezes usando o Service Desk para efectuar esta papel, Concordar e agendar tais atividades. 4.6.6 Gestão do Conhecimento É de vital importância que todos os dados e informações que podem ser úteis para o futuro Operação de Serviço atividades são devidamente recolhidos, armazenados e avaliados. Dados relevantes, métricos e informação deve ser passada em cima da cadeia de gestão e de outro Serviço Ciclo de Vida fases para que possa alimentar as camadas de conhecimento e sabedoria do organização'S Serviço do Sistema de Gestão do Conhecimento, As estruturas de que têm de ser definidas em Estratégia de Serviço e Serviço de Design e refinado em Melhoria de Serviço Continuada (ver outro ITIL publicações nesta série). Repositórios chave da operação de serviço, que foram citados em outros lugares, são a CMS ea BDEC, mas isso deve ser ampliado para incluir a totalidade do Serviço de Operação das equipes e departamentos "documentação, tais como operaçãos manuais, procedimentos manuais, instrução de trabalhos, etc ITIL V3 - Operação de Serviço - Página: 151 de 423
    • 4.6.7 Gerenciamento Financeiro para Serviços de TI Operação de Serviço equipe deve participar e apoiar o global de TI orçamentação e contabilidade sistema - E pode ser ativamente envolvidos em qualquer carregamento sistema que podem estar no local. Adequado planejamento é necessário para que despesas de capital (Capex) e despesas operacionais (Opex) orçamento estimativas podem ser preparadas e concordou em boa hora para atender os ciclos orçamentais. O Gerente de Operação de Serviço também deve ser envolvido em regular, pelo menos mensalmente, revers de despesas contra orçamentos - como parte do orçamento de TI em andamento e contabilidade processo. Qualquer irregularidade deve ser identificado e feito os ajustes necessários. Todas as despesas comprometido deve passar pela organização de sistema de ordem de compra, de modo que os compromissos podem ser acumulados e verificações adequadas devem ser feitas em todos os bens recebidos para que as faturas e pagamentos podem ser corretamente autorizado - ou discrepâncias investigadas e corrigidas. Deve notar-se que alguns propôs custar reduções por o negócio pode realmente aumentar os custos de TI, ou pelo menos Custo unitários. Cuidados devem ser tomados para garantir que a TI está envolvida na discussão de todas as medidas de redução de custos e contribuir para as decisões globais. Gestão Financeira é tratada em pormenor na publicação Estratégia de Serviço. 4.6.8 Gestão da Continuidade de Serviço de TI Funções de operação de serviços são responsáveis pelo teste e execução de sistema e serviço recuperação planos, tal como determinado no TI Plano de Continuidade do Serviços para a organização. Além disso, os gerentes de todas as funções de operação de serviço devem estar na equipe de Coordenação de Negócios Continuidade Central. Isto é discutido em detalhe na estratégia de serviço e design de serviço e não serão aqui repetidas, excepto para indicar que é importante que a operação de serviço funçãos devem estar envolvidos nas seguintes áreas: • Avaliação de risco, Usando seu conhecimento da infra-estrutura e técnicas como a ACIA e acesso à informação no CMS para identificar pontos únicos de falha ou outras de altarisco situações • Execução de qualquer Gestão de Risco medidas que estão acordados, por exemplo implementação de contramedidas, ou aumentada resiliência para componentes das infra-estruturas, etc • Assistência por escrito o real recuperação planos para sistemas e serviços sob sua controlar ITIL V3 - Operação de Serviço - Página: 152 de 423
    • • Participação nos testes dos planos (tais como envolvimento em off-site de testes etc simulações,) em uma base contínua, sob a direção do Gerente de Continuidade dos Serviços de TI (ITSCM) • Manutenção contínua dos planos sob o controle do GCSTI e Gestão da Mudança • Participação em campanhas de formação e sensibilização para garantir que eles são capazes de executar os planos e compreender a sua papels em um desastre • O Service Desk irá desempenhar um papel fundamental na comunicação com a equipe, clientes e usuários durante um desastre real ITIL V3 - Operação de Serviço - Página: 153 de 423
    • 5 atividades operação comum Serviço Capítulo 4 tratadas com os processos necessários para a eficaz Operação de Serviço e no Capítulo 6, serão abordados os aspectos organizacionais. Este capítulo se concentra em um número de operacional actividades que assegurem que a tecnologia está alinhado com o Serviço geral e Processo objetivos. Essas atividades são às vezes descritos como processos, mas na realidade são conjuntos de atividades técnicas especializadas todas destinadas a garantir que a tecnologia necessária para entregar e suportar serviços está a funcionar de forma eficaz e eficiente. Estas actividades serão geralmente de natureza técnica - embora a tecnologia exacta irá variar de acordo com o tipo de serviço a ser entregues. Esta publicação incidirá sobre as atividades necessárias para gerenciar TI. Nota importante na gestão de tecnologia É tentador separar o conceito de Serviço de Gestão de da gestão da infra- estrutura que é utilizada para prestar esses serviços. Na realidade, é impossível alcançar qualidade serviços sem alinhamento e 'engrenagens' cada nível de tecnologia (e as pessoas que a gerenciam) para os serviços que estão sendo prestados. Serviço de Gestão envolve pessoas, processo e tecnologia. Em outras palavras, as atividades de operação comum de serviço não são sobre o gerenciamento da tecnologia para a questão de ter boa tecnologia atuação. Eles estão sobre a realização de desempenho que irá integrar a componente de tecnologia com as pessoas e componentes de processo alcançar serviço e objetivos de negócio. Veja a Figura 5.1 para exemplos de como a tecnologia é gerido em organizações de maturação. ITIL V3 - Operação de Serviço - Página: 154 de 423
    • Figura 5.1 atingir a maturidade em Gestão de Tecnologia Figura 5.1 ilustra as etapas envolvidas no amadurecimento de uma tecnologia centrada organização a uma organização que utiliza a tecnologia como parte de sua estratégia de negócios. Figura 5.1 ainda descreve o papel de Gestores de Tecnologia em organizações de diferentes maturidade. O diagrama não é abrangente, mas fornece exemplos da forma em que a tecnologia é gerido em cada tipo de organização. Os títulos em negrito indicam o papel importante desempenhado pela TI na gestão de tecnologia. O texto nas linhas descreve as características de um departamento de TI em cada nível. A finalidade deste diagrama neste capítulo é como se segue: • Este capítulo centra-se na Gestão Técnica actividades, mas não há nenhum modo simples de os representar. A organização menos madura tende a ver essas atividades como fins em si mesmos, e não um meio para um fim. Uma organização mais madura tenderá a subordinar essas atividades para nível superior Serviço de Gestão de objetivos. Por exemplo, a Servidor Equipa de gestão vai passar de um departamento isolado, focada exclusivamente no gerenciamento de servidores, para ITIL V3 - Operação de Serviço - Página: 155 de 423
    • uma equipe que trabalha em conjunto com outros gerentes de tecnologia para encontrar formas de aumentar o seu valor para o negócio. • Para fazer e reforçar o ponto de que não há nenhuma maneira "certa" de agrupar e organizar os departamentos que realizam esses serviços. Alguns leitores podem interpretar os títulos neste capítulo como os nomes dos departamentos, mas este não é o caso. O objetivo deste capítulo é identificar as atividades típicas técnicos envolvidos na Operação de Serviço. Aspectos organizacionais são discutidas no Capítulo 6. • As atividades de serviço de operação descritas no restante deste capítulo não são típicos de qualquer um dos níveis de maturidade. Em vez disso, as atividades são geralmente tudo presente de alguma forma em todos os níveis. Eles só estão organizadas e geridas de forma diferente em cada nível. Em alguns casos, um grupo dedicado pode lidar com todos de um processo ou atividade enquanto em outros casos de processos ou atividades podem ser compartilhadas ou dividir entre os grupos. No entanto, por meio de orientações gerais, as seções a seguir listam as atividades necessárias sob os grupos funcionais mais provável de ser envolvido em sua operação. Isso não significa que todas as organizações têm de usar essas divisões. Organizações menores tendem a atribuir grupos de essas atividades (se eles são necessários em todos) para os departamentos individuais, ou mesmo indivíduos. Finalmente, o objetivo deste capítulo não é fornecer uma análise detalhada de todas as atividades. Eles são especializados, e orientação detalhada está disponível a partir dos fornecedores de plataformas e outros, mais técnicos, quadros, novas categorias serão adicionadas continuamente como a tecnologia evolui. Este capítulo simplesmente tem como objetivo destacar a importância ea natureza da gestão de tecnologia para o gerenciamento de serviços de TI no contexto. ITIL V3 - Operação de Serviço - Página: 156 de 423
    • 5,1 Monitoramento e controle A medição e controlar de serviços é baseado em um ciclo contínuo de monitoramento, Relatórios e ações posteriores. Este ciclo é discutido em detalhes nesta seção porque é fundamental para a prestação de suporte e melhoria dos serviços. É também importante notar que, embora o ciclo tem lugar durante a operação de serviço, que fornece a base para a fixação estratégia, Projeto e testes de serviços e alcançar a melhoria significativa. É também a base para a medição SLM. Portanto, apesar de controlo é realizada por operação de serviço funçãos, que não deve ser visto como uma forma puramente operacional assunto. Todas as fases do Serviço Ciclo de Vida devem assegurar que as medidas e controles estão claramente definidos e executados, e colocada em prática. 5.1.1 Definições Refere-se a monitorização da atividade de observar uma situação para detectar mudanças que ocorrem ao longo do tempo. No contexto do Operação de Serviço, Isto implica o seguinte: • Usando ferramentas para monitorar o estado de CIs chave e principais atividades operacionais • Assegurar condições especificadas forem satisfeitas (ou não atingida) e, se não, para levantar um alertar para o grupo apropriado (por exemplo, a disponibilidade de dispositivos de rede chave) • Assegurar que o atuação ou a utilização de um componente ou sistema está dentro de um intervalo especificado (espaço em disco, por exemplo, ou a utilização de memória) • Para detectar tipos anormais ou níveis de actividade na infra-estrutura (por exemplo, o potencial segurança ameaças) • Para detectar alterações não autorizadas (por exemplo, introdução de software) • Para garantir observância com a organização'S políticas (por exemplo, uso inadequado de e-mail) • Para acompanhar as saídas para o negócio e garantir que eles se encontram qualidade e desempenho exigências • Para rastrear qualquer informação que é usado para medir Key Performance Indicators (KPIs). Relatórios refere-se à análise da produção e distribuição de saída do monitoramento atividade. No contexto do Operação de Serviço, Isto implica o seguinte: ITIL V3 - Operação de Serviço - Página: 157 de 423
    • • Usando ferramentas para agrupar a saída de monitoramento a informação que pode ser disseminada a vários grupos, funções ou processos • Interpretar o significado dessa informação • Determinar onde essa informação poderia ser melhor utilizados • A garantia de que os tomadores de decisão têm acesso às informações que lhes permitam tomar decisões • Encaminhamento das informações transmitidas para o apropriado pessoa, grupo ou ferramenta. Controlar refere-se ao processo de administrar a utilização ou o comportamento de um dispositivo, sistema ou serviço. É importante notar, no entanto, que simplesmente manipulando um dispositivo não é o mesmo que para a controlar. Controle exige três condições: • A ação deve assegurar que o comportamento está de acordo com um padrão definido ou norma • As condições levando a ação deve ser definida, entendida e confirmada • A ação deve ser definido, aprovado e adequado para estas condições. No contexto do Operação de Serviço, Controle implica o seguinte: • Usando ferramentas para definir quais as condições que representam normais operaçãos ou operações anormais • Regular o desempenho de dispositivos, sistemas ou serviços • Medir disponibilidade • Iniciar ações corretivas, o que pode ser automatizado (por exemplo, reiniciar um dispositivo remotamente ou executar um script) ou manual (por exemplo, notificar a equipe de operações do estado). 5.1.2 Controle Loops monitor O mais comum modelo para a definição de controle é o Monitor de Controle de Loop. Apesar de ser um modelo simples, tem muitos complexos aplicaçãos dentro IT Service Management. Esta seção irá definir os conceitos básicos do modelo de malha de controle Monitor e seções irá mostrar o quão importante esses conceitos são para o Serviço de Gestão de Ciclo de Vida. ITIL V3 - Operação de Serviço - Página: 158 de 423
    • Figura 5.2 a malha de controle do monitor Figura 5.2 descreve os princípios básicos de controle. Uma única atividade e a sua produção são medidos utilizando uma norma pré-definida, ou padrão, Para determinar se ela está dentro de um intervalo aceitável de atuação ou qualidade. Se não, são tomadas medidas para corrigir a situação ou para restaurar desempenho normal. Normalmente existem dois tipos de Malhas de Controle do Monitor: • Open Loop Sistemas destinam-se a efectuar uma específica atividade independentemente das condições ambientais. Por exemplo, um apoio pode ser iniciada em um determinado momento e frequência - e será executado independentemente de outras condições. • Sistemas de circuito fechados monitorar uma ambiente e responder às mudanças nesse ambiente. Por exemplo, no balanceamento de carga de rede um monitor irá avaliar o tráfego em um circuito. Se o tráfego de rede excede um determinado intervalo, o controlar sistema vai começar a rota de tráfego através de um circuito de backup. O monitor vai continuar a fornecer feedback para o sistema de controlo que vai continuar a regular o fluxo de tráfego de rede entre os dois circuitos. ITIL V3 - Operação de Serviço - Página: 159 de 423
    • Para ajudar a esclarecer a diferença, resolvendo Gerenciamento da Capacidade através de excesso de provisionamento é de malha aberta, um balanceador de carga que detecta congestão /falha e capacidade de redirecionamentos é de circuito fechado. 5.1.2.1 Controlo de Monitor Complexo Laço O Monitor de Controle de Loop na Figura 5.2 é uma boa base para a definição de como Gestão de Operações obras, mas dentro do contexto de ITSM, a situação é muito mais complexa. A Figura 5.3 ilustra um processo composto por três atividades principais. Cada um tem uma entrada e uma saída, e a saída torna-se uma entrada para a actividade seguinte. Neste diagrama, cada atividade é controlada pelo seu próprio loop Monitor de controle, usando um conjunto de normas para que a atividade específica. O processo como um todo também tem a sua própria malha de controle Monitor, que abrange todas as atividades e garante que todas as normas sejam adequadas e estão sendo seguidas. Figura 5.3 Malha de Controle Complexo do Monitor Na Figura 5.3 há um ciclo de feedback de casal. Um ciclo se concentra exclusivamente na execução de um determinado padrão, E o segundo avalia o ITIL V3 - Operação de Serviço - Página: 160 de 423
    • atuação do processo, e também os padrões em que o processo é executado. Um exemplo disto seria se o primeiro conjunto de laços de realimentação, na parte inferior do diagrama representado estações individuais de uma linha de montagem e o circuito de nível superior representada Garantia de Qualidade. A malha de controle Complexo Monitor é uma boa ferramenta de aprendizagem organizacional (como definido por Chris Argyris, (1976) Aumentar a eficácia da liderança. Nova Iorque: Wiley). O primeiro nível de feedback no nível de atividade indivíduo está preocupado com monitoramento e respondendo aos dados (fatos individuais, códigos ou peças de informação). O segundo nível está preocupado com a monitorização e resposta à informação (uma coleção de uma série de fatos sobre os quais uma conclusão pode ser desenhada). Consulte o Transição de Serviço publicação para um debate aprofundado sobre dados, informações, conhecimento e sabedoria. Tudo isso é teoria interessante, mas não explica como o Monitor conceito de controle de loop pode ser usado para operar De serviços de TIs. E especialmente - que define a norma? Com base no que foi descrito até agora, Malhas de Controle do monitor pode ser usado para gerenciar: • O atuação de atividades em um processo ou procedimento. Cada actividade ea sua saída relacionado pode potencialmente ser medido para assegurar que problemas com o processo são identificados antes do processo como um todo é concluída. Por exemplo, em Gerenciamento de Incidentes, O Service Desk monitora se uma equipe técnica aceitou um incidente em um tempo especificado. Se não, o incidente é escalado. Isto é feito antes de o alvo bem resolução tempo para que o incidente porque o objectivo de escalada que uma actividade é o de assegurar que o processo no seu conjunto é completado em tempo. • O eficácia de um processo ou procedimento como um todo. Neste caso, o 'atividade'Caixa representa todo o processo como uma única entidade. Por exemplo, a Gestão da Mudança irá medir o sucesso do processo, verificando se um mudar foi implementada em tempo, para especificação e dentro orçamento. • O atuação de um dispositivo. Por exemplo, a caixa de "atividade" poderia representar o tempo de resposta de um servidor sob uma dada carga de trabalho. • O desempenho de uma série de dispositivos. Por exemplo, a extremidade usuário tempo de resposta de um aplicação através da rede. Para definir como utilizar o conceito de Monitor de Controle de Loops em Serviço de Gestão de, As seguintes perguntas devem ser respondidas: • Como podemos definir o que precisa ser monitorado? • Quais são os adequados limiars para cada um deles? • Como será monitoramento ser realizada (manual ou automático)? ITIL V3 - Operação de Serviço - Página: 161 de 423
    • • O que representa normais operação? • Quais são as dependências para o funcionamento normal? • O que acontece antes de se chegar a entrada? • Com que freqüência deve a medição ocorrer? • Será que precisamos para realizar medição ativa para verificar se o item está dentro da norma ou vamos esperar até que uma exceção é relatado (medição passiva)? • É Gestão de Operações a única função que realiza um acompanhamento? • Se não, como são as outras instâncias de monitoramento relacionados à Gestão de Operações? • Se houver múltiplos loops, que são responsáveis por processos cada loop? As seções seguintes irão expandir o conceito de Malhas de Controle do Monitor e demonstrar como essas questões são respondidas. 5.1.2.2 O ITSM Monitor de Controle Laço Em ITSM, a malha de controle complexo Monitor pode ser representada como mostrado na figura 5.4. ITIL V3 - Operação de Serviço - Página: 162 de 423
    • Figura 5.4 ITSM Monitor de Controle de Loop Figura 5.4 pode ser utilizado para ilustrar o controlar de um processo ou de o componenteé usado para entregar um serviço. Neste diagrama "atividade" a palavra implica que ele se refere a um processo. Para aplicá-lo a um serviço, uma "atividade" também poderia ser um "CI". Há um certo número de características importantes na Figura 5.4: • Cada atividade num Serviço de Gestão de processo (ou de cada componente usado para fornecer um serviço) É monitorizada como parte do Operação de Serviço processos. O operacional equipe ou departamento responsável por cada atividade ou componente irá aplicar a malha de controle do monitor, conforme definido no processo, E usando as normas que foram definidos durante o Design de Serviços processos. O papel da monitorização operacional e controlo é o de assegurar que o processo ou o serviço funçãos exatamente como especificado, é por isso que eles estão principalmente preocupados com a manutenção do status quo. ITIL V3 - Operação de Serviço - Página: 163 de 423
    • • As normas e mecanismos de monitoramento e de controle são definidos em Design de Serviços, mas eles são baseados no padrãos e arquiteturas definido durante Estratégia de Serviço. Quaisquer alterações ao organizaçãoEstratégia do Serviço, arquitetura, serviço carteiras ou Exigência de Nível de Serviços vai precipitar mudanças para o que é monitorado e como ele é controlado. • O Monitor de Controle de Loops são colocados dentro do quadro do sistema. Isto implica que a Estratégia de Serviço serão principalmente executado por executivos de TI com o apoio do fornecedor gerente de contass. Design de Serviços atua como ponte entre a Estratégia de Serviço e Operação de Serviço e normalmente envolvem representantes de todos os grupos. As atividades e controles geralmente será executado pela equipe de TI (às vezes envolvendo usuários) e apoiada por gerentes de TI e os fornecedores. Melhoria de Serviço abrange todas as áreas, mas principalmente representa os interesses da empresa e seus usuários. • Observe que o segundo nível de monitoramento neste loop complexo Monitor de controle é realizado por meio de processos de CSI Estratégia de Serviço e Design de Serviço. Estes relaçãos são representadas pelas setas numeradas na figura 5.4, como segue: • Seta 1. Neste caso CSI tem reconhecido que o serviço será melhorada através de uma mudar à Estratégia de Serviço. Isto poderia ser o resultado da necessidade de uma mudança de actividade para o Portfólio de Serviços, Ou que a arquitetura não entregar o que era esperado. • Arrow 2. Neste caso, os requisitos de nível de serviço precisam ser ajustados. Pode ser que o serviço é muito caro, ou que o configuração da infra-estrutura necessita de ser alterada para melhorar atuação, Ou porque Gestão de Operações é incapaz de manter o serviço qualidade na arquitetura atual. • Seta 3. Neste caso, as normas especificadas em Design de Serviços não estão a ser cumpridos. Isto poderia ser porque eles não são apropriados ou executável, ou por causa de uma falta de educação ou falta de comunicação. As normas ea falta de observância precisam ser investigadas e as medidas tomadas para corrigir a situação. Transição de Serviço oferece um grande conjunto de freios e contrapesos nestes processos. Fá-lo como se segue: • De novos serviços, Transição de Serviço irá garantir que as arquiteturas técnicas são adequadas e que os padrões operacionais de desempenho pode ser executado. Este, por sua vez, irá garantir que as equipes de serviço de operação ou departamentos são capazes de cumprir os requisitos de nível de serviço. ITIL V3 - Operação de Serviço - Página: 164 de 423
    • • Para os serviços existentes, Gestão da Mudança irá gerenciar qualquer uma das alterações que são necessárias, como parte de um controle (por exemplo, afinação), Assim como quaisquer alterações representadas pelas setas marcadas 1, 2 e 3. Apesar de Transição de Serviço não define estratégia e projeto serviços, por si só, fornece coordenação e garantia de que os serviços estão funcionando e vai continuar a trabalhar, como planejado. Porque é que este circuito coberto Operação de Serviço? Figura 5.4 representa Monitoramento e Controle para o conjunto da IT Service Management. Alguns leitores da publicação operação de serviço pode sentir que ele deve ser mais adequadamente abordados na publicação Estratégia de Serviço. No entanto, Monitoramento e Controle só pode ser efetivamente implantado quando o serviço é operacional. Isto significa que o qualidade de todo o conjunto de processos de Gerenciamento de Serviço depende de como eles são monitorados e controlados de Operação de Serviço. As implicações disso são as seguintes: • Operação equipe de serviço não são as únicas pessoas com um interesse no que é monitorado e como eles são controlados. • Enquanto Operação de Serviço é responsável por monitoramento e controlar de serviços e componentes, eles estão agindo como administradores de uma parte muito importante do conjunto de laços de ITSM Monitoramento e Controle • Se a equipe da Operação de Serviço definir e executar Monitoramento e Controle procedimentos isoladamente, nenhum dos processos de Gerenciamento de Serviço ou funçãos só será plenamente eficaz. Isso ocorre porque as funções de operação de serviço não vai apoiar as prioridades e informações exigências de outros processos, por exemplo, a tentativa de negociar um SLA quando os dados disponíveis apenas é a página de swap as taxas em um servidor e a utilização da largura de banda de uma rede detalhada. 5.1.2.3 definir o que precisa ser monitorado A definição do que precisa ser monitorado é baseada no entendimento do desejado resultado de um processo, dispositivo ou sistema. Deve concentrar-se no serviço e os seus impacto sobre o negócio, e não apenas os componentes individuais de tecnologia. A primeira pergunta que precisa ser feita é "O que estamos tentando alcançar? '. 5.1.2.4 Monitoramento Interno e Externo e Controle ITIL V3 - Operação de Serviço - Página: 165 de 423
    • No início, torna-se claro que existem dois níveis de controlo: • Monitoramento e Controle Interno: A maioria das equipes ou departamentos estão preocupados com a possibilidade de executar com eficácia e eficiência as tarefas que foram atribuídas a eles. Por isso, eles vão monitorar os itens e atividades que estão diretamente sob seu controle. Este tipo de monitoramento e controle se concentra em atividades que são auto-contido que a equipe ou departamento. Por exemplo, a Service Desk Gerente vai monitorar o volume de chamadas para determinar como muitos funcionários precisam estar disponíveis para atender o telefone. • Monitoramento e controle externo: Embora cada equipe ou departamento é responsável por gerenciar sua própria área, eles não agem de forma independente. Cada tarefa que eles executam, ou dispositivo que eles conseguem, tem um impacto sobre o sucesso da organização como um todo. Cada equipe ou departamento também vai estar controlando itens e atividades em nome de outros grupos, processos ou funçãos. Por exemplo, a Servidor Equipa de gestão vai monitorar a CPU atuação em servidores principais e executar carga de trabalho equilibrar, de modo que um crítico aplicação é capaz de permanecer dentro de desempenho limiars definido pelo Aplicação de Gestão de. A distinção entre o controlo interno e externo é um passo importante. Se Operação de Serviço incide apenas sobre monitoramento interno, que terá infra- estrutura muito bem gerida, mas não há maneira de entender ou influenciar o qualidade de serviços. Se ele se concentra apenas no monitoramento externo, ele vai entender o quão pobre a serviço qualidade é, mas não tem idéia do que está causando isso ou como mudar isso. Na realidade, a maioria das organizações têm uma combinação de controlo interno e externo, mas em muitos casos estes não estão ligados. Por exemplo, a equipe de gerenciamento de servidor sabe exatamente o quão bem os servidores estão executando as tarefas eo Nível de Serviço Gerente sabe exatamente como os usuários percebem a qualidade do serviço prestado pelos servidores. No entanto, nenhum deles sabe como ligar esses métricos para definir qual o nível de desempenho do servidor representa a boa qualidade serviço. Isso se torna ainda mais confuso quando o desempenho do servidor que é aceitável no meio do mês, não é aceitável no final do mês. 5.1.2.5 Definir objectivos para monitoramento e controle Muitas organizações começar por perguntar a pergunta "O que estamos a gestão? '. Isso leva invariavelmente a um monitoramento interno forte Sistema, Com ligação muito pouco para o real resultado ou serviço que é exigido pela empresa. ITIL V3 - Operação de Serviço - Página: 166 de 423
    • A pergunta mais apropriada é "Qual é o resultado final das atividades e equipamentos que a minha equipa consegue? '. Portanto, o melhor lugar para começar, ao definir o que monitorar, é determinar o resultado necessário. A definição de Monitoramento e Controle objetivos devem, idealmente, começar com a definição da Exigência de Nível de Serviçosdocumentos (ver Design de Serviços publicação). Estes irão especificar como o clientes e usuários vai medir o desempenho do serviço, e são utilizados como entrada para os processos de design de serviço. Durante Design de Serviços, vários processos irá determinar como o serviço será entregue e gerenciado. Por exemplo, a Gerenciamento da Capacidade vai determinar a forma mais adequada e econômica para entregar os níveis de desempenho exigidos. Gerenciamento de Disponibilidade vai determinar a forma como a infra-estrutura pode ser configurado para proporcionar o menor número de pontos de falha. Se houver qualquer dúvida sobre a validade ou integridade de objectivos, a COBIT framework fornece uma abrangente, conjunto de alto nível dos objectivos como uma lista de verificação. Mais informações sobre o COBIT é fornecido no Apêndice A desta publicação. O Processo de Design de Serviços irá ajudar a identificar os seguintes conjuntos de insumos para a definição Operacional Monitoramento e Controle de normas e mecanismos: • Eles vão trabalhar com clientes e usuários para determinar como a saída do serviço será medido. Isso irá incluir mecanismos de medição, freqüência e amostragem. Esta parte do Design de Serviços incidirá especificamente sobre os requisitos funcionais. • Eles vão identificar CIs chave, como devem ser configurados e qual o nível de desempenho e disponibilidade é necessária, a fim de cobrir a Nível de Serviços. • Eles vão trabalhar com os desenvolvedores e fornecedores da CEI que compõem cada serviço para identificar quaisquer restrições ou limitações naqueles componentes. • Todo apoio e equipes de entrega e departamentos terão de identificar quais informações irá ajudá-los a executar seu papel eficazmente. Parte do Design de Serviços e desenvolvimento será instrumento cada serviço para que ele possa ser controlado para fornecer essas informações, ou para que possa gerar significativo eventos. Tudo isso significa que uma parte muito importante de definir o que Operação de Serviço monitores e como ela exerce o controle é identificar a das partes interessadass de cada serviço. As partes interessadas podem ser definidos como qualquer pessoa com interesse na entrega e recepção de sucesso De serviços de TIs. Cada ator terá ITIL V3 - Operação de Serviço - Página: 167 de 423
    • uma perspectiva diferente do que vai demorar para entregar ou receber um serviço de TI. Operação de Serviço precisa entender cada uma dessas perspectivas, a fim de determinar exatamente o que precisa ser monitorado eo que fazer com a saída. Operação de Serviço, portanto, dependem de SLM para definir exatamente quem são essas partes interessadas e como elas contribuem ou usar o serviço. Isso é discutido com mais detalhes no design de serviço e publicações Melhoria de Serviço Continuada. Nota sobre Objetivos de monitoramento interno e externo O requerido resultado pode ser interno ou externo à Operação de Serviço funçãos, embora deva ser sempre lembrado que uma ação interna, muitas vezes, ter um resultado externo. Por exemplo, a consolidação servidors para torná-los mais fáceis de administrar pode resultar numa custar poupança, o que afetará a negociação e SLM rever ciclo, bem como o Gestão Financeira processos. 5.1.2.6 Tipos de monitoramento Existem muitos tipos diferentes de monitoramento ferramenta e situações diferentes em que cada um deles será utilizado. Esta seção focaliza alguns dos diferentes tipos de controlo que podem ser realizadas e quando seria adequado. Monitoramento ativa versus passiva • Monitoramento ativo refere-se à "interrogação" contínuo de um dispositivo ou sistema para determinar a sua estado. Esse tipo de monitoramento pode ser recurso intensivo e é geralmente reservado para monitorar proativamente o disponibilidade de dispositivos ou sistemas críticos, ou como um passo de diagnóstico quando se tenta resolver um incidente ou diagnosticar um problema. • Monitoramento passivo é mais comum e refere-se a geração e transmissão de eventos de um "dispositivo de escuta", ou agente de monitoramento. Monitoramento passivo depende de definição bem sucedida de eventos e instrumentação do sistema a ser monitorizados (ver secção 4.1). Reativa contra Proactive • Acompanhamento reactivo é projetado para solicitar ou desencadear uma acção na sequência de um certo tipo de evento ou falha. Por exemplo, servidor, atuação degradação pode desencadear um reboot, ou uma falha do sistema irá gerar uma incidente. Monitoramento reativo não é usado somente para exceções. Ele também pode ser usado como parte da ITIL V3 - Operação de Serviço - Página: 168 de 423
    • operação normal procedimentos, por exemplo, um trabalho em lotes é concluída com êxito, o que leva o sistema de agendamento para enviar o trabalho próximo lote. • Monitoramento proativo é usado para detectar os padrões de eventos, que indicam que um sistema ou serviço pode estar prestes a falhar. Proactive monitoramento é geralmente usado em mais madura ambientes, onde estes padrões têm sido detectados anteriormente, muitas vezes, por várias vezes. Ferramentas de monitoramento pró-ativo são, portanto, um meio de automatizar a experiência da equipe de TI experiente e muitas vezes são criadas através do Gerenciamento de Problemas pró-ativa processo (Ver publicação Melhoria de Serviço Continuada). Por favor, note que o monitoramento reativo e proativo pode ser ativo ou passivo, conforme a Tabela 5.1: Ativo Passiva Reativo Usado para diagnosticar qual dispositivo está causando o falha e em que condições ("ping" por exemplo, um dispositivo, ou executar e acompanhar uma amostra transação através de uma série de dispositivos) Requer conhecimento da infra- estrutura e topografia do mapeamento dos serviços a instituições de crédito Detecta e correlaciona evento registros para determinar o sentido da eventos ea ação apropriada (por exemplo, um usuário faz em três vezes com a senha incorreta, o que gera representa um segurança exceção e é escalado por Gestão de Segurança da Informação procedimentos) Requer conhecimento detalhado do normal operação da infra-estrutura e serviços Proactive Utilizado para determinar o tempo real estado de um dispositivo, sistema ou serviço - geralmente por crítica componentes ou após a recuperação de um dispositivo falhou para garantir que ele está totalmente recuperado (isto é, não vai causar novos incidentes) Os registros de eventos são correlacionados ao longo do tempo para construir tendências para Gerenciamento de Problemas pró-ativa. Padrões de eventos são definidos e programados em ferramentas de correlação para futuro reconhecimento Reativa Tabela 5.1 Ativo e Passivo e monitoramento proativo Medição contínua versus exceção baseada em Medição • Medição Contínua é focado em monitoramento um sistema em tempo real para assegurar que ele está em conformidade com a atuação norma (por exemplo, um aplicação servidor está disponível para 99,9% do acordado horas de serviço). A diferença entre a medição e monitorização contínua e ativa é que o monitoramento ativo não tem que ser contínuo. No entanto, como com a monitorização activa, isto é recurso intensivo e é geralmente reservado para componentes críticos ou serviços. Na maioria dos casos, o custar da largura de banda e poder de processamento ITIL V3 - Operação de Serviço - Página: 169 de 423
    • superior ao benefício de medição contínua. Nestes casos, um controlo será normalmente por amostragem e análise estatística (por exemplo, o desempenho do sistema é relatada a cada 30 segundos e extrapolados para representar o desempenho global). Nestes casos, o método de medição deverá ser documentado e acordado nos OLAs para garantir que ela é adequada para suportar os requisitos de informação de serviço (ver Melhoria de Serviço Continuada publicação). • Exceção Baseado Medição não mede o desempenho em tempo real de um serviço ou sistema, mas detecta e relatórios com exceções. Por exemplo, um evento é gerado se a transação não for concluída, ou se um desempenho limiar é atingido. Este é mais rentável e mais fácil de medir, mas pode resultar em mais serviço interrupções. Medição exceção Baseado é usado para sistemas menos críticos ou em sistemas onde custar é uma questão importante. Também é utilizado em instrumentos de TI não são capazes de determinar o estado ou qualidade de um serviço (Por exemplo, se a qualidade de impressão faz parte da serviço especificação, A única maneira de medir esta é a inspecção física - muitas vezes realizada pelo usuário em vez de a equipe de TI). Onde Medição Excepção-Based é usado, é importante que tanto o OLA ea SLA para esse serviço refletir isso, como interrupções de serviço são mais prováveis de ocorrer, e os usuários são muitas vezes obrigados a comunicar a exceção. Desempenho versus saída Há uma distinção importante entre o relatório usado para rastrear a atuação de componentes ou equipes ou departamento usado para fornecer um serviço e os relatórios usados para demonstrar a realização do serviço qualidade objetivos. Os gerentes de TI muitas vezes confundem estes relatando ao negócio sobre o desempenho de suas equipes ou departamentos (por exemplo, número de chamadas atendidas por Service Desk Analista), como se isso fosse a mesma coisa que qualidade de serviço (por exemplo, incidentes resolvidos no prazo acordado). Monitoramento de Desempenho e métricos deve ser usado internamente pelo Serviço de Gestão de para determinar se as pessoas, processo e tecnologia estão funcionando corretamente e com o padrão. Usuários e clientes preferiria ver relatórios relacionados com a qualidade e desempenho do serviço. Embora Operação de Serviço está preocupado com os dois tipos de comunicação, a principal preocupação desta publicação é de monitoramento de desempenho, enquanto monitoramento de Qualidade de Serviço (ou com base ITIL V3 - Operação de Serviço - Página: 170 de 423
    • em resultados de Monitoramento) será discutido em detalhe no Melhoria de Serviço Continuada publicação. 5.1.2.7 Monitoramento em ambientes de teste Tal como acontece com qualquer Infraestrutura de TI, Um Ambiente de Teste terá de definir como vai utilizar a monitorização e controlar. Estes controlos são mais completamente discutidos na Transição de Serviço publicação. • Monitorar o ambiente de teste em si: Um ambiente de teste consiste de infra-estrutura, aplicaçãos e processos que têm de ser geridos e controlados como qualquer outro ambiente. É tentador pensar que o ambiente de teste não precisa de rigoroso monitoramento e controle, porque não é um viver ambiente. No entanto, este argumento não é válido. Se um ambiente de teste não está devidamente monitorizado e controlado, existe o perigo de executar os testes no equipamento que se desvia da padrãos definidos no Design de Serviços. • Itens de monitoramento que está sendo testado: Os resultados dos testes têm de ser rigorosamente controladas e verificadas. Também é importante que as ferramentas de monitoramento que foram construídas em serviços novos ou modificados têm de ser testados também. 5.1.2.8 Relatórios e ação "Um relatório sozinho cria a consciência, um relatório com um plano de ação alcança resultados. Relatórios e disfunçãofunção A experiência prática tem mostrado que há mais informação nas organizações disfuncionais do que em organizações eficazes. Isto é porque os relatórios não estão sendo usados para iniciar pré-definida de ação planos, mas sim: • transferir a culpa para um incidente • para tentar descobrir quem é o responsável por tomar uma decisão • como entrada para a criação de planos de ação para futuras ocorrências. Nas organizações disfuncionais uma série de relatórios que são produzidos ninguém tem tempo para olhar ou consulta. Monitoramento sem controlar é irrelevante e ineficaz. O monitoramento deve ser sempre, para evitar que serviço e operacional objetivos estão sendo atendidas. Isso significa que, a menos que haja um objetivo claro para monitoramento um sistema ou serviços, que não devem ser monitorizados. ITIL V3 - Operação de Serviço - Página: 171 de 423
    • Isso também significa que quando a vigilância é definida, também deve quaisquer ações necessárias. Por exemplo, ser capaz de detectar que uma grande aplicação falhou não é suficiente. A equipe de gestão competente aplicativo também deve ter definido as etapas exatas que vai levar quando o aplicativo falha. Além disso, deve também ser reconhecido que essa acção pode ter de ser tomada por pessoas diferentes, por exemplo, um único evento (tal como uma aplicação falha) Pode desencadear a acção da Aplicação de Gestão de equipa (para restaurar serviço), os usuários (para iniciar o processamento manual) e de gestão (para determinar como esta evento pode ser evitado no futuro). As implicações disto princípio são descritos em mais pormenor em relação às Gestão de Eventos (Ver secção 4.1). 5.1.2.9 auditorias Operação de Serviço Regular auditars devem ser realizados com o Operação de Serviço processos e atividades para garantir: • Estão a ser realizados como pretendido • Não há evasão • Eles ainda são apto para o efeito, Ou para identificar eventuais alterações ou melhorias. Gerentes de operação de serviço pode optar por realizar auditorias si, mas o ideal é alguma forma de elemento independente das auditorias é preferível. O organização'S interno de TI equipe de auditoria ou departamento pode ser solicitado a se envolver ou algumas organizações podem optar por participar de terceiros consultoria / auditoria /avaliação empresas de modo que um perito vista totalmente independente é obtido. Auditorias operação de serviço fazem parte da avaliação contínua que ocorre como parte de Melhoria de Serviço Continuada e são discutidos em mais detalhes na publicação. 5.1.2.10 Medição, métricas e KPIs Esta seção tem como foco principal o monitoramento e controle como base para a operação de serviço. Outras seções da publicação ter coberto alguns básicos métricos que podem ser usados para medir a eficácia e eficiência de um processo. Embora esta publicação não é principalmente sobre medição e métricas, é importante que as organizações que utilizam estes diretrizs têm técnicas de ITIL V3 - Operação de Serviço - Página: 172 de 423
    • medição robustos e métricas que suportam o objetivos dos seus organização. Esta seção é um resumo desses conceitos. Medição Refere-se a medição de qualquer técnica que é utilizada para avaliar a extensão ou dimensão capacidade de um artigo, em relação a um padrão ou a unidade. • Refere-se a medida do grau de observância ou conclusão (por exemplo, são todas as alterações formalmente autorizados pela autoridade competente) • Dimensão refere-se ao tamanho de um artigo, por exemplo, o número de incidentes resolvidos pela Service Desk • Refere-se a capacidade total capacidade de um artigo, por exemplo, número máximo de padrão transaçãos que podem ser processados por um servidor por minuto. Medição só se torna significativa quando é possível medir a saída real ou dimensões de um sistema,função ou processo contra um nível padrão ou desejado, por exemplo, o servidor deve ser capaz de processar um mínimo de 100 operações padrão por minuto. Isso precisa ser definido em Design de Serviço, e aperfeiçoado ao longo do tempo através Melhoria de Serviço Continuada, Mas a medida em si acontece durante Operação de Serviço. Métrica Métricos referem-se ao quantitativo, periódica avaliação de um processo, Sistema ou função, juntamente com a procedimentos e ferramentas que serão usadas para fazer essas avaliações e os procedimentos para interpretá-los. Esta definição é importante, porque não só especifica o que deve ser medido, mas também a forma de medi-la, o que a faixa aceitável de desempenho será e quais as medidas terão de ser tomadas como resultado do normal atuação ou um. exceção A partir disto, é evidente que qualquer métrica dada na secção precedente desta publicação é muito básica e terá de ser aplicado e expandido dentro do contexto de cada organização antes que possa ser eficaz. Indicadores Chave de Desempenho Um KPI refere-se a um nível específico, acordado atuação que irão ser utilizados para medir o eficácia de um organização ou processo. KPIs são únicos para cada organização e têm de estar relacionadas a determinadas entradas, saídas e atividades. Elas não são de natureza genérica ou universal e, portanto, não foram incluídos nesta publicação. ITIL V3 - Operação de Serviço - Página: 173 de 423
    • Uma outra razão para não incluir a eles é o fato de que semelhante métricos pode ser usada para atingir KPIs muito diferentes. Por exemplo, uma organização utilizada a percentagem 'métrica de Incidentes resolvidos pela Service Desk"Para avaliar o desempenho do Service Desk. Isso funcionou efetivamente por cerca de dois anos, após o qual o gerente de TI começaram a perceber que este KPI estava sendo usado para prevenir eficaz Gerenciamento de Problemas, Ou seja, se, depois de dois anos, 80% de todos os incidentes são fáceis o suficiente para ser resolvido em 10 minutos no primeiro chamar, Por que não podemos chegar a uma solução para eles? Com efeito, o KPI agora tornou- se uma medida de como ineficazes as equipes de Gerenciamento de Problemas foram. 5.1.2.11 Interfaces para práticas de outros serviços do Ciclo de Vida Monitoramento Operacional e Melhoria de Serviço Continuada Esta secção tem incidido sobre Operacional Vigilância e informação, mas monitoramento também constitui o ponto de partida para o Melhoria de Serviço Continuada. Isso é abordado na publicação Melhoria de Serviço Continuada, mas as principais diferenças são descritos aqui. Qualidade é a chave objetivo de monitoramento para a Melhoria de Serviço Continuada (MSC). O acompanhamento será, portanto, incidir sobre a eficácia de um serviço, Processo, ferramenta de organização, ou CI. A ênfase não está na garantia de desempenho em tempo real de serviços, mas sim que está em identificar onde as melhorias podem ser feitas para o actual nível de serviço, ou o desempenho de TI. Monitoramento de CSI, portanto, tendem a se concentrar na detecção de exceções e resoluçãos. Por exemplo, a CSI não é tão interessado em saber se um incidente foi resolvido, mas se ele foi resolvido dentro do prazo acordado e se incidentes futuros podem ser evitados. CSI não é apenas interessado em exceções. Se um SLA é consistentemente conheceu ao longo do tempo, CSI também estará interessado em determinar se o nível de desempenho pode ser sustentado a um menor custar ou se ele precisa ser atualizado para um nível ainda maior de desempenho. CSI pode, portanto, também precisam ter acesso a relatórios de desempenho regulares. No entanto, como CSI é improvável que precisa, ou ser capaz de lidar com as enormes quantidades de dados que são produzidos por todo o acompanhamento atividade, Eles vão se concentrar mais provável em um subconjunto específico de monitoramento a qualquer momento. Isto pode ser determinado através de uma entrada a partir da empresa ou melhorias à tecnologia. ITIL V3 - Operação de Serviço - Página: 174 de 423
    • Isso tem duas implicações principais: • Monitoramento de CSI vai mudar ao longo do tempo. Eles podem estar interessados no acompanhamento do serviço de correio electrónico quarto e depois passar a olhar para RH sistemas no próximo trimestre. • Isto significa que, Operação de Serviço e CSI precisa construir um processo que irá ajudá-los a chegar a acordo sobre que áreas precisam ser monitoradas e para que finalidade. ITIL V3 - Operação de Serviço - Página: 175 de 423
    • 5,2 Operações de TI 5.2.1 Management Console / Ponte de Operações Estes fornecem um ponto de coordenação central para gerenciar várias classes de eventos, a detecção de incidentes de rotina, gestão operacional atividades e elaboração de relatórios sobre o estado ou atuação de tecnologia componentes. Observação e monitoramento do Infraestrutura de TI pode ocorrer a partir de um console centralizado - para o qual todos sistema eventos são roteados. Historicamente, isto envolveu o acompanhamento do mestre operaçãos consola de um ou mais computadores centrais -, mas hoje em dia é mais provável que envolve um controlo de um servidor farm (s), dispositivos de armazenamento, componentes de rede aplicaçãos, bases de dados ou qualquer outro CIs, incluindo qualquer estrutura principal restante (s), a partir de um único local, conhecido como o Operações Ponte. Existem duas teorias sobre como o Operações Ponte foi assim chamado. Uma delas é que ele se assemelha a ponte de um navio grande, automatizada (como naves espaciais comumente visto em filmes de ficção científica). Outra teoria é que a Operações Ponte representa uma ligação entre o Operações de TI equipes e as tradicionais Help Desk. Em alguns organismos, isto significa que o funçãos de Controle Operacional e do Help Desk foram incorporadas pela Service Desk, Que realizou os dois conjuntos de funções em um único local físico. Independentemente da forma como foi nomeado, um Operações Ponte reunirá todos os pontos de observação críticos na infra-estrutura de TI, para que possam ser monitorados e gerenciados a partir de um local centralizado, com o mínimo de esforço. Os dispositivos a ser monitorizado são susceptíveis de ser fisicamente dispersos e podem estar localizados em instalações centralizadas do computador ou dispersos no interior da usuário comunidade, ou ambos. O Operações Ponte vai combinar muitas atividades, que podem incluir Management Console, manipulação de eventos, de primeira linha de gerenciamento de rede, Job Scheduling e suporte out-of-hora (cobertura para o Service Desk e / ou segunda linha de apoio grupos se eles não trabalham 24/7). Em algumas organizações, o Service Desk é parte do Operações Ponte. A localização física e layout de Ponte da operação deve ser cuidadosamente projetado para oferecer a acessibilidade correta e visibilidade de todas as telas e dispositivos pertinentes ao pessoal autorizado. No entanto, isso vai se tornar uma área muito sensível, onde o acesso controlado e apertado segurança será essencial. ITIL V3 - Operação de Serviço - Página: 176 de 423
    • Organizações menores não pode ter um físico Operações Ponte, Mas haverá certamente ainda a necessidade de Management Console, geralmente combinado com outras técnicas papels. Por exemplo, uma única equipe de técnicos irá gerenciar a rede, servidores e aplicativos. Parte do seu papel será o de monitorar os consoles para esses sistemas - muitas vezes usando consoles virtuais, para que possam realizar o atividade a partir de qualquer localização. No entanto, deve notar-se que estas consolas virtuais são ferramentas poderosas e, se for usado em locais inseguros ou mais conexões a descoberto, pode representar uma segurança significativa ameaça. 5.2.2 Job Scheduling Operações de TI irá executar rotinas, consultas ou relatórios que lhe forem delegadas, como parte dos serviços de entrega, ou como parte da rotina de limpeza delegada pelo técnico e Aplicação de Gestão de equipes. Job Scheduling envolve a definição e início de pacotes de software de agendamento de tarefas para executar em lote e em tempo real de trabalho. Isto normalmente envolvem diária, semanal, mensal, anual e horários ad hoc para atender às necessidades de negócio. Além da primeira projetoOu redesenho periódica, dos horários, não são susceptíveis de ser frequentes alterações ou ajustes para fazer, durante o qual as dependências de trabalho têm de ser identificados e acomodados. Haverá também um papel a desempenhar na definição alertars e Relatório de Exceçãos para ser usado para monitoramento/ Verificar horários de trabalho. Gestão da Mudança desempenha um papel importante na avaliação e validação de grandes mudanças de horários, bem como a criação de Mudança Padrão procedimentos para mais mudanças de rotina. Tempo de execução parâmetros e / ou arquivos têm que ser recebidos (ou acelerada se atrasado) e de entrada - e todos os logs em tempo de execução tem que ser verificado e qualquer falhas identificadas. Se as falhas ocorrem, em seguida, re-runs terá que ser iniciado, sob a orientação da apropriadas unidade de negócioss, muitas vezes com diferentes parâmetros ou dados alterados / arquivo versãos. Isso vai exigir comunicações cuidadosos para garantir parâmetros corretos e arquivos são usados. Muitas organizações se deparam com crescentes horários lote durante a noite que pode, se superado o slot lote durante a noite, negativamente impacto sobre os serviços on-line dia - assim estão buscando maneiras de utilizar máxima durante a noite capacidade e atuação, Em conjunto com Gerenciamento da Capacidade. Isto é onde Workload Técnicas de gestão podem ser úteis, tais como: ITIL V3 - Operação de Serviço - Página: 177 de 423
    • • Re-agendamento de trabalho para evitar a disputa em dispositivos específicos ou em momentos específicos e melhorar global rendimento • Migração de cargas de trabalho para plataformas alternativas /ambientes para ganhar um melhor desempenho e / ou produtividade (capacidades de virtualização de fazer isso muito mais viável, permitindo a migração, dinâmico automatizado) • Sincronismo cuidadoso e "intercalação" de postos de trabalho para ganhar o máximo aproveitamento dos disponíveis recursos. Anedota Um grande organização, Que foi confrontado com superação lote / utilização problemas, identificou que, devido à natureza humana onde as pessoas estavam procurando ser 'arrumado', todos os trabalhos estavam sendo iniciado na hora ou menos 15 minutos de intervalo durante a hora (ou seja, n horas, 15 minutos passado, passado meia, de 15 minutos a, etc.) Ao re-agendamento de trabalho para que ele começou logo outro trabalho terminado, e cambaleando os tempos de início de outro trabalho, ele foi capaz de obter reduções significativas na disputa e conseguir o processamento muito mais rápido em geral, que se resolveu a sua problemas, sem a necessidade de atualizações. Job Scheduling tornou-se um sofisticado atividade, Incluindo qualquer número de variáveis - tais como tempo-sensibilidade, dependências críticas e não críticas, balanceamento de carga de trabalho, falha e encaminhar, etc Como resultado, a maioria operaçãos contar com ferramentas que permitem Job Scheduling Operações de TI para agendar trabalhos para o melhor uso da tecnologia para alcançar Nível de Serviço Objetivos. A mais recente geração de ferramentas de programação permite um único conjunto de ferramentas para agendar e automatizar as atividades técnicas e Serviço de Gestão de processo atividades (como o agendamento de mudança). Embora esta seja uma boa oportunidade para melhorar eficiência, Representa também um maior ponto único de falha. As organizações que utilizam esse tipo de ferramenta, portanto, ainda usam soluções pontuais como agentes e também como um apoio no caso de o conjunto de ferramentas principal falhar. 5.2.3 Backup e Restauração Faça backup e Restaurar É, essencialmente, um componente do bem De serviços de TI Planejamento da Continuidade. Como tal, Design de Serviços deve assegurar que existem sólidas estratégias de backup para cada serviço e Transição de Serviço deve garantir que estas sejam devidamente testados. ITIL V3 - Operação de Serviço - Página: 178 de 423
    • Além disso, o regulador exigências especificar que certos tipos de organização (Tais como serviços financeiros ou empresas cotadas) deve ter um backup formal e Restaurar estratégia no lugar e que esta estratégia é executado e auditados. Os requisitos exatos variam de país para país e por setor da indústria. Isso deve ser determinado durante Design de Serviços e construído na funcionalidade do serviço e documentação. O único ponto de fazer backups é que eles podem precisar de ser restaurado em algum ponto. Por esta razão, não é tão importante para definir como fazer uma sistema -se como é para definir quais componentes estão em risco e como efetivamente mitigar esse risco. Há um sem número de ferramentas disponíveis para backup e restauração, mas é importante notar que as características de tecnologias de armazenamento usados para dados corporativos estão sendo utilizados para backup / restore (instantâneos, por exemplo). Há, portanto, um aumento do grau de integração entre as atividades de backup e restauração e as de armazenamento e arquivamento (ver secção 5.6). 5.2.3.1 backup Dados da organização tem que ser protegido e isso vai incluir backup (cópia) e armazenamento de dados em locais remotos, onde pode ser protegidos - e usado deveria precisam ser restaurados, devido à corrupção, perda ou implementação de TI Plano de Continuidade do Serviços. Uma estratégia de backup global deve ser acordado com o negócio, abrangendo: • Que dados tem de ser apoiada ea freqüência e periodicidade a ser usado. • Quantas gerações de dados têm de ser conservados - isto pode variar de acordo com o tipo de dados que está sendo feito o backup, ou que tipo de arquivo (por exemplo, arquivo de dados ou aplicação executável). • O tipo de backup (completo, parcial, progressiva) e pontos de controlo a serem utilizados. • Os locais a serem utilizadas para o armazenamento (que podem incluir desastre recuperação locais) e horários de rotação. • Métodos de transporte (por exemplo, a transferência de arquivos através da rede, transporte físico em mídia magnética). • Testes / verificações a serem realizadas, como teste-lê, teste restaurações, verificar-somas etc • Objetivo do ponto de recuperação. Isto descreve o ponto para o qual os dados serão restaurados após a recuperação de uma De serviços de TI. Isto pode envolver a perda de dados. Por exemplo, um Objetivo do ponto de recuperação de um dia pode ser suportado por apoios diários, e até 24 horas de dados podem ser perdidos. Objetivos do ponto de recuperação ITIL V3 - Operação de Serviço - Página: 179 de 423
    • para cada serviço de TI deve ser negociado, acordado e documentado em Olas, SLAs e UCs. • Objetivo Tempo de recuperação. Isso descreve o tempo máximo permitido para a recuperação de um serviço de TI após uma interrupção. O Nível de Serviço a ser fornecida pode ser menor do que o normal Alvo de Nível de Serviços. Objetivos de tempo de recuperação para cada serviço de TI deve ser negociado, acordado e documentado em Olas, SLAs e UCs. • Como verificar se o apoios vai funcionar se eles precisam ser restaurard. Mesmo se não houver erro códigos gerados, pode haver vários motivos para o backup não podem ser restaurados. Um bom backup estratégia e operaçãosprocedimentos irá minimizar o risco de que isso aconteça. Faça backup procedimentos devem incluir uma verificação passo para garantir que os backups estão completos e que vai funcionar se uma restauração é necessária. Onde qualquer backup falhas são detectados, recuperação ações devem ser iniciadas. Há também uma necessidade de adquirir e gerir os meios necessários (discos, fitas, CDs, etc) que serão utilizadas para backups, de modo que não há escassez de oferta. No caso de dispositivos automatizados estão a ser utilizados, de pré- carregamento dos meios de comunicação necessários irá ser necessária previamente. Ao carregar e limpar mídia retornados de fora do local de armazenamento, é importante que haja um procedimento para verificar se estes são os corretos. Isso impedirá que o backup mais recente é escrito com dados defeituosos, e depois de não ter dados válidos para restaurar. Depois de backups bem-sucedidos foram tomadas, a mídia deve ser removido para o armazenamento. O início real dos backups podem ser automatizados, ou realizada a partir da Operações Ponte. Algumas organizações podem utilizar equipe de operações para realizar o transporte físico e trasfega de cópias de backup de / para locais remotos, onde, em outros casos, esta pode ser entregues a outros grupos, como interna segurança funcionários ou prestadores de serviços externos. Se os backups estão sendo automatizados ou executadas remotamente, em seguida, recursos de monitoramento de eventos devem ser considerados para que eventuais falhas podem ser detectadas precocemente e corrigidos antes que eles causem problemas. Em tais casos Operações de TI tem um papel a desempenhar na definição alertars e escalada caminhos. Em todos os casos, a equipe de TI Operações devem ser treinados em backup (e restauração) procedimentos - que deve ser bem documentado na ITIL V3 - Operação de Serviço - Página: 180 de 423
    • organização'S operações de TI Manual de Procedimentos. Qualquer específica exigências ou metas deve ser referenciado em UCs OLAs ou se for o caso, enquanto qualquer usuário ou cliente exigências ou atividade deve ser especificado no apropriado SLA. 5.2.3.2 Restaurar A restauração pode ser iniciada a partir de um número de fontes, que vão desde um evento que indica a corrupção de dados, através de um Solicitação de Serviço de um usuário ou cliente logado no Service Desk. A restauração poderá ser necessária no caso de: • Dados corrompidos • Dados perdidos • A recuperação de desastres /De serviços de TI Situação de continuidade • Dados históricos requerido para a investigação forense. As medidas a serem tomadas irão incluir: • Localização dos dados apropriados / mídia • Transporte ou transferência de volta para o físico recuperação localização • Acordo no ponto de recuperação checkpoint e no local específico para os dados recuperados (disco, diretório, etc pasta) • Restauração real do arquivo / dados (cópia de segurança e qualquer roll- back/roll-forward necessário para chegar ao posto de controle concordou • Verificação para garantir a conclusão do restaurar - Com mais recuperação ação se necessário até que o sucesso foi alcançado. • Usuário /cliente sign-off. 5.2.4 impressão e de saída Muitos serviços consistem em gerar e fornecer as informações em forma impressa ou eletrônica. Garantir a informação certa chegue às pessoas certas, com total integridade, Requer formais controlar e gestão. Impressão (física) e de saída (eletrônica) instalações e serviços precisam ser formalmente conseguiu porque: • Eles muitas vezes representam a saída tangível de uma serviço. A capacidade de medir que esta saída atingiu o destino adequado, é muito importante (por exemplo, se a verificação de arquivos com financeira transação dados realmente chegaram a um banco através de um serviço FTP) • Produção física e eletrônica, muitas vezes contém informações sensíveis ou confidenciais. É vital que os níveis adequados de segurança são aplicados tanto a geração como o fornecimento deste produto. ITIL V3 - Operação de Serviço - Página: 181 de 423
    • Muitas organizações terão impressão em massa centralizada exigências que Operações de TI deve lidar. Além da carga física e re-carregamento de papel ea operação e cuidados das impressoras, outras actividades podem ser necessários, tais como: • Acordo e definição de pré-notificação de impressão grande roda e alertars para evitar a impressão excessiva de trabalhos de impressão desonestos • Controle físico de alto valor papelaria, como cheques de empresas ou certificados, etc • Gestão do armazenamento físico e electrónico necessário para gerar a saída. Em muitos casos, vai ser obrigado a fornecer arquivos para os materiais impressos e eletrônicos • Controle de todo o material impresso, de modo a aderir a legislação de protecção de dados e, por exemplo regulação HIPAA (Health Insurance Portability e Accountability Act) no EUA, Ou FSA (Financial Services Authority) na Reino Unido. Quando os serviços de impressão e de saída são entregues diretamente para o usuários, é importante que a responsabilidade pela manutenção das impressoras ou dispositivos de armazenamento é claramente definida. Por exemplo, a maioria dos usuários assumem que a limpeza e manutenção de impressoras deve ser realizada por TI. Se este não é o caso, isso deve ser claramente indicado no SLA. ITIL V3 - Operação de Serviço - Página: 182 de 423
    • 5.3 Gestão Mainframe Mainframes ainda são amplamente utilizados e ter bem estabelecido e maduro práticas. Mainframes formar o centro componente de muitos serviços e seus atuação , portanto, definir um linha de base para as expectativas de desempenho do serviço e do usuário ou cliente, embora nunca pode saber que eles estão usando o mainframe. As formas em que as equipes de gestão de mainframe são organizadas são bastante diversificadas. Em alguns Gestão Mainframe organizações é uma equipe única, altamente especializada, que gerencia todos os aspectos das operações diárias através de sistema engenharia. Em outras organizações, as atividades são realizadas por várias equipes ou departamentos, com engenharia e terceiro nível de apoio a ser prestado por uma equipe e por dia operaçãos a ser combinado com o resto da Operações de TI (E muito provavelmente gerida através do Operações Ponte). Normalmente, as seguintes atividades deverão ser realizadas: • Operacional de mainframe sistema manutenção e suporte • Terceiro nível de suporte para todos os incidentes relacionados / mainframeproblemas • Escrevendo roteiros de trabalho • A programação do sistema • Interface com suporte de hardware (H / W); arranjar manutenção, concordando slots, identificando H / W falha, Ligação com H / W engenharia. • Prestação de informações e assistência aos Gerenciamento da Capacidade para ajudar a alcançar o melhor rendimento, Utilização e atuação do mainframe. ITIL V3 - Operação de Serviço - Página: 183 de 423
    • 5,4 Management Server e suporte Servidors são usados na maioria das organizações de prestação de serviços flexíveis e acessíveis de hospedagem aplicaçãos ou bancos de dados, executando cliente/ Servidor de serviços, armazenamento de impressão e gerenciamento de arquivos. Gestão bem-sucedida de servidores é, portanto, essencial para o sucesso Operação de Serviço. O procedimentos e as atividades que devem ser realizadas pela Equipe Server (s) ou serviço (s) - equipes separadas podem ser necessárias nos casos em servidor diferente tipos são usados (UNIX, Wintel etc) - incluem: • Suporte de sistema operacional: De suporte e de manutenção do sistema operacional apropriado (s) e, relativamente utilidade software (software de failover, por exemplo), incluindo gerenciamento de patches e envolvimento na definição apoio e restaurar políticas. • Gerenciamento de licença para todos os itens de configuração do servidor, não especialmente sistemas operacionais, utilitários e software aplicativo gerenciado pelas equipes de gerenciamento de aplicativos. • Terceiro nível de suporte: Terceiro nível de suporte para todos os servidores e / ou servidor do sistema de operação relacionadas com incidentes, incluindo diagnóstico e recuperação actividades. Isso também irá incluir a ligação com terceiros contratados para suporte a hardware e / ou fabricantes como necessário para escalar hardware incidentes relacionados. • Conselho aquisições: Aconselhamento e orientação para o negócio da seleção, dimensionamento, aquisição e uso de servidores e software utilitário relacionado para atender às necessidades de negócio. • Sistema segurança: Controle e manutenção dos controles de acesso e permissões dentro do servidor relevante ambiente(S), bem como sistema adequado e de medidas de segurança física. Que incluem a identificação e aplicação de patches de segurança, Gerenciamento de Acesso (Ver secção 4.5) e intrusão detecção. • Definição e gestão de servidores virtuais. Isto implica que qualquer servidor que tenha sido projetada e construída em torno de um comum padrão pode ser usado para processo carga de trabalhos de uma gama de aplicações ou usuários. Management Server será necessário para definir esses padrões e, em seguida, garantir que as cargas de trabalho são devidamente equilibrado e distribuído. Eles também são responsáveis por ser capaz de controlar a carga de trabalho que está sendo processado por que servidor de modo que eles são capazes de lidar com incidentes de forma eficaz. • Capacidade e desempenho: Fornecer informações e assistência aos Gerenciamento da Capacidade para ajudar a alcançar o melhor rendimento, Utilização e atuação dos servidores disponíveis. Isto é discutido em mais detalhe na Design de Serviços, Mas inclui o ITIL V3 - Operação de Serviço - Página: 184 de 423
    • fornecimento de orientações sobre, e instalação e operação de, o software de virtualização de modo a alcançar valor para o dinheiro obtendo os mais altos níveis de desempenho e de utilização de um número mínimo de servidores. • Outro atividades de rotina incluem: o Definição de padrão construirs para os servidores como parte do provisionamento processo. Isso é abordado com mais detalhes em Design de Serviços e Transição de Serviço o Construção e instalação de novos servidores como parte de manutenção contínua ou para a prestação de novos serviços. Isto é discutido em mais detalhe na Transição de Serviço o Clusters de criação e gestão, que visam a construção de redundância, Melhorando o desempenho do serviço e fazer a infra- estrutura mais fácil de gerenciar. • Manutenção contínua. Isso normalmente consiste na substituição de servidores ou "lâminas" em uma programação de rolamento para garantir que o equipamento é substituído antes de falhar ou se torna obsoleto. Isso resulta em servidores que não são apenas totalmente funcional, mas também capaz de suportar serviços em evolução • Desmantelamento e eliminação de equipamento servidor antigo. Isso geralmente é feito em conjunto com o organizaçãoPolíticas ambientais "s para eliminação. ITIL V3 - Operação de Serviço - Página: 185 de 423
    • 5,5 Gerenciamento de Rede Como a maioria De serviços de TIs são dependentes de conectividade, gerenciamento de rede será essencial para oferecer serviços e também para permitir Operação de Serviço pessoal para acessar e gerenciar serviço chave componentes. Gerenciamento de rede terá a responsabilidade global para toda a organização próprias redes locais (LANs), Metropolitan Area Networks (MANs) e redes de área ampla (WAN) - e também será responsável pelos contactos com terceiros rede fornecedors. Seu papel irá incluir as seguintes atividades: • Inicial planejamento e instalação de novas redes / componentes de rede, manutenção e upgrades para a infra-estrutura de rede física. Isto é feito através do Design de Serviços e Transição de Serviço. • Terceiro nível de suporte para todas as atividades relacionadas à rede, incluindo a investigação de problemas de rede (por exemplo, ping ou rastreamento de rota e / ou utilização de ferramentas de software de gerenciamento de rede - embora deva ser notado que o ping de um servidor não significa necessariamente que o serviço está disponível! ) de ligação e com terceiros, se necessário. Isto também inclui a instalação e utilização de "ferramentas" farejadores, que analisam o tráfego de rede, para ajudar na incidente e problema resolução. • Manutenção e suporte operacional de rede sistema e middleware incluindo software de gerenciamento de patches, upgrades, etc • Monitoramento de tráfego de rede para identificar falhas ou de detectar potencial atuação ou questões gargalo. • Reconfigurar ou desvios de tráfego para alcançar melhor rendimento ou saldo massa - definição de regras para o balanceamento dinâmico / roteamento. • Rede segurança (Em articulação com o organização'S Gestão de Segurança da Informação), incluindo acesso de firewall, gestão direitos, Proteção de senha etc • Atribuição e gerenciamento de endereços IP, sistemas de nome de domínio (DNSs - que convertem o nome de um serviço para seu endereço IP associado) e Dynamic Host Configuration Protocol (DHCP) de sistemas, que permitem o acesso e uso dos DNS. • Gerenciando Provedor de Serviços de Internets (ISPs). • Execução, monitoramento e manutenção de Sistemas de Detecção de Intrusão em nome de Gestão de Segurança da Informação. Eles também serão responsáveis por assegurar que não há negação de serviço para legitimar usuários da rede. • Atualizando Gerenciamento da Configuração se necessário, documentando CIs, estado,relaçãos, etc ITIL V3 - Operação de Serviço - Página: 186 de 423
    • Gerenciamento de rede também é muitas vezes responsável, muitas vezes em conjunto com o suporte de desktop, por questões de conectividade remota, tais como discagem, dial-back e instalações VPN prestados a casa de trabalho, os trabalhadores remotos ou fornecedors. Algumas equipes de gerenciamento de rede ou departamentos também terá a responsabilidade de voz / telefonia, incluindo o fornecimento e apoio ao intercâmbio, linhas, ACD, pacotes de software estatísticos etc, e para Voice over Internet Protocol (VoIP) e de monitoramento remoto (RMON) sistemas. Ao mesmo tempo, muitas organizações ver VoIP e telefonia como áreas especializadas e têm equipes dedicadas ao gerenciamento desta tecnologia. As suas actividades serão semelhantes aos descritos acima. Nota sobre o gerenciamento de VoIP como serviço Muitas organizações têm experimentado atuação e disponibilidade problemas com a sua VoIP soluções, apesar do facto de que não parece ser mais do que a largura de banda disponível suficiente. Isso resulta em queda de chamadas e som pobres qualidade. Isso geralmente é devido a variações na utilização da largura de banda durante o chamar, O que é frequentemente o resultado da utilização da rede por outros utilizadores, aplicaçãos ou outro web atividade. Isto levou à diferenciação entre a medição da largura de banda disponível para iniciar uma chamada (serviço de acesso de banda - ou SAB) e a quantidade de largura de banda que deve ser continuamente disponível durante a chamada (serviço de banda Utilization - ou SUB). Cuidados devem ser tomados na diferenciação entre estes quando projetar, gerenciar e medir os serviços de VoIP. ITIL V3 - Operação de Serviço - Página: 187 de 423
    • 5,6 Armazenamento e Arquivo Muitos serviços exigem o armazenamento de dados por um tempo específico e também para que os dados estejam disponíveis off-line por um determinado período após ele não é mais usado. Este é muitas vezes devido a regulamentar ou legislativo exigências, mas também porque a história e auditar dados são valiosos para uma variedade de finalidades, incluindo o produto de marketing, desenvolvimento, Investigações forenses, etc A equipe separada ou departamento pode ser necessária para gerir a organizaçãoA tecnologia de armazenamento de dados, tais como: • Dispositivos de armazenamento, como discos, controladores, fitas, etc • Network Attached Storage (NAS), que é de armazenamento conectado a uma rede e acessível por vários clientes • Armazenamento Area Networks (SAN) destinados a conectar dispositivos de armazenamento de computador, tais como controladores de matriz de disco e bibliotecas de fitas. Para além de dispositivos de armazenamento, uma SAN vai exigir também a gestão de rede diversos componentes, como hubs, cabos, etc • Direct Attached Storage (DAS), o qual é um dispositivo de armazenamento ligado directamente a um servidor • Armazenamento de conteúdo endereçável (CAS), que é o armazenamento que é baseado em recuperação de informação com base no seu teor em vez de localização. O foco neste tipo de sistema é na compreensão da natureza dos dados e informações armazenados, em vez do que em proporcionar locais de armazenamento específicos. Independentemente do tipo de sistemas de armazenamento estão sendo utilizados, armazenamento e arquivamento vai exigir o gerenciamento dos componentes da infra-estrutura, bem como as políticas relacionadas ao local onde os dados são armazenados, por quanto tempo, de que forma e quem pode acessá-lo. Responsabilidades específicas incluirão: • Definição de políticas de armazenamento de dados e procedimentos • Convenções de armazenamento de arquivos de nomenclatura, hierarquia e as decisões de colocação • Projeto, dimensionamento, seleção, aquisição, configuração e operação de toda a infra-estrutura de armazenamento de dados • Manutenção e suporte para todos utilidade e middleware de armazenamento de dados de software • Ligação com Informação Ciclo de Vida Gestão de equipe (s) ou Governo equipes para garantir observância com a liberdade de informação de protecção de dados, governança de TI e regulamentações • Envolvimento com definição e acordo de arquivamento política ITIL V3 - Operação de Serviço - Página: 188 de 423
    • • Limpeza de todas as instalações de armazenamento de dados • Arquivamento de dados de acordo com regras e horários definidos durante Design de Serviços. As equipes de armazenamento ou departamentos irá igualmente contribuir para a definição dessas regras e irá fornecer relatórios sobre a sua eficácia como entrada para futuro projeto • Recuperação de dados arquivados que for necessário (por exemplo, para fins de auditoria, a evidência forense, ou para atender a todos os requisitos de outras empresas) • Terceira linha de apoio para armazenamento e arquivamento de incidentes relacionados. ITIL V3 - Operação de Serviço - Página: 189 de 423
    • 5,7 Database Administration Administração de banco de dados deve trabalhar em estreita colaboração com a chave Aplicação de Gestão de equipes ou departamentos e em algumas organizações a funçãos podem ser combinados ou ligados em uma única estrutura de gestão. Opções organizacionais incluem: • Administração de banco de dados que está sendo realizada por cada equipe de Gerenciamento de Aplicativos para todos os aplicaçãos sob seu controle • Um departamento dedicado, que gerencia todas as bases de dados, independentemente do tipo ou aplicação • Vários departamentos, cada um gerenciando um tipo de banco de dados, independentemente de qual aplicativo eles fazem parte. Administração de banco de dados trabalha para garantir o melhor atuação,segurança e funcionalidade de bancos de dados que gerenciam. Administradores de banco de dados normalmente têm as seguintes responsabilidades: • Criação e manutenção de banco de dados padrãoe as políticas • Banco de dados inicial projeto, Criação de testes, • Gestão da base de dados disponibilidade e desempenho; resiliência, Dimensionamento capacidade volumetria etc • Resiliência pode exigir a replicação de banco de dados, que seria de responsabilidade da Administração do Banco de Dados • Administração contínua de objetos de banco de dados: tabelas, índices, visões, restrições, seqüências de instantâneos e armazenados procedimentos; bloqueios de página - para alcançar melhor utilização • A definição de gatilhos que irão gerar eventos, que por sua vez irá alertar administradores de banco de dados de desempenho ou potencial integridade problemas com o banco de dados • Execução de limpeza de banco de dados - as tarefas de rotina que assegurem que os bancos de dados estão funcionando de forma otimizada e segura, por exemplo, afinação, Indexação, etc • Monitoramento de uso; transação volumes, tempo de respostas, simultaneidade níveis, etc • Geração de relatórios. Estes poderiam ser os relatórios com base nos dados no banco de dados ou relatórios relacionados com o desempenho ea integridade do banco de dados • Relatórios de identificação e gestão de questões de segurança de banco de dados; auditar trilhas e forenses • Assistência na elaboração de banco de dados apoio, Arquivamento e armazenamento estratégia • Assistência na alertas dados concepção e gestão de eventos ITIL V3 - Operação de Serviço - Página: 190 de 423
    • • Prestação de terceiro nível de suporte de banco de dados para todos os incidentes relacionados. ITIL V3 - Operação de Serviço - Página: 191 de 423
    • 5,8 Diretório de Gestão de Serviços AServiço de Diretório é um software especializado que gerencia informações sobre o recursoEstá disponível em uma rede e quais os usuários têm acesso. É a base para fornecer acesso a esses recursos e para garantir que o acesso não autorizado é detectado e impedido (ver secção 4.5 para informações detalhadas sobre Gerenciamento de Acesso). Directory Services vê cada recurso como um objeto do Diretório Servidor e atribui-lhe um nome. Cada nome está ligado ao endereço do recurso de rede, de modo que usuários não tem que memorizar endereços confusos e complexos. Directory Services é baseado em X.500 da OSI padrãos e comumente utiliza protocolos como o Directory Access Protocol (DAP) ou Lightweight Directory Access Protocol (LDAP). LDAP é utilizado para apoiar as credenciais do usuário para aplicação login e muitas vezes inclui usuário interno e externo /cliente dados que é especialmente bom para extranet chamar registro. Desde LDAP é um crítico operacional ferramenta, e geralmente mantido até à data, também é uma boa fonte de dados e verificação para o CMS. Gestão de Serviços de Diretório refere-se ao processo que é usado para gerenciar Directory Services. Suas atividades incluem: • Trabalhando como parte de Design de Serviços e Transição de Serviço para garantir que os novos serviços são acessíveis e controlados quando eles são implantados • Localização de recursos em uma rede (se não já foram definidos durante Service Design) • O acompanhamento do estado desses recursos e fornecendo a capacidade de gerir esses recursos remotamente • Gerenciando o direitos de específica usuários ou grupos de usuários para acessar recursos em uma rede • Definir e manter as convenções de nomenclatura para serem utilizados para os recursos numa rede • Assegurar a coerência de nomeação e acesso controlar em diferentes redes do organização • Ligando diferente Serviço de Diretórios em toda a organização para formar um serviço de diretório distribuído, ou seja, os usuários só vai ver um conjunto lógico de recursos de rede. Isso é chamado de Distribuição de Serviços de Diretório • Monitorando eventos sobre os Serviços de Diretório, como tentativas para acessar um recurso, e tendo a ação apropriada quando necessário • Manutenção e atualização das ferramentas utilizadas para gerenciar Directory Services. ITIL V3 - Operação de Serviço - Página: 192 de 423
    • 5,9 Desktop Support Como a maioria o acesso de usuários De serviços de TIs usando computadores desktop ou laptop, é fundamental que estes são suportados para garantir os níveis acordados de disponibilidade e atuação de serviços. Suporte de mesa terá a responsabilidade global para toda a área de trabalho da organização e hardware de computador portátil, software e periféricos. Responsabilidades específicas incluirão: • Políticas de desktop e procedimentos, por exemplo, as políticas de licenciamento, uso de laptops ou desktops para fins pessoais, USB bloqueio, etc • Projetando e concordando imagens de desktop padrão • Área de trabalho de manutenção do serviço, incluindo desenvolvimento de liberars, upgrades, patches e correções (hot-em conjunto com Gerenciamento de Liberação (Ver publicação Transição de Serviço para mais detalhes) • Concepção e implementação de área de trabalho de arquivamento / reconstruir política (Incluindo a política relativa aos cookies, favoritos, modelos, dados pessoais, etc) • Terceiro nível de suporte do ambiente de trabalho relacionados com incidentes, incluindo mesa as visitas sempre que necessário • Suporte para problemas de conectividade (em conjunto com o gerenciamento de rede) para a casa de trabalho, o pessoal móvel, etc • Controle de configuração e auditar de todos os equipamentos de área de trabalho (em conjunto com Gerenciamento da Configuração e Auditoria de TI). ITIL V3 - Operação de Serviço - Página: 193 de 423
    • 5,10 Middleware Gestão Middleware é um software que conecta ou integra software componentes em todo distribuída ou díspar aplicaçãos e sistemas. Middleware permite a efetiva transferência de dados entre aplicações, e é, portanto, fundamental para serviços que dependem de vários aplicativos ou fontes de dados. Uma variedade de tecnologias são atualmente usados para apoiar o programa para programa de comunicação, como corretores de solicitação de objetos, middleware orientado a mensagem, controle remoto procedimento chamadas e serviços ponto-a-ponto web. Mais recentes tecnologias estão surgindo o tempo todo, por exemplo Enterprise Service Bus (ESB), que permite que os programas, sistemas e serviços para se comunicar uns com os outros, independentemente da arquitetura e origem das aplicações. Isto é especialmente utilizado no contexto da implantação Service Oriented Architectures (SOA). Middleware Management pode ser realizada como parte de um Aplicação de Gestão de função (Em que é dedicado a uma aplicação específica), ou como parte de um Gestão Técnica função (onde ele é visto como uma extensão para o sistema operacional de uma plataforma específica). Funcionalidade fornecida pelo middleware inclui: • Fornecer mecanismos de transferência de dados de várias aplicações ou fontes de dados • O envio de trabalho para outra aplicação ou procedimento para o processamento • Transmissão de dados ou informações para outros sistemas, tais como dados de sourcing para publicação em sites (por exemplo, publicação de Incidentes estado informação) • Liberando atualizados módulos de software em todo distribuído ambientes • Agrupamento e distribuição de mensagens do sistema e instruções, por exemplo, eventos ou operacional scripts que precisam ser executados em dispositivos remotos • Configuração de multicast com redes. Multicast é a entrega de informações a um grupo de destinos em simultâneo através da rota de entrega mais eficiente • Gerenciando tamanhos de fila. Middleware Management é o conjunto de atividades que são usados para gerenciar middleware. Estes incluem: • Trabalhando como parte de Design de Serviços e Transição para garantir que o apropriado middleware As soluções são escolhidas e que eles possam desempenhar optimamente quando eles são implantados ITIL V3 - Operação de Serviço - Página: 194 de 423
    • • Garantir a correta operação de middleware através de monitoramento e controlar • Detecção e resolução de incidentes relacionados com middleware • Manutenção e atualização de middleware, incluindo o licenciamento e instalação de novo versãos • Definir e manter informações sobre como aplicaçãos estão ligados através de Middleware. Isso deve ser parte da CMS (ver Transição de Serviço publicação). ITIL V3 - Operação de Serviço - Página: 195 de 423
    • 5,11 Gestor da Internet / Web Muitas organizações conduzir muito de seu negócio através da Internet e são, portanto, fortemente dependente do disponibilidade e atuação de seus sites. Nesses casos, uma equipe de suporte em separado Internet / Web ou departamento será desejável e justificado. As responsabilidades de uma equipe ou departamento de incorporar tanto Intranet e Internet e é provável que incluem: • Definindo arquiteturas para serviços de Internet e web • O especificação de padrãos para desenvolvimento e gestão de aplicações baseadas na web, conteúdo, sites e páginas da web. Este será tipicamente feito durante Design de Serviços • Design, testes, implementação e manutenção de websites. Isso irá incluir a arquitetura de sites eo mapeamento de conteúdo a ser disponibilizado • Em muitas organizações, o gerenciamento web irá incluir a edição do conteúdo a ser postado na web • Manutenção de todo o desenvolvimento web e gerenciamento de aplicativos • Ligação e conselhos para web-conteúdo equipes dentro da empresa. O conteúdo pode residir em aplicativos ou dispositivos de armazenamento, o que implica uma estreita ligação com Aplicação de Gestão de e outros Gestão Técnica equipes • Ligação e gestão de fornecedores dos ISPs, os anfitriões, o monitoramento de terceiros ou de organizações de virtualização etc Em muitas organizações os ISPs são gerenciados como parte de Gerenciamento de Rede • Terceiro nível de suporte para incidentes Internet-/web-related • Suporte para interfaces com back-end e legado sistemas. Isso muitas vezes significa trabalhar com os membros do Desenvolvimento de Aplicações e equipas de gestão para garantir acesso seguro e consistência de funcionalidade • Monitoramento e gerenciamento de desempenho do site e incluindo: testes de batimentos cardíacos, usuário simulação experiência, aferição, On-demand de balanceamento de carga de virtualização, • Site disponibilidade,resiliência e segurança. Isto fará parte do conjunto Gestão de Segurança da Informação do organização ITIL V3 - Operação de Serviço - Página: 196 de 423
    • 5,12 Instalações e Data Management Centre Gestão de Instalações refere-se à gestão da física ambiente de Operações de TI, Geralmente localizados nos centros de dados ou salas de informática. Esta é uma área vasta e complexa e esta publicação irá fornecer uma visão geral de sua chave papel e atividades. Uma visão mais detalhada está contida no Anexo E. Em muitos aspectos, Gestão de Instalações poderia ser visto como um função em seu próprio direito. No entanto, por causa desta publicação está focada em que as operações de TI estão alojados, cobrirá Facilities Management especificamente no que se refere à gestão dos centros de dados e, como um subconjunto da TI Gestão de Operações função. O principal componentes de Gestão de Instalações são as seguintes: • Gestão de Edifícios, Que refere-se à manutenção e conservação dos prédios que abrigam o Centro de TI pessoal e de dados. As atividades típicas incluem limpeza, eliminação de resíduos, gestão do estacionamento e acesso controlar • Equipamentos de hospedagem, O que garante que todo especial exigências são fornecidos para a habitação física de equipamentos e as equipes que os suportam • Gerenciamento de energia, A qual refere-se a gerir o fornecimento e utilização de fontes de energia que são utilizados para manter a unidade funcional. Esta definição de gerenciamento de energia tem uma série de implicações, que são discutidos no Apêndice E. Nota que as informações sobre utilização de energia é importante para a planejamento o capacidade de ambos os novos serviços e novas construções • Condicionamento ambiental e Alertar Sistemas, Os quais incluem o especificaçãoE manutenção monitoramento de sistemas como a detecção de fumaça e combate a incêndios, de água, sistemas de aquecimento e refrigeração, etc • Segurança refere-se observância a toda a legislação, padrãos e políticas em relação à segurança dos empregados • Controle de Acesso Físico refere-se a assegurar que a instalação só é acessado por pessoal autorizado e que qualquer acesso não autorizado é detectado e gerenciado. Isto é discutido em mais detalhe no Apêndice F • Envio e recebimento refere-se à gestão de todos os equipamentos, móveis, correio, etc, que sai ou entra no edifício. Ele garante que somente itens apropriados estão entrando ou saindo do prédio e que eles são encaminhados para a festa correta • Envolvimento em Gestão de Contratos dos vários fornecedors e provedor de serviçoss envolvidas na instalação ITIL V3 - Operação de Serviço - Página: 197 de 423
    • • Manutenção refere-se a manutenção, regulares programadas da instalação, bem como a detecção e resolução de problemas com a facilidade. Nota importante sobre os Centros de Dados Centros de dados são geralmente unidades especializadas e, enquanto eles usam e se beneficiar de genéricos disciplinas Facilities Management, eles precisam se adaptar estes. Por exemplo aquecimento layout, e poder condicionado, planejamento e muitos outros aspectos são geridos exclusivamente em Centros de Dados. Isto significa que, apesar de centros de dados pode ser detida por um instalações organização, Eles são melhor geridas sob a autoridade do Operações de TI, Embora possa haver uma linha de comunicação funcional entre a TI eo departamento que gerencia outras facilidades para a organização. 5.12.1 Dados estratégias Centro Gerenciando um Centro de Dados é muito mais do que hospedar um espaço aberto onde grupos técnicos instalar e gerenciar equipamentos, utilizando as suas próprias abordagens e procedimentos. Ela exige um conjunto integrado de processos e procedimentos envolvendo todos os grupos de TI em todas as fases do ITSM Ciclo de Vida. Centro de Dados operaçãos são regidas pela estratégico e projeto decisões para o manejo e controlar e são executadas pelos operadores. Isso exige uma série de fatores-chave a serem postas em prática: • Dados Automação Centro. Automação especializado sistemas, que reduzem a necessidade de operadores manual e que monitorar e acompanhar o estado da instalação e todos Operações de TI sempre • PolíticaGestão baseada em onde as regras de automação e recurso alocação são geridos pela política, ao invés de ter que passar por complexo mudar procedimentos de processamento a cada momento é movido de um recurso para outro • Serviços de tempo real 24 horas por dia, 7 dias por semana • Normalização do equipamento. Isso proporciona maior facilidade de gerenciamento, os níveis mais consistentes de atuação e um meio de fornecimento de serviços múltiplos através de tecnologia semelhante. Padronização também reduz a variedade de conhecimentos técnicos necessários para gerir equipamentos no Centro de Dados e para fornecer serviços • SOAs, Onde o serviço componentes pode ser reutilizado, trocadas e substituído muito rapidamente e sem impacto sobre o negócio. Isto tornará possível para o Centro de Dados para ser altamente responsivo em atender às demandas empresariais em constante mudança, sem ter de passar pelo demorado e complicado re-engenharia e rearquitetura ITIL V3 - Operação de Serviço - Página: 198 de 423
    • • Virtualização. Isto significa que, De serviços de TIs são entregues através de um conjunto em constante mudança de equipamentos, voltados para atender a demanda atual. Por exemplo, um aplicativo pode ser executado em um dispositivo dedicado juntamente com o seu banco de dados durante a alta demanda vezes, mas mudou para um dispositivo compartilhado com seu banco de dados em um dispositivo remoto não durante horários de pico - tudo automatizado e automático. Isto significa uma economia ainda maior de custars como qualquer equipamento pode ser usado a qualquer momento, sem qualquer intervenção humana, exceto para realizar a manutenção e substituição de equipamentos falhou. O Infraestrutura de TI é mais resiliente porque qualquer componente é apoiada por qualquer número de componentes semelhantes, qualquer um dos quais pode ter mais de um componente falha carga de trabalho automaticamente. Remoto monitoramento,controlar e equipamentos de sistemas de gestão e será essencial para gerenciar uma virtualizado ambiente, Como muitos serviços não será ligada a qualquer uma peça específica do equipamento. • Unificado sistema de gestãos tornaram-se mais importante como os serviços são executados em vários locais e tecnologias. Hoje, é importante definir que ações devem ser tomadas e que sistemas vai executar essa ação. Isso significa investir em soluções que permitam aos gerentes de infra-estrutura simplesmente especificar o que resultado é necessário, e permitindo que o sistema de gestão para calcular a melhor combinação de instrumentos por forma a atingir o resultado. ITIL V3 - Operação de Serviço - Página: 199 de 423
    • 5,13 Gestão de Segurança da Informação e Operação de Serviço Gestão de Segurança da Informação como processo é abordado no ITIL Design de Serviços publicação. Gestão de Segurança da Informação tem a responsabilidade global para definição de políticas, padrãos e procedimentos para assegurar a protecção da organização'S ativoss, dados, informações e De serviços de TIs. Operação de Serviço equipes jogam um papel na execução dessas políticas, normas e procedimentos e trabalhará em estreita colaboração com as equipes ou departamentos responsáveis de Gestão de Segurança da Informação. Equipes de operação de serviço não pode tomar posse de Gestão de Segurança da Informação, isso representaria um conflito. É preciso haver segregação de funções entre os grupos de definir e gerir o processo e os grupos que executam atividades específicas como parte do curso operação. Isso vai ajudar a proteger contra violações de segurança medidas, como nenhum indivíduo deve ter controlar ao longo de dois ou mais fases de um transação ou operação. Gestão de Segurança da Informação deve atribuir responsabilidades para garantir uma verificação cruzada de funções. O papel das equipes de operação de serviço é descrito a seguir. 5.13.1 Policiamento e relatórios Isso vai envolver a equipe Operação realizar atividades específicas de policiamento, tais como a verificação de revistas, logs de sistema, evento/monitoramento alertars etc, intrusão detecção e / ou relatórios de violações de segurança reais ou potenciais. Isso é feito em conjunto com a Gestão de Segurança da Informação para fornecer um sistema de verificação e equilíbrio para garantir a detecção e gestão eficaz dos problemas de segurança. Pessoal Operação de Serviço são muitas vezes primeiro a detectar eventos de segurança e estão em melhor posição para ser capaz de desligar e / ou remover o acesso a sistemas comprometidos. Particular atenção será necessária no caso de organizações de terceiros que requerem acesso físico à organização. Pessoal Operação de Serviço pode ser obrigado a escoltar visitantes em áreas sensíveis e / ou controlar o seu acesso. Eles também podem ter um papel a desempenhar no controle de acesso de rede a terceiros, como mantenedores de hardware discando para fins de diagnóstico, etc ITIL V3 - Operação de Serviço - Página: 200 de 423
    • 5.13.2 Assistência técnica Alguns suporte técnico pode precisar de ser fornecida para a equipe de TI de Segurança para ajudar na investigação de incidentes de segurança e auxiliar na produção de relatórios ou na coleta de provas forenses para uso em ação disciplinar ou processos criminais. Consultoria e assistência técnica também pode ser necessária em relação a melhorias de segurança em potencial (por exemplo, a criação de firewalls apropriadas ou acesso / senha controles). O uso de evento, incidente,problema e gerenciamento de configuração informação pode ser invocado para fornecer cronologias precisas de segurança relacionados com as investigações. 5.13.3 controle de segurança operacional Para operacional razões, o pessoal técnico, muitas vezes, precisa ter acesso privilegiado às principais áreas técnicas (por exemplo, raiz sistema senhas, o acesso físico aos dados Centros ou etc comunicações quartos). É, portanto, essencial que controles adequados e auditar trilhas são mantidos de todas essas atividades privilegiadas, de modo a prevenir e detectar qualquer segurança eventos. Controles físicos precisam estar no local para todas as áreas seguras com o login-out de todos os funcionários. Onde terceiro funcionários ou visitantes precisam de acesso, pode ser Operação de Serviço funcionários que são responsáveis pela escolta e gerir o movimento desse pessoal. No caso de sistemas de acesso privilegiado, isso precisa ser restrito a apenas aquelas pessoas cuja necessidade de acessar o sistema foi verificado - e retirado imediatamente quando essa necessidade não existe mais. Uma trilha de auditoria deve ser mantida de quem tem acesso e quando teve, e de todas as atividades realizadas com os níveis de acesso. 5.13.4 Seleção e habilitação Todo o pessoal Operação de Serviço deverão ser avaliados e controlados a um nível de segurança adequado ao organização em questão. Fornecedors e de terceiros contratados também devem ser avaliados e controlados - ambas as organizações e os específicos de pessoal envolvido. Muitas organizações começaram a usar a polícia ou do governo de antecedentes da agência, especialmente onde os contratantes estarão trabalhando com sistemas de classificados. Sempre que necessário, as organizações não-revelação e confidencialidade acordos deve ser acordado. ITIL V3 - Operação de Serviço - Página: 201 de 423
    • 5.13.5 Treinamento e conscientização Todo o pessoal Operação de Serviço deve ser dada formação regular e contínua e consciência da organização do política de segurança e procedimentos. Este deve incluir detalhes de medidas disciplinares no lugar. Além disso, a segurança de qualquer exigências deve ser especificado no do empregado contrato de emprego. 5.13.6 políticas e procedimentos documentados Procedimentos de serviço de operação documentados deve incluir todas as informações pertinentes relativas a questões de segurança - extraído da política de segurança da organização geral documentos. Deve-se considerar a utilização de manuais para auxiliar na obtenção das mensagens de segurança para todo o pessoal relevante. ITIL V3 - Operação de Serviço - Página: 202 de 423
    • 5,14 Melhoria das actividades operacionais Todo o pessoal Operação de Serviço deve ser constantemente à procura de áreas em que processo melhorias podem ser feitas para dar maior De serviços de TI qualidade e / ou executados de forma mais rentável. Isto pode incluir algumas das seguintes atividades. 5.14.1 automação de tarefas manuais Quaisquer tarefas que têm de ser realizadas manualmente, particularmente aqueles que têm de ser regularmente repetido, são susceptíveis de ser mais demorada, dispendiosa e erro propensos do que os que podem ser sistematizado e automatizado. Todas as tarefas devem ser examinados para automação potencial para reduzir o esforço e custars e para minimizar os erros potenciais. A decisão deve ser feita na custars da automação e os prováveis benefícios que irão ocorrer. 5.14.2 Rever atividades improvisadas ou procedimentos Devido à natureza pragmática de Operação de Serviço, Que por vezes pode surgir de que as atividades improvisadas ou processos são introduzidos para resolver a curto prazo operacional expedientes. Existe o perigo de que tal práticas pode ser continuado e tornar-se a "norma" - levando a ineficiências em curso. Onde quaisquer atividades ou improvisados procedimentos tem de ser introduzida, é importante que estas sejam revered, logo que a oportunidade imediata é superar - e, ou suprimida ou substituída por processos eficientes acordados para o prazo mais longo. 5.14.3 Auditorias Operacionais Regular auditars deve ser conduzida de todos os processos de operação de serviço para garantir que eles estão trabalhando de forma satisfatória. 5.14.4 Usando o Gerenciamento de Incidentes e de Problemas Problema e Gerenciamento de Incidentes proporcionar uma fonte rica de operacional oportunidades de melhoria. Esses processos são discutidos em detalhe no capítulo 4 desta publicação. 5.14.5 Comunicação Deve ir sem dizer que a boa comunicação sobre a mudança exigências, a tecnologia e os processos resultará em melhoria na operação do serviço. No ITIL V3 - Operação de Serviço - Página: 203 de 423
    • entanto, a comunicação é muitas vezes negligenciada. Melhoria Operação serviço é dependente da comunicação formal e regular entre as equipes responsáveis pela projeto, Suporte e operação de serviços. 5.14.6 A educação ea formação Equipes de operação de serviço deve compreender a importância do que fazem em uma base diária. Educação é necessária para garantir que o pessoal entender o que o negócio funçãos ou serviços são suportados por suas atividades. Isso irá incentivar um maior cuidado e atenção aos detalhes e também vai ajudar as equipes de operação do serviço, para melhor identificar as prioridades de negócios. Treinamento programas deve assegurar que todos os funcionários têm as habilidades necessárias para a tecnologia ou aplicaçãos que eles estão conseguindo. A formação deve ser sempre fornecida quando uma nova tecnologia é introduzida, ou quando a tecnologia existente é alterado. ITIL V3 - Operação de Serviço - Página: 204 de 423
    • 6 Organizador para Operação de Serviço 6.1 Funções Afunção é um conceito lógico que se refere ao povo e medidas automatizadas que executam um definido processo, Um atividade ou uma combinação de processos ou atividades. Em organizações maiores uma função pode ser dividida e executada por vários departamentos, equipes e grupos, ou pode ser incorporado dentro de uma única unidade organizacional. Figura 6.1 Funções de operação de serviço ITIL V3 - Operação de Serviço - Página: 205 de 423
    • A Operação de Serviço funçãos dado na Figura 6.1 são necessários para gerir o "estado estável" operacional TI ambiente. Estas são funções lógicas e não necessariamente tem que ser feita por uma estrutura equivalente organizacional. Isto significa que a técnica e Aplicação de Gestão de podem ser organizados em qualquer combinação e em qualquer número de departamentos. Os agrupamentos de segundo nível na Figura 6.1 são exemplos de grupos típicos de atividades realizadas por Gestão Técnica (Ver Capítulo 5) e não são uma sugestão organização estrutura. A seguir, um resumo das principais funções de Serviço de Operação na Figura 6.1: • O Service Desk é o principal ponto de contato para usuários quando há uma serviço interrupção, por solicitação de serviços ou até mesmo para algumas categorias de Requisição de Mudança. O Service Desk fornece um ponto de comunicação com os usuários e um ponto de coordenação para vários grupos de TI e processos. Para habilitá-los para realizar essas ações efetivamente o Posto de Serviço é normalmente separado dos outros Funções de operação de serviço. Em alguns casos, por exemplo, onde detalhada suporte técnico é oferecida aos usuários no primeiro chamar, Pode ser necessário para a técnica ou Aplicação de Gestão de equipe para estar no Service Desk. Isso não significa que o Service Desk se torna parte de theTechnical função de Gestão. De fato, enquanto eles estão no Service Desk, eles deixam de ser uma parte da gestão técnica ou funções de gerenciamento de aplicativos e tornar-se parte do Service Desk, mesmo que apenas temporariamente. • Gestão Técnica fornece detalhadas habilidades técnicas e recursos necessários para suportar o curso operação do Infraestrutura de TI. Gestão Técnica também desempenha um importante papel no projeto, Testes, liberar e melhoria das De serviços de TIs. Em pequenas empresas, é possível gerenciar essa experiência em um único departamento, mas as grandes organizações são normalmente dividida em vários departamentos especializados tecnicamente (ver mais adiante neste capítulo). Em muitas organizações, os departamentos de Gestão técnicos são também responsáveis pela operação diária de um subconjunto da infra-estrutura de TI. A Figura 6.1 mostra que, embora sejam parte de um departamento de gestão técnica, funcionários que realizam essas atividades são logicamente parte da função de Gerenciamento de Operações de TI. • TI Gestão de Operações é a função de responsável pela diária operacional atividades necessárias para gerenciar a infra-estrutura de TI. Isso é feito de acordo com o desempenho Padrãos definido durante Design de Serviços. Em algumas organizações este é um departamento único e centralizado, enquanto em outros algumas atividades e funcionários são centralizados e alguns são fornecidos por departamentos distribuídos ou especializada. Isto é ilustrado na Figura 6.1 pela ITIL V3 - Operação de Serviço - Página: 206 de 423
    • sobreposição de funções de gestão técnica e de aplicativos. Gestão de Operações de TI tem duas funções que são únicas e que são geralmente formais estruturas organizacionais. Estes são os seguintes: • Operações de TI Controle, O qual é geralmente composta por deslocars de operadores e que assegura que as tarefas rotineiras operacionais são realizadas. Controle de Operações de TI também irá fornecer centralizado monitoramento e controlar actividades, geralmente usando uma Operações Ponte ou Centro de Operações de Rede. • Gestão de Instalações refere-se à gestão da TI física ambiente, Geralmente centros de dados ou salas de informática. Em muitas organizações Técnica e Gerenciamento de Aplicativos são co- localizado com Operações de TI nos Centros de dados grandes. Em algumas organizações muitas física componentes da Infraestrutura de TI foram terceirizados e gestão de instalações podem incluir a gestão do terceirização contratos. • Aplicação de Gestão de é responsável pela gestão aplicaçãos ao longo da sua ciclo de vida. O Gerenciamento de Aplicativos função suporta e mantém operacional aplicações e também desempenha um importante papel no projeto, Teste e aperfeiçoamento de aplicações que fazem parte do De serviços de TIs. Gerenciamento de Aplicativos é geralmente dividida em departamentos com base no portfólio de aplicativos do organização (Veja os exemplos na figura 6.1), permitindo assim mais fácil de especialização e de mais apoio focado. Em muitas organizações departamentos de gestão de aplicativos têm funcionários que realizam diariamente operaçãos para esses aplicativos. Tal como acontece com Gestão Técnica, Esse pessoal logicamente parte do TI Gestão de Operações função. Nota especial sobre Gestão de Segurança da Informação Embora a maioria concorda que a Gestão de Segurança da Informação é um função, É altamente especializada e abrange diversas fases do ciclo de vida. Também é responsável pela supervisão de muitas atividades dentro de tudo Operação de Serviço funções. Para uma descrição mais aprofundada de Gestão de Segurança da Informação, por favor consulte o Design de Serviços publicação e de seção 5.13 desta publicação. 6.1.1 Funções e atividades Capítulo 5 desta publicação introduziu uma série de atividades de operação comum de serviço. Devido à natureza técnica e especialização dessas atividades, as equipes, grupos ou departamentos que os executam são muitas vezes recebem nomes que correspondem às atividades particulares. Por exemplo, Gerenciamento de Rede pode ser realizado por um 'Departamento de Gestão de Rede ". Isto, no entanto, é de modo nenhum uma regra. Há um ITIL V3 - Operação de Serviço - Página: 207 de 423
    • número de opções disponíveis no mapeamento atividades para uma equipe ou departamento, por exemplo: • Um atividade poderia ser realizada por várias equipes ou departamentos, por exemplo, se uma organização tem cinco departamentos principais aplicativos de apoio, cada um apoiando um conjunto diferente de aplicativos, cada um destes departamentos pode executar a Administração de banco de dados para aplicações de 'suas' • Um departamento pode realizar várias actividades, como por exemplo do Departamento de Gestão de Rede pode ser responsável pela gestão da rede, Serviço de Diretórios Gestão e Servidor Gestão • Uma actividade pode ser realizada, por exemplo, por grupos Administração de Segurança pode ser realizada por qualquer pessoa com a responsabilidade de gerir uma aplicação de servidor, middleware ou desktop. Estas decisões organizacionais são influenciadas por uma série de factores, tais como: • A dimensão e localização da organização. Menores, as organizações menos distribuídos tendem a combinar essas funções, enquanto que empresas grandes e descentralizadas pode ter várias equipes ou departamentos realizando o mesmo atividade (Por exemplo, por região). • A complexidade da tecnologia utilizada no organização. Quanto maior o número de diferentes tecnologias utilizadas, o mais provável, há de ser várias equipes diferentes, cada um fazendo algo semelhante, mas em um contexto diferente (por exemplo, UNIX Servidor Gestão e de gerenciamento do Windows Server). • O disponibilidade de competências. Onde as habilidades técnicas são escassos, é comum que as organizações usem generalistas para executar vários grupos de atividades - embora, em alguns casos, segurança considerações tornam isso muito difícil. Por exemplo, uma organização que trabalha em classificados ou segredo projetos pode ter que contratar caro, especializado recursos, mesmo quando isso significa que realocá-los ou contratação através de segurança-Limpou fornecedores. • O cultura da organização. Algumas organizações preferem trabalhar em altamente especializada ambientes, enquanto outros tendem a preferir a flexibilidade da equipe generalista. • A situação financeira da organização vai determinar quantas pessoas, com que tipo de habilidade, pode ser empregada e como eles serão organizados. Como resultado desses fatores, é impossível para esta publicação para prescrever uma estrutura organizacional adequada que vai caber a cada situação, no entanto, as seções a seguir listam as atividades necessárias sob os ITIL V3 - Operação de Serviço - Página: 208 de 423
    • grupos funcionais mais propensos a se envolver em seu operação. Por favor, note que isso não significa que todas as organizações têm de usar essas divisões. Organizações menores tendem a combinar essas atividades em departamentos individuais, ou mesmo indivíduos - se eles são mesmo necessários em tudo. Nota especial sobre terceirização Estas considerações organizacionais tendem a ser mais relevante para as organizações de TI internos. A situação se torna ainda mais complexa quando parte ou a totalidade de uma determinada atividade ou função são terceirizados. Excelentes oportunidades para a terceirização tem sido o Service Desk e Operações de Rede. Isto será explicado em mais pormenor na ITIL Orientação complementar, mas alguns dos pontos-chave para se lembrar são: • Independentemente de quem está realizando o atividade, A empresa que contrata o contratante ainda é responsável por garantir que ele é realizado para uma padrão que irá apoiar a prestação de serviços aos seus clientes e usuários. • Terceirização para resolver de uma organização problemas ou como uma alternativa ao bom Serviço de Gestão de processos raramente funciona. Os melhores resultados são obtidos quando estes estão em vigor antes da terceirização. • Terceirização funciona melhor quando há o envolvimento ativo de ambas as organizações. Se a equipe e gerentes da organização do cliente desengatar, o contratante é improvável que seja bem sucedido, simplesmente porque ninguém entende a organização melhor do que as pessoas que trabalham lá. • O contratante não deve determinar suas saídas ou como eles são medidos. Estas são determinadas através da compreensão da empresa exigências de usuários e clientes e garantir que eles possam ser atendidas pelos recursos de que o contratante do. • Embora os serviços que o contratante se tornam parte integrante do organização, Eles ainda são uma organização de terceiros, com um conjunto diferente de objetivo de negócios, políticas e práticas. Segurança padrãos deve ser acolhida e ambas as partes devem entender claramente seus respectivos papels e contribuições. ITIL V3 - Operação de Serviço - Página: 209 de 423
    • 6,2 Service Desk AService Desk é uma unidade funcional formada por um número específico de pessoal responsável pelo tratamento de uma variedade de serviços eventos, muitas vezes feita através de chamadas telefónicas, interface web, ou eventos de infra-estrutura automaticamente notificados. O Service Desk é uma parte vital do Departamento de TI de uma organização e deve ser o único ponto de contato para TI usuários em uma base dia-a-dia - e irá lidar com todos os incidentes e solicitação de serviços, geralmente usando ferramentas de software especializados para registrar e gerenciar todos esses eventos. O valor de um Service Desk eficaz não deve ser subestimado - um Service Desk bom muitas vezes pode compensar deficiências em outras partes da organização de TI, mas um Service Desk pobres (ou a falta de um Posto de Serviço) pode dar uma má impressão de uma outra maneira muito organização de TI eficaz! Por isso, é muito importante que o calibre correto de pessoal utilizado no Service Desk e que Gerentes de TI fazer o seu melhor para fazer a mesa de um lugar atrativo para trabalhar para melhorar a retenção de pessoal. A natureza exata, tipo, tamanho e localização de um Service Desk pode variar, dependendo do tipo de negócio, número de usuários, a geografia, a complexidade das chamadas, escopo de serviços e de muitos outros fatores. Em alinhamento com cliente e de negócios exigências, os gerentes seniores da organização de TI, deve decidir a natureza exata de seu Service Desk necessária (e se deve ser interna ou terceirizada para uma terceiro) Como parte de sua ITSM geral estratégia (Ver Estratégia de Serviço publicação) - e posterior planejamento deve ser feito para preparar e implementar o Service Desk apropriado função (Seja na implementação de uma nova função, ou, mais provavelmente nos dias de hoje ao fazer alterações necessárias para uma função existente - veja Design de Serviços e Transição de Serviço publicações). 6.2.1 Justificação e do papel do Service Desk Muito pouca justificação é necessário hoje para um Service Desk, como muitas organizações têm se convencido de que esta é de longe a melhor abordagem para lidar com questões de primeira linha de suporte de TI. Basta fazer a pergunta "Qual é a alternativa?" Para fazer um caso convincente para o conceito de Service Desk. Onde justificação adicional é necessária, os seguintes benefícios devem ser considerados: ITIL V3 - Operação de Serviço - Página: 210 de 423
    • • Melhor serviço ao cliente, percepção e satisfação • Acessibilidade aumentada através de um único ponto de contacto de comunicação e informação • Melhorqualidade e de resposta mais rápido de pedidos do cliente ou usuário • Melhor trabalho em equipe e comunicação • Maior concentração e uma abordagem pró-ativa para a prestação de serviços • Um negócio reduzida negativo impacto • Melhor infra-estrutura e de gestão controlar • Melhor utilização de Suporte de TI recursos e aumento da produtividade do pessoal de negócios • Mais significativo gestão da informação de apoio à decisão • É comum prática que o Service Desk posições fornece "nível de entrada" para o pessoal de ITSM. Trabalho sobre o Service Desk é uma 'terra' excelente para quem deseja seguir a carreira de Serviço de Gestão de. No entanto, isso também pode apresentar desafios com pessoas que não entendem do negócio ou da tecnologia. Usuáriochamando o Service Desk deve ser capaz de falar com alguém que é capaz de atender às suas necessidades, e os analistas do Service Desk não deve ser queimado em menos de um ano por causa de estresse. Cuidados devem ser tomados para selecionar adequadamente os indivíduos qualificados com um bom entendimento do negócio e fornecer treinamento adequado - redução impedindo assim em níveis de apoio, devido à falta de conhecimento na primeira linha. 6.2.2 Posto de objectivos de serviço O objetivo principal do Service Desk é restaurar normal ' serviço'Aos usuários o mais rápido possível. Neste "contextorestauração do serviço'Significa, no sentido mais amplo possível. Enquanto isto pode envolver a fixação de um técnico culpa, Pode igualmente envolver o cumprimento de uma solicitação de serviço ou respondendo a uma consulta - tudo o que é necessário para permitir que os usuários de voltar a trabalhar de forma satisfatória. Responsabilidades específicas incluirão: • Registrando todas as informações relevantes incidente/ Serviço detalhes da solicitação, a categorização alocação e códigos de priorização • Fornecer primeira linha de investigação e diagnóstico • Resolver os incidentes / requisições de serviços que eles são capazes • A escalada de incidentes / requisições de serviços que não podem ser resolvidos dentro de prazos acordados • Manter os usuários informados sobre o progresso • Fechar todos os incidentes resolvidos, pedidos e outras chamadas ITIL V3 - Operação de Serviço - Página: 211 de 423
    • • Condutor cliente/ Satisfação do usuário call-backs/surveys conforme acordado • Comunicação com os usuários - mantendo-os informados de incidente progresso, interrupções notificando-os de mudanças iminentes ou acordado, etc • Atualizando o CMS sob a direção e aprovação de Gerenciamento da Configuração se assim for acordado. Nota: essas atividades são explicados e definir em contexto com a mais completa Gerenciamento de Incidentes e Cumprimento de Requisição processo nas seções 4.2 e 4.3, respectivamente. 6.2.3 estrutura organizacional Service Desk Há muitas maneiras de estruturar Mesas de Serviço e localizá-las - ea solução correta irá variar para diferentes organizações. As principais opções são detalhadas a seguir, mas, na realidade, uma organização pode precisar implementar uma estrutura que combina um número dessas opções, a fim de atender plenamente as necessidades de negócios: 6.2.3.1 Posto de Serviço Local Este é o lugar onde uma mesa é co-localizados dentro ou fisicamente perto do usuário comunidade que serve. Essa comunicação muitas vezes ajudas e dá uma presença bem visível, o que alguns usuários gostam, mas muitas vezes pode ser ineficiente e caro recurso como pessoal são amarrados à espera de lidar com incidentes quando a taxa de volume e chegada de chamadas não pode justificar isso. Pode, no entanto, haver algumas razões válidas para a manutenção de um balcão de local, mesmo quando chamar volumes por si só não justificam. Razões podem incluir: • Língua e as diferenças culturais ou políticos • Diferentes fusos horários • Grupos especializados de usuários • A existência de serviços personalizados ou especializadas que exigem conhecimento especializado • VIP criticidade / estado de usuários. ITIL V3 - Operação de Serviço - Página: 212 de 423
    • Figura 6.2 Service Desk local 6.2.3.2 Service Desk centralizado É possível reduzir o número de Service Desks, fundindo-os em um único local (ou em um número menor de locais), chamando a equipe em uma ou mais estruturas centralizadas Posto de Serviço. Isso pode ser mais eficiente e de baixo custo, permitindo menos pessoal global para lidar com um volume maior de chamadas, e também pode levar a níveis mais altos através de familiarização grande através de ocorrência mais freqüente de eventos. Pode ainda ser necessário manter alguma forma de "presença local" para lidar com suporte físico exigências, mas esse pessoal pode ser controlada e implantado a partir do balcão central. ITIL V3 - Operação de Serviço - Página: 213 de 423
    • Figura 6.3 Service Desk centralizado 6.2.3.3 Service Desk Virtual Através da utilização de tecnologia, em particular a Internet, bem como a utilização de ferramentas de suporte corporativos, é possível dar a impressão de uma única central de serviços, centralizado, quando, de facto, o pessoal pode ser espalhada ou localizado em qualquer número ou tipo de geográfica ou locais estruturais. Isso traz a opção de 'trabalho em casa', secundário grupo de apoio, Off-shore, ou terceirização - Ou qualquer combinação necessária para atender usuário demanda. É importante notar, contudo, que as salvaguardas são necessários em todas estas circunstâncias para assegurar a consistência e uniformidade de serviço qualidade e termos culturais. ITIL V3 - Operação de Serviço - Página: 214 de 423
    • Figura 6.4 Service Desk Virtual 6.2.3.4 Siga o Sol Algumas organizações globais ou internacionais pode desejar combinar duas ou mais de sua geograficamente dispersos Service Desks para fornecer 24 horas de acompanhamento do sol serviço. Por exemplo, um Service Desk na Ásia- Pacífico pode lidar com chamadas durante seu horário de expediente normal e no final deste período, pode entregar a responsabilidade por quaisquer incidentes abertas para uma mesa de base europeia. Essa mesa vai lidar com essas chamadas, juntamente com os seus próprios incidentes durante o seu dia- padrão e, em seguida, entregar a uma secretária EUA-baseado - que, finalmente, as mãos de volta a responsabilidade para a mesa da Ásia-Pacífico para completar o ciclo. Isso pode dar cobertura de 24 horas na relativamente baixa custar, Como nenhuma mesa tem que trabalhar mais do que um único deslocar. No entanto, as mesmas garantias de processos comuns, ferramentas, banco de dados compartilhado de informações e cultura devem ser abordadas para esta abordagem para prosseguir - e bem controlados escalada e processos de transferência são necessários. ITIL V3 - Operação de Serviço - Página: 215 de 423
    • 6.2.3.5 grupos Posto de serviço especializado Para algumas organizações que poderia ser benéfico para criar "grupos de especialistas" dentro da estrutura geral de Service Desk, para que incidentes relacionados a um determinado De serviços de TI podem ser encaminhadas diretamente (normalmente através da seleção de telefonia ou de uma interface web-based) para o grupo de especialistas. Isso pode permitir que mais rapidamente resolução desses incidentes, através de uma maior familiaridade e formação especializada. A seleção será feita através de um script ao longo das linhas de 'Se o seu chamar é sobre o serviço X, por favor, pressione 1 agora, caso contrário, por favor, segure para um analista de Service Desk ". É necessário cuidado para não complicar mais a seleção, então grupos de especialistas deve ser considerada apenas para um número muito pequeno de serviços essenciais, caso existam, e onde chamam taxas sobre isso serviço justificar um grupo especializado em separado. 6.2.3.6 Ambiente O ambiente onde o Service Desk deve ser localizado deve ser cuidadosamente escolhido. Sempre que possível, as seguintes instalações devem ser fornecidos: • Um local onde toda a função pode ser posicionado com luz natural suficiente e espaço total - para permitir mesa adequada e espaço de armazenamento, e espaço para se movimentar, se necessário Anedota Uma empresa descobriu que havia um 'nós e eles' cultura existente entre o Service Desk e as equipes de apoio. As equipes de terceira linha muitas vezes acredita-se ser melhor do que o Service Desk. Escondendo o Service Desk de distância em uma sala isolada ajudou a reforçar essa cultura. A empresa constatou que a criação de um escritório de plano aberto com o Service Desk no meio de trabalho mais próxima incentivou e ajudou a quebrar essas barreiras • Um ambiente tranquilo, com acústica adequada controlar de modo que uma conversação telefónica não é perturbada por uma outra • Ambiente agradável e mobiliário confortável, de modo a aliviar o clima (o Service Desk pode ser um lugar muito estressante para trabalhar, então cada pequena ajuda!) • Uma área de sala de descanso e refresco separado nas proximidades, para que a equipe possa fazer pausas curtas como apropriado, quando necessário, sem estar longe por muito tempo. ITIL V3 - Operação de Serviço - Página: 216 de 423
    • 6.2.3.7 Nota sobre a construção de um único ponto de contato Independentemente de a combinação das opções escolhido para cumprir uma organizaçãoEstrutura do Posto de Serviço geral individual, usuários deve estar em dúvida sobre quem contactar se eles precisam de ajuda. Um único número de telefone (ou um número único para cada grupo se mesas separadas são escolhidas) devem ser fornecidos e bem divulgado -, bem como um endereço de e-mail único e uma página de contato Internet Service Desk. Idéias que podem ser usadas com sucesso para ajudar a divulgar o número de telefone de Serviço de Recepção e e-mail, e disponibilizá-lo à mão quando os usuários estão propensos a precisar deles, são: • Incluindo o número de telefone de Service Desk em rótulos de hardware IC, anexa ao componentes o usuário é susceptível de ser chamadas sobre • Impressão de Service Desk detalhes de contato nos telefones • Para PCs e laptops, usando um fundo personalizado ou área de trabalho com o Serviço detalhes de contato Posto, juntamente com informações ler a partir do sistema que será necessário ao chamar (como endereço IP, sistema operacional construir número, etc), num canto • Imprimir o número de Service Desk em 'brindes' (canetas, lápis, canecas, mouse-esteiras, etc) • Proeminente colocar esses detalhes em Service Desk Internet / intranet locais • Incluí-los em quaisquer cartões telefônicos ou cartões de pesquisa de satisfação com os usuários deixados quando uma visita mesa foi necessário • Repetindo os detalhes sobre toda a correspondência enviada aos usuários (juntamente com chamar números de referência) • Colocar os detalhes sobre a afixação ou locais físicos que os usuários tendem a visitar regularmente (entradas, refeitórios, áreas de arrefecimento, etc.) 6.2.4 pessoal Service Desk As questões envolvidas na, e os critérios para estabelecer, o pessoal adequado modelo e os níveis são discutidos nesta seção. Detalhes sobre Service Desk típico papels e responsabilidades podem ser encontradas no parágrafo 6.6.1 abaixo. Eles incluem o Service Desk Manager, Supervisor, analistas e, em algumas organizações, esses papéis são complementados por usuários de negócios ('Super Users '), que fornecem suporte de primeira linha. 6.2.4.1 Os níveis de pessoal ITIL V3 - Operação de Serviço - Página: 217 de 423
    • Uma organização deve assegurar que o número correto de funcionários estão disponíveis a qualquer momento para atender a demanda que está sendo colocado sobre a mesa pela empresa. Taxas de chamadas podem ser muito voláteis e muitas vezes no mesmo dia, a taxa de chegada pode ir de muito alta a muito baixa e de volta. Uma organização planejamento uma nova mesa deve tentar prever a taxa de chegada de chamadas e perfil - e ao pessoal em conformidade. A análise estatística dos chamar taxas de chegada em regime de suporte atuais devem ser realizados e, em seguida, acompanhado de perto e ajustada, se necessário. Muitas organizações vai descobrir que as taxas de chamadas de pico durante o início do dia escritório e depois cair rapidamente, talvez com outra explosão no início da tarde - isso, obviamente, varia de acordo com o organizaçãoNegócio 's, mas é um padrão, muitas vezes ocorrendo para muitas organizações. Em tais circunstâncias, pode ser possível utilizar parte-time, home-trabalhadores, segunda linha de apoio pessoal ou de terceiros para cobrir os picos. Os seguintes fatores devem ser considerados ao decidir os níveis de pessoal: • Cliente expectativas de serviço • Negócio exigências, tais como orçamento, Chamada tempo de respostas, etc • Tamanho, idade relativa projeto e complexidade do Infraestrutura de TI e Catálogo de Serviços - por exemplo, o número eo tipo de incidentes, a extensão do padrão personalizado contra software off-the-shelf implantado, etc • O número de clientes e usuários para apoiar, e fatores associados, tais como: • Número de clientes e usuários falando uma língua diferente • Nível de habilidade • Incidente e Solicitação de Serviço tipos (e tipos de RFC, se for o caso): • Duração do tempo requerido para tipo de chamadas (por exemplo, consultas simples, especialista aplicação consultas, hardware, etc) • Experiência local ou externo necessário • O volume e os tipos de incidentes e solicitações de serviço • O período de cobertura apoio necessário, com base em: • Horas coberta • Fora-de-horas de apoio exigências • Fusos horários a serem cobertas • Locais a serem suportados (especialmente se Service Desk funcionários também realizam mesa do lado de suporte) • O tempo de viagem entre os locais • Workload padrão de pedidos (por exemplo, diariamente, fim de mês, etc) • O meta de nível de serviços em vigor (níveis de resposta, etc) • O tipo de resposta exigida: ITIL V3 - Operação de Serviço - Página: 218 de 423
    • • Telefone • E-mail/fax/voice mail / vídeo • Presença física • Acesso on-line /controlar • O nível de formação exigido • As tecnologias de apoio disponíveis (por exemplo, telefone sistemas, ferramentas de suporte remoto, etc) • Os actuais níveis de competência do pessoal • Os processos e procedimentos em uso. Todos esses itens devem ser cuidadosamente considerados antes de tomar qualquer decisão sobre os níveis de pessoal. Isso também deve ser refletido nos níveis de documentação necessária. Lembre-se que o melhor a serviço, Mais o negócio vai usá-lo. Uma série de ferramentas estão disponíveis para ajudar a determinar o número adequado de funcionários para o Service Desk. Estes carga de trabalho modelagem ferramentas são dependentes de "conhecimento local" detalhada do organização tal como chamar volumes e padrões, serviços e perfil do usuários, etc 6.2.4.2 Os níveis de especialização Uma organização deve decidir sobre o nível e variedade de habilidades que exige de sua equipe de Service Desk - e, em seguida, garantir que essas habilidades estão disponíveis nos momentos apropriados. Uma gama de opções de habilidade é possível, a partir de um 'call-logging " serviço apenas - onde a equipe só precisa de muito conhecimentos técnicos básicos - direito até a um "técnico" Service Desk onde a equipe tecnicamente mais qualificada da organização são usados. No caso do primeiro, não haverá um manuseamento elevada, mas baixa resolução taxa, enquanto no último caso, esta será invertida. A decisão sobre o nível de competências necessárias, muitas vezes, ser conduzido por vezes alvo de resolução (concordou com o negócio e capturado em meta de nível de serviços), a complexidade dos sistemas de apoio e 'o que a empresa está disposta a pagar ". Há uma forte correlação entre a resposta e as metas de resolução e custars - de um modo geral, o menor dos tempos alvo, maior o custo, porque mais recursos são necessárias. Embora possa haver casos em negócios dependência criticidade ou fazer uma mesa altamente qualificados tecnicamente um imperativo, a abordagem ideal e melhor custo-benefício é geralmente a primeira linha tem uma "chamada- ITIL V3 - Operação de Serviço - Página: 219 de 423
    • logging" de apoio através do Service Desk, com rápido e eficaz escaladas para mais qualificados grupos de resolução de segunda linha e terceira linha, onde pessoal qualificado pode ser concentrada e mais eficazmente utilizados (ver Gerenciamento de Incidentes, Secção 4.2, para mais informações e orientações sobre estruturas de ponta a ponta-de apoio). No entanto, este ponto de partida básico pode ser melhorada ao longo do tempo, proporcionando ao pessoal de primeira linha com um eficaz da base de conhecimento, script de diagnósticos e ferramentas de apoio integrados (incluindo um CMS), bem como a formação contínua ea consciência, de modo que as taxas de resolução de primeira linha pode ser gradualmente aumentada. Isso também pode ser alcançado através da localização de segundo nível pessoal no Service Desk, efetivamente criando uma estrutura de dois níveis. Isto tem vantagens de fazer segundo nível pessoal disponível para ajudar a lidar com períodos de pico de chamadas e para treinar o pessoal mais júnior, e, muitas vezes, aumentar a taxa de resolução na primeira chamada. No entanto, segundo pessoal da linha, muitas vezes têm deveres fora do Service Desk - resultando em listas que têm de ser geridos ou posições de segunda linha pessoal que está sendo duplicado. Além disso, ter que lidar com chamadas de rotina pode ser desmotivador para o pessoal mais experiente. Uma outra desvantagem potencial é que o Service Desk torna-se muito bom em resolver as chamadas, enquanto a segunda linha pessoal deve ser focada na remoção do causa raiz em vez disso. Outro fator a considerar quando se decidir sobre as habilidades exigências para o Serviço de Pessoal da recepção é o nível de personalização e especialização dos serviços suportados. Serviços padronizados requerem menos conhecimento específico para fornecer qualidade cliente apoiar. Quanto mais especializado o serviço, o conhecimento especializado mais provável será exigida na primeira chamada. Note-se que em primeira linha resolução as taxas podem ser reduzidos por eficácia Gerenciamento de Problemas, O que vai reduzir a quantidade dos mais simples, incidentes repetitivos. Em tais casos, embora os índices de resolução parecem estar a correr para baixo, o conjunto serviço qualidade terá melhorado através da remoção completa dos muitos incidentes. Enquanto isso é bom, se a equipe de Service Desk são pagos incentivos ou bônus de resolução na primeira chamada, pode ser desastrosa para a moral e processo eficácia, A menos que o bônus limiar é revered. Melhorias no tempo de resolução / taxas não deve ser deixado ao acaso, mas deverão ser parte de uma Melhoria de Serviço em curso Programa (Veja a Melhoria de Serviço Continuada publicação para maiores detalhes). Uma vez que o nível de conhecimentos necessários foram identificados, existe uma tarefa permanente de garantir que o Service Desk é operado de tal forma que o pessoal necessário obter e manter as habilidades necessárias - e que o ITIL V3 - Operação de Serviço - Página: 220 de 423
    • pessoal com o equilíbrio correto de habilidades estão de plantão em momentos apropriados para que a consistência é mantida. Isso envolverá uma formação contínua e programa de conscientização que deve abranger: • Habilidades interpessoais, tais como habilidades de telefonia, habilidades de comunicação, escuta ativa e clienteDe cuidados de treinamento. • Consciência negócio: conhecimento específico do organização'S áreas de negócio, motoristaA estrutura, prioridades, etc • A consciência de serviço de toda a chave da organização De serviços de TIs para a qual o suporte está a ser fornecido • Consciência técnica (e mais profunda formação técnica para o nível adequado, dependendo da taxa de resolução procurado) • Dependendo do nível de suporte fornecido, alguns diagnóstico habilidades (por exemplo, Kepner e Tregoe) • Ferramentas de apoio e técnicas • Treinamento de conscientização e tutoriais em novo sistemas e tecnologias, antes da sua introdução • Processos e procedimentos (mais incidente particularmente Alterar e Gerenciamento da Configuração - Mas uma visão geral de todos os processos de ITSM e procedimentos) • Digitando habilidades para garantir a entrada rápida e precisa de incidente ou solicite mais detalhes do serviço. Para tal programa seja eficaz habilidade, exigências e os níveis devem ser avaliados periodicamente e treinamento registros mantidas. Formulação cuidadosa de rotações de pessoal ou horários deve ser mantido para que um equilíbrio consistente de experiência pessoal e os níveis de habilidade apropriadas estão presentes durante toda a crítica operacional períodos. Não é suficiente ter apenas o número certo de funcionários de plantão - a mistura correta de habilidades também deve estar disponível. 6.2.4.3 Formação É fundamental que toda a equipe de Service Desk são adequadamente treinados antes de serem chamados para o pessoal do Service Desk. Um programa de indução formal deve ser realizada por todos os novos funcionários, o conteúdo exato do que irá variar de acordo com os níveis de habilidade e experiência existentes do novo recruta, mas é provável que incluem muitas das habilidades necessárias, como descrito acima. Sempre que possível, a consciência de um negócio programa, Incluindo curtos períodos de destacamento em áreas chave do negócio, deve ser fornecida para o pessoal novo que ainda não tem este nível de consciência negócio. ITIL V3 - Operação de Serviço - Página: 221 de 423
    • Ao iniciar no Service Desk, Nova equipe deverá inicialmente equipe experiente 'sombra' - sentar com eles e ouvir em chamadas - antes de começar a tomar chama-se com um mentor ouvindo e capaz de intervir e fornecer suporte quando necessário. O mentor deverá inicialmente rever cada chamar com o estagiário, após concluir a aprender quaisquer lições. A frequência dessas análises deverá ser gradualmente reduzida, experiência e confiança cresce, mas o mentor ainda deve estar disponível para fornecer suporte contínuo, mesmo quando o candidato tenha alcançado o estágio de carreira solo. Mentores podem precisar de ser treinados sobre como mentor. Experiência Service Desk e habilidades técnicas não são o único exigências para orientação. Eficazes de transferência de conhecimentos e habilidades a capacidade de ensinar sem ser condescendente ou ameaçando são igualmente importantes. Aprograma será necessário para manter o conhecimento pessoal do Serviço de Recepção de até à data - e torná-los conscientes de novo desenvolvimentos, serviços e tecnologias. O momento de tal eventos é crítica de forma a não impacto sobre as funções normais. Mesas Serviço Muitos acham que é melhor para organizar curta "tutoriais" durante períodos tranquilos quando os funcionários têm menos probabilidade de ser necessário para atendimento de chamadas. Nota: Investimento também deve ser feito no desenvolvimento profissional do pessoal de Service Desk. Interno de orientação e de sombreamento pessoal de apoio de segundo e terceiro nível é um bom começo, mas Mesas best-of-breed Serviço beneficiar de um programa formal de desenvolvimento de pessoal. Comprometimento organizacional para o desenvolvimento profissional ajuda a incutir um senso de realização e oportunidade para o pessoal. Isso muitas vezes leva à inovação em Service Desk operação (Tais como serviços especializados), que por sua vez, na unidade operacional eficiências em todos os níveis da camada de apoio. Ela ajuda a construir habilidades que podem ser utilizados na sua actual papel assim como ele saltar inicia o treinamento para um novo papel. Embora seja importante para desenvolver suas competências essenciais em sua função atual, ter um plano de carreira claro e reconhecendo exigência futuro e as necessidades de desenvolvimento também é importante. 6.2.4.4 retenção de pessoal É muito importante que todos os gestores de TI reconhecem a importância do Service Desk e do pessoal que trabalha nele, e dar essa atenção especial. Qualquer perda significativa de pessoal pode ser perturbador e levar a inconsistência de serviço - Por isso os esforços devem ser feitos para que o Service Desk um lugar atraente para o trabalho. Maneiras em que isto pode ser feito incluem o reconhecimento apropriado do papel com pacotes de recompensa Reconhecendo isso, equipe de construção ITIL V3 - Operação de Serviço - Página: 222 de 423
    • de exercícios, rotação de pessoal para outras atividades (projetos, o suporte de segunda linha, etc.) O Service Desk muitas vezes pode ser usado como um trampolim para outras funções mais técnicas ou de supervisão / gerencial. Se isso for feito, o cuidado é necessário para garantir que a sucessão adequada planejamento ocorre para que a mesa não perder todo o seu conhecimento fundamental em qualquer área de uma vez. Além disso, boa documentação e cross-training pode reduzir esse risco. 6.2.4.5 Superusuários Muitas organizações achar que é útil para nomear ou designar um número de 'Super Users "ao longo da usuário comunidade, para atuar como pontos de ligação com TI em geral e do Service Desk, em particular. Superusuários pode ser dada alguma formação adicional e de sensibilização e usado como um canal de comunicações de fluxo em ambas as direcções. Elas podem ser feitas para filtrar os pedidos e as questões levantadas pela comunidade de usuários (em alguns casos, até mesmo indo tão longe a ponto de ter incidentes ou solicitações levantadas pelo Super Usuário) - pode ajudar a prevenir 'incidente tempestades "quando um serviço chave ou componente falha, que afeta muitos usuários. Eles também podem ser utilizados para informação de cascata para o exterior ao longo do seu Service Desk comunidade local de utilizadores, que podem ser muito úteis na divulgação detalhes do serviço para todos os utilizadores muito rapidamente. É importante notar que, Super Users deve registrar todas as chamadas que lidam com, e não apenas aqueles que eles passam para TI. Isto significa acesso e treinamento sobre como usar as ferramentas, registrando incidentes. Isso vai ajudar a medir a atividade do Super Usuário e também para assegurar que a sua posição não é abusado. Além disso, ele vai garantir que a história valiosas sobre incidentes e serviços qualidade não são perdidos. Também pode ser possível para Superusuários a ser envolvida em: • Formação de pessoal para usuários na sua área • Fornecendo suporte para incidentes menores ou simples pedido cumprimento • Envolvimento com o novo liberars e lançamentos. Superusuários não necessariamente fornecer suporte para toda a TI. Em muitos casos, um Super Usuário só irá fornecer suporte para uma específica aplicaçãoOu módulo unidade de negócios área. Como um usuário de negócios ITIL V3 - Operação de Serviço - Página: 223 de 423
    • do Usuário Super muitas vezes tem um conhecimento profundo de como chave processo de negócioes executar e como trabalhar em serviços prática. Este é um conhecimento muito útil para compartilhar com o Service Desk, De modo que possa proporcionar maior qualidade de serviços no futuro. Note-se que um compromisso firme é necessário que potenciais usuários Super e, especificamente, a sua gestão, que terá o tempo e interesse para realizar esse papel antes da seleção e treinamento começa. A Super User, enquanto uma interface valiosa para o negócio e Service Desk, deve ser dada formação adequada, responsabilidade e expectativa. Superusuários podem ser vulneráveis ao mau uso, se o seu papel, as responsabilidades e os processo regem estes não são claramente comunicada aos usuários. É imperativo que um Super Usuário não é visto como um substituto, ou um meio de contornar, o Service Desk. 6.2.5 Posto de métricas de serviço Métricos deve ser estabelecida de modo que atuação do Service Desk pode ser avaliada em intervalos regulares. Isto é importante para avaliar a saúde, maturidade,eficiência,eficácia e todas as oportunidades para melhorar as operações do Service Desk. Métricas de desempenho Service Desk devem ser realistas e cuidadosamente escolhido. É comum para selecionar essas métricas que são facilmente disponíveis e que pode parecer ser uma possível indicação de desempenho, no entanto, isso pode ser enganador. Por exemplo, o número total de chamadas recebidas pela Central de Serviços não é em si uma indicação de qualquer bom ou mau desempenho e pode de fato ser causada por eventos completamente fora do controlar do Service Desk - por exemplo, um período particularmente movimentado para o organização, Ou o liberar de um novo versão de uma das grandes empresas sistema. Um aumento no número de chamadas para a Central de Serviço pode indicar serviços menos confiáveis durante esse período de tempo - mas também pode indicar a confiança do usuário em um aumento de Service Desk que está amadurecendo, resultando em uma maior probabilidade de que os usuários vão procurar assistência em vez de tentar para lidar sozinho. Para este tipo de métrica para ser confiável para alcançar ou conclusão de comparação, ainda mais em períodos anteriores por quaisquer melhorias Service Desk implementadas desde a última medição linha de baseOu serviço confiança alterações, problemas, etc, para isolar a verdadeira causa para o aumento é necessário. Uma análise adicional e mais métricas detalhadas são, portanto, necessário, e deve ser examinada durante um período de tempo. Estas incluem as estatísticas ITIL V3 - Operação de Serviço - Página: 224 de 423
    • de processamento de chamadas anteriormente mencionados em telefonia, e, adicionalmente: • A primeira linha resolução taxa de: a percentagem de chamadas resolvidas em primeira linha, sem a necessidade de escalada a outra grupo de apoios. Esta é a figura freqüentemente citado por organizações como a principal medida do desempenho Mesas serviço - e utilizado para fins de comparação com o desempenho de outras mesas - mas é preciso cuidado ao fazer qualquer comparação. Para maior precisão e mais comparações válidas isto pode ser subdivididos como segue: • A percentagem de chamadas resolvidas no primeiro contato com o Service Desk, Isto é, enquanto o usuário ainda está no telefone para informar o chamar • A percentagem de chamadas resolvido pela equipe de Service Desk-se sem ter que procurar mais profundo apoio de outros grupos. Nota: algumas mesas vai escolher para co-localizar ou incorporar mais tecnicamente capacitada equipe de segunda linha com o Service Desk (ver Gerenciamento de Incidentes para mais detalhes). Em tais casos, é importante ao fazer comparações com a também separar (i) A percentagem resolvido pela equipe de Service Desk sozinho, e (ii) A percentagem resolvido pela equipe de primeira linha Posto de Serviço e segunda linha de apoio equipe combinados. • O tempo médio para resolver uma incidente (Quando resolvidas em primeira linha) • O tempo médio para escalar um incidente (onde de primeira linha resolução não é possível) • Service Desk média custar de lidar com um incidente. Dois métricos devem ser considerados aqui: • O custo total do Service Desk dividido pelo número de chamadas. Isto irá proporcionar um valor médio que é útil como um índice e para planejamento propósitos, mas não representar com precisão os custos relativos dos diferentes tipos de chamadas • Ao calcular a percentagem de tempo de duração da chamada na mesa geral e elaborar um custo por minuto (custos totais para o período, dividido pelo total de minutos de duração de chamada ") isto pode ser usado para calcular o custo das chamadas individuais e dar um valor mais exacto . Ao avaliar os tipos de incidentes com duração de chamada, uma imagem mais refinada de custo por chamada por tipos surge e dá indicação de quais tipos de incidentes tendem a custar mais para resolver e possíveis alvos para melhorias. • Percentual de cliente ou actualizações do utilizador conduzido dentro de tempos-alvo, como definido na SLA alvos ITIL V3 - Operação de Serviço - Página: 225 de 423
    • • Tempo médio para rever e fechar uma chamada resolvido • O número de chamadas discriminadas por hora do dia e dia da semana, combinada com a média de tempo de chamada métrica, é fundamental para determinar o número de pessoal necessário. Outros detalhes gerais sobre métricas e como eles devem ser usados para impulsionar serviço qualidade está incluído no Melhoria de Serviço Continuada publicação. 6.2.5.1 cliente / usuário pesquisas de satisfação Bem como acompanhamento das medidas "duras" do Service Desk da atuação (Através dos indicadores descritos acima), também é importante avaliar 'soft' medidas - tais como o quão bem os clientes e usuários sentem que suas chamadas foram atendidas, se eles se sentem o operador Service Desk foi cortês e profissional, se reforçou a confiança no utilizador. Este tipo de medida é o melhor obtido a partir dos próprios usuários. Isso pode ser feito como parte de um amplo cliente/usuário pesquisa de satisfação que cobre tudo ou pode ser especificamente orientadas para as questões Service Desk sozinho. Uma maneira eficaz de alcançar o último é através de um inquérito telefónico de call-back, onde uma organização independente Service Desk Operador ou Supervisor anéis de volta uma pequena porcentagem de usuários logo após seu incidente foi resolvido, para fazer as perguntas específicas necessárias. Cuidados devem ser tomados para manter o número de perguntas a um mínimo (5-6 no máximo) para que os usuários terão tempo para cooperar. Também perguntas da pesquisa deve ser projetado de forma que o usuário ou o cliente sabe o que perguntas de área ou tema são cerca e que incidente ou serviço eles estão se referindo. O Service Desk deve atuar em baixos níveis de satisfação e qualquer feedback recebido. Para permitir comparações adequadas, o mesmo percentual de chamadas devem ser selecionados em cada período e devem ser rigorosamente realizadas apesar das pressões do tempo outros. As pesquisas são uma área complexa e especializada, exigindo um bom entendimento de estatísticas e técnicas de pesquisa. Esta publicação não pode ITIL V3 - Operação de Serviço - Página: 226 de 423
    • tentar fornecer uma visão geral de todas elas, mas um resumo de algumas das técnicas mais amplamente utilizadas e ferramentas está listada na Tabela 6.1. Técnica / Ferramenta Vantagens Desvantagens Depois de call-pesquisa Chamadores são convidados a permanecer no telefone após a chamar e então solicitados a classificar o serviço foram fornecidos • Alta taxa de resposta desde o chamador é já no telefone • Chamador seja examinado imediatamente após a chamada assim que sua experiência é recente • As pessoas podem se sentir pressionados a tomar a pesquisa, resultando em uma experiência de serviço negativa • O inspector é visto como parte do Service Desk em estudo, o que pode desencorajar respostas abertas Pesquisa telefônica de saída Os clientes e usuários que já usaram o Service Desk são contactados algum tempo após a sua experiência com o Service Desk • Maior taxa de resposta desde o chamador é entrevistado diretamente • Categorias específicas de usuário ou cliente pode ser alvo de feedback (por exemplo, pessoas que solicitaram um serviço específico, ou pessoas experimentou uma quebra para um serviço particular) • Este método poderia ser visto como intrusivo, se interrompe a chamada do utilizador ou cliente do seu trabalho • A pesquisa é realizada algum tempo depois que o usuário ou cliente usou o Service Desk, pelo que a sua percepção pode ter mudado Entrevistas pessoais Os clientes e usuários são entrevistados pessoalmente pela pessoa que faz a pesquisa. Isto é especialmente eficaz para clientes ou usuários que usam o Service Desk extensivamente ou que tiveram uma experiência muito negativa • O entrevistador é capaz de observar sinais não- verbais, bem como ouvir o que o usuário ou o cliente está dizendo • Usuários e clientes sentem um maior grau de atenção pessoal e uma sensação de que suas respostas estão sendo levados a sério · • Entrevistas são demorados, tanto para o entrevistador eo entrevistado • Usuários e clientes pode transformar as entrevistas em sessões de reclamações · Entrevistas de grupo Os clientes e usuários são entrevistados em pequenos • Um número maior de usuários e clientes podem ser entrevistado • As perguntas são mais • As pessoas não podem se expressar livremente na frente de seus colegas ou ITIL V3 - Operação de Serviço - Página: 227 de 423
    • grupos. Isto é bom para a recolha de impressões gerais e para determinar se existe uma necessidade de alterar certos aspectos da Service Desk, E.g. horas de serviço ou localização genéricos e, portanto, mais consistente entre entrevistas · gerentes • As opiniões das pessoas pode ser facilmente alterado por outros membros do grupo durante a entrevista · Postais / e-mail pesquisas Questionários são enviados para um conjunto alvo de clientes e usuários. Eles são convidados a retornar suas respostas por e / mail • Clientes específicos ou todos ou os usuários podem ser orientados • Pesquisas postais podem ser anônimas, permitindo que as pessoas se expressem mais livremente • E-mail pesquisas não são anônimas, mas podem ser criados usando formulários automatizados que tornam conveniente e fácil para o usuário a responder e aumentar a probabilidade de que será completada · • Pesquisas postais são intensivos de trabalho para processo • O percentual de pessoas que responderam a inquéritos postais tende a ser pequeno • Má interpretação de uma pergunta poderia afetar o resultado · Pesquisas on-line Os questionários são postados em um site e usuários e clientes incentivada através de e- mail ou links de um site popular para participar da pesquisa • O público potencial dessas pesquisas é bastante grande • Os entrevistados podem preencher o questionário em seu próprio tempo • Os links em sites populares são lembranças boas, sem ser intrusivo A percentagem de inquiridos não pode ser prevista Tabela 6.1 técnicas e ferramentas de pesquisa 6.2.6 A terceirização do Service Desk A decisão de terceirizar é uma estratégico emitir para gerentes seniores - e é abordado em detalhes na Estratégia de Serviço e Design de Serviços publicações. Muitos dos diretrizs nesta seção não são exclusivos do Service Desk e pode ser aplicado a qualquer função, A área de suporte ou serviço sendo terceirizado (ou fora-tarefa). Independentemente das razões, ou a extensão de, a terceirização contrato, É vital que o organização mantém a responsabilidade para as atividades e ITIL V3 - Operação de Serviço - Página: 228 de 423
    • serviços prestados pelo Service Desk. A organização é responsável pela resultados da decisão e, portanto, deve determinar que tipo de serviço o contratante fornece, e não o contrário. Se a rota é escolhida de terceirização, há algumas salvaguardas que são necessárias para assegurar que o Service Desk terceirizado funciona de forma eficaz e eficiente, com a organização de TI outras equipes e departamentos e esse fim-de-final Serviço de Gestão de controlar é mantida (isto é particularmente importante para as organizações que procuram ISO / IEC 20000 certificado como controle de gestão global tem de ser demonstrada). Algumas dessas garantias são definidas a seguir. 6.2.6.1 As ferramentas comuns e processos O Service Desk não tem a responsabilidade de todos os processos e procedimentos que inicia. Por exemplo, um Solicitação de Serviço é recebido pelo Service Desk, mas a solicitação é atendida pelo interno de TI Operacional equipe. Se o Service Desk é terceirizado, os cuidados devem ser tomados para que as ferramentas são consistentes com aqueles que ainda estão sendo usados na organização do cliente. Terceirização é muitas vezes visto como uma oportunidade para substituir os instrumentos desatualizados ou inadequada, apenas para descobrir que há integração grave problemas entre a nova ferramenta e as ferramentas herdadas e processos. Por esta razão, é importante para assegurar que estas questões são devidamente estudadas e do cliente exigências são devidamente delimitado e especificado antes do contrato de terceirização. Ferramentas de Service Desk deve não só apoiar a Central de serviços terceirizados, mas devem apoiar os processos da organização do cliente e requisitos de negócio também. Idealmente, a secretária terceirizada deve usar as mesmas ferramentas e processos (ou, no mínimo, as ferramentas de interface e processos) para permitir suave processo fluxo entre o Service Desk e de segunda e terceira linha grupo de apoios. Além disso, o Service Desk terceirizado deve ter acesso a: • Todos registro de incidentes e informações • Grave problemas e informações • Erro Conhecido Dados • Alterar agendamento • Fontes de conhecimento interno (especialmente técnico ou aplicação especialistas) • SKMS ITIL V3 - Operação de Serviço - Página: 229 de 423
    • • CMS • Alertars a partir de monitoramento ferramentas. Muitas vezes, é um desafio processos integradores e ferramentas em um menos maduro organização com os de uma organização mais madura. Uma suposição comum, mas incorreta é que o maturidade de uma organização, de alguma forma como consequência uma maior maturidade na outra. O envolvimento ativo para garantir o alinhamento de processos e ferramentas é essencial para uma transição suave e gerenciamento contínuo de serviços entre organizações internas e externas. Na verdade, se este não está directamente dirigida, isso pode resultar na falha do contrato. É também muitas vezes erradamente do princípio de que a prova de Serviço de Gestão de qualidade e vencimento em um parceiro terceirizar externo pode ser garantido por afirmar exigências, na aquisição processo para 'ITIL conformidade 'e / ou'ISO / IEC 20000 certificado'. Estas declarações podem indicar que um potencial fornecedor usa o modelo ITIL em sua entrega de serviços aos clientes, ou que eles têm alcançado padrãos certificação para sua interna práticas, mas é igualmente importante ter a tecnologia que permite no lugar e sendo utilizado um que demonstra provedor de serviços'S capacidade para gerenciar serviços e interface com as práticas internas harmoniosamente. Não existe um padrão de observância que garante esforços de aquisição deste e por isso deve incluir consultas específicas para satisfazer esta exigência. Mais informações sobre o fornecedor terceirizar aquisição pode ser encontrada na Design de Serviços publicação. 6.2.6.2 SLA alvos As metas de SLA para geral incidente manipulação e resolução vezes precisam ser acordado com o clientes, e entre todas as equipes e departamentos - e OLA / UC metas precisam ser coordenadas e concordou com o indivíduo grupo de apoios para que apoiar e apoiar o SLA alvos. Exemplos destes podem ser vistos na secção métricos acima (ver secção 6.2.5). 6.2.6.3 A boa comunicação As linhas de comunicação entre a Central de Serviço terceirizado e os outros grupos de apoio precisam trabalhar de forma muito eficaz. Isto pode ser ajudado por alguns ou todos os seguintes passos: • Feche a partilha física • Ligação regular /rever reuniões • Cross-training tutoriais entre as equipes e departamentos • 'Parceria"Arranjos quando o pessoal de ambas as organizações são usados em conjunto com o pessoal da mesa ITIL V3 - Operação de Serviço - Página: 230 de 423
    • • Planos de comunicação e atuação alvos são documentados de forma consistente em Olas e UCs. Nos casos em que o Service Desk está localizado off-shore, Nem todas essas medidas será possível. No entanto, a necessidade de formação e comunicação da equipe de Service Desk ainda é crítica, ainda mais em casos em que existam diferenças linguísticas e culturais. Isso será abordado mais detalhadamente em publicações ITIL complementares, mas, como regra, as empresas de outsourcing que oferecem soluções off-shore de Service Desk deve levar em conta o seguinte: • Treinamento programas focada na compreensão cultural do cliente mercado • Habilidades de linguagem - especialmente a compreensão da utilização idiomática da língua no mercado do cliente. Isto não é assim que o serviço de som A equipe como os nativos do país do cliente (que tipo de insinceridade é rapidamente detectado por clientes), mas para facilitar a compreensão do cliente e para melhor apreciar as suas prioridades • Visitas regulares de representantes do cliente organização para fornecer treinamento e feedback apropriado diretamente para a gestão de Service Desk e pessoal • Treinamento no uso de organizações dos clientes ferramentas e métodos de trabalho. Isto é especialmente eficaz se os materiais de formação semelhantes são apresentados pelos instrutores idênticos aos utilizados pela organização do cliente. 6.2.6.4 Propriedade dos dados Domínio claro dos dados coletados pelo Service Desk terceirizado deve ser estabelecida. Posse de todos os dados relativos aos usuários, clientes, CIS afetada, serviços, incidentes Solicitação de Serviços, mudanças, etc devem permanecer com a organização que é terceirização o atividade -, Mas ambas as organizações precisam de acesso a ele. Dados que estão relacionados especificamente para atuação de funcionários da empresa de terceirização continuará a ser propriedade daquela empresa, que muitas vezes é legalmente impedido de compartilhar os dados com a organização do cliente. Isso também pode ser verdade para outros dados que são utilizados exclusivamente para a gestão interna do Service Desk, como contagem de cabeça, otimização de atividades, Service Desk custar informações, etc Todos os relatórios exigências e as questões em torno da propriedade dos dados deve ser especificado no subjacente contrato com a empresa que presta o serviço de outsourcing. ITIL V3 - Operação de Serviço - Página: 231 de 423
    • 6.3 Gestão Técnica Gestão Técnica refere-se aos grupos, departamentos ou equipes que fornecem conhecimento técnico e de gestão global da Infraestrutura de TI. 6.3.1 papel de Gestão Técnica Gestão Técnica desempenha um duplo papel: • Ele é o guardião do conhecimento técnico e experiência relacionada à gestão da infra-estrutura de TI. Neste papel, Gestão Técnica garante que o conhecimento necessário para projeto,teste, Gerir e melhorar De serviços de TIs é identificado, desenvolvido e aperfeiçoado. • Ele oferece a real recursos para suportar o ITSM Ciclo de Vida. Neste papel de Gestão Técnica garante que os recursos sejam efetivamente treinados e distribuídos para projeto,construir, Transição, operar e melhorar a tecnologia necessária para dar suporte De serviços de TIs. Ao realizar estes dois papels, Gestão Técnica é capaz de assegurar que o organização tem acesso ao tipo certo nível e de humano recursos para administrar de tecnologia e, portanto, para satisfazer negócios objetivos. Definindo o exigências para estes papéis começa na Estratégia de Serviço e é expandido em Design de Serviços, Validado em Transição de Serviço e refinado em Melhoria de Serviço Continuada (Ver outro ITIL publicações nesta série). Parte deste papel é também para assegurar um equilíbrio entre o nível de habilidade de utilização, e a custar desses recursos. Por exemplo, a contratação de um recurso de nível superior no ponto mais alto da escala salarial e só então usar essa habilidade para 10% do tempo não é eficaz. A melhor de Gestão Técnica estratégia seria identificar os momentos em que a habilidade é necessário e, em seguida, contratar um empreiteiro para apenas as tarefas. Outra estratégia em organizações maiores é a equipe de alavancagem especialista de "central" de grupos para que especialistas possam ser bem utilizados e proporcionar uma economia de escala para a organização e minimizar a necessidade de contratar em empreiteiros. Habilidades especializadas devem ser identificados entre os recursos na organização de TI, então aproveitados para necessidades específicas que possam surgir, análogas a uma unidade especial tático, cujos membros também desempenhar funções regulares, mas que são designados para tarefas que necessitam de suas habilidades especiais. Este tipo de utilização de recursos é particularmente útil tanto para projeto equipes e problema resolução. Um papel adicional, mas muito importante desempenhado pela Gestão Técnica é fornecer orientações para Operações de TI sobre a melhor forma de levar a cabo o curso operacional gerenciamento da tecnologia. Este papel é ITIL V3 - Operação de Serviço - Página: 232 de 423
    • parcialmente realizado durante o Design de Serviços processo, Mas é também uma parte da comunicação diária com TI Gestão de Operações , que procuram alcançar a estabilidade e ótima atuação. Os objetivos, atividades e estruturas que permitem Gestão Técnica para executar essas funções de forma eficaz são discutidas abaixo. 6.3.2 Técnicas objectivos de gestão Os objetivos da Gestão Técnica são para ajudar a planejar, implementar e manter uma infra-estrutura estável técnica para apoiar a organização do processo de negócioes por meio de: • Bem desenhado e altamente resistente, topologia de custo-benefício técnico • O uso de habilidades técnicas adequadas para manter a infra-estrutura técnica em óptimo estado • Swift uso de habilidades técnicas para diagnosticar e resolver rapidamente qualquer técnica falhas que ocorrem. 6.3.3 genéricos técnicos actividades de gestão Gestão Técnica está envolvido em dois tipos de atividade: • Atividades que são genéricas para a Gestão Técnica função como um todo são discutidos nesta seção como eles permitem Gestão Técnica como uma função para executar o seu papel. • Um conjunto de atividades distintas e processos que são executadas por todas as três funções de Aplicação, Técnico de TI e Gestão de Operações são abordados no Capítulo 5. As actividades de gestão genéricos técnicos se destacam as seguintes: • Identificar o conhecimento ea experiência necessários para gerenciar e operar o Infraestrutura de TI e para fornecer De serviços de TIs. Este processo começa durante a Estratégia de Serviço fase, é expandido em detalhe em Design de Serviços e é realizado em Operação de Serviço. Contínuo avaliação e atualização dessas habilidades é feito durante Melhoria de Serviço Continuada. • Documentação das habilidades que existem no organização, Bem como as capacidades que precisam de ser desenvolvido. Isso incluirá a desenvolvimento Habilidades de Inventários e as atuação Análise das Necessidades de Formação. • Iniciando treinamento programas para desenvolver e refinar as habilidades da técnica adequada recursos e treinamento manter registros para todos os recursos técnicos. ITIL V3 - Operação de Serviço - Página: 233 de 423
    • • Concepção e execução de treinamento para usuários, o Service Desk e outros grupos. Embora o treinamento exigências deve ser definido em Design de Serviços, são executadas de Operação de Serviço. Onde Gestão Técnica não entrega de formação, é responsável por identificar as organizações que podem fornecer isso. • Recrutamento ou contratação de recursos com as competências que não podem ser desenvolvidas internamente, ou onde há pessoas suficientes para realizar as atividades exigidas gestão técnica. • Aquisição de habilidades para atividades específicas, onde as habilidades necessárias não estão disponíveis internamente ou no mercado aberto, ou onde ela é mais custo-eficiente para fazer isso. • Definição de padrãos utilizados no projeto de novo arquiteturas e participação na definição de arquiteturas de tecnologia durante a Estratégia de Serviço e as fases do projeto. • Pesquisa e desenvolvimento de soluções que podem ajudar a expandir a Carteira de serviço, ou que podem ser usados para simplificar ou automatizar Operações de TI, Reduzir custars ou aumentar os níveis de serviço de TI. • Participação na concepção e construção de novos serviços. Gestão Técnica irá contribuir para a concepção das normas técnicas Arquitetura e desempenho para serviços de TI. Além disso, será também responsável por especificar o operacional atividades necessárias para gerenciar a Infraestrutura de TI em uma base contínua. • Envolvimento em projetos, não apenas durante o Design de Serviços e Transição de Serviço, mas também para Melhoria de Serviço Continuada ou projectos operacionais, tais como atualizações do sistema operacional, servidor projetos de consolidação ou movimentos físicos. • Disponibilidade e Gerenciamento da Capacidade são dependentes de Gestão Técnica de Engenharia de serviços de TI para atender os níveis de serviço exigidas pela empresa. Isto significa que, modelagem e carga de trabalho previsão são muitas vezes feito com recursos gestão técnica. • Assistência na avaliação risco, Identificando o serviço e críticas sistema dependências e definição e implementação de contramedidas. • Concepção e realização de testes para a funcionalidade, desempenho e capacidade de gerenciamento de serviços de TI. • Gestão de fornecedores. Muitos departamentos de Gestão Técnica ou grupos são os únicos que sabem exatamente o que é exigido de um fornecedor e como medir e gerenciá-los. Por esta razão, muitas organizações dependem de Gestão Técnica departamentos para gerir contratos com fornecedores de itens de configuração específica. Se este for o caso, é importante para assegurar que estes relaçãos são gerenciados como parte do SLM processo. • Definição e gestão dos Gestão de Eventos padrãos e ferramentas. Gestão Técnica também vai monitorar e responder a muitas categorias de eventos. ITIL V3 - Operação de Serviço - Página: 234 de 423
    • • Departamentos de gestão técnica ou grupos são essenciais para o atuação de Gerenciamento de Incidentes. Eles recebem através de incidentes Escalada funcional e fornecer suporte de segundo e de nível superior. Eles também estão envolvidos na manutenção de categorias e que define o escalada procedimentos que são executados em Gerenciamento de Incidentes. • Gestão Técnica em função fornece o recursos que executam o Gerenciamento de Problemas processo. É a sua competência técnica e conhecimento que é usado para diagnosticar e resolver problemas. É também sua relação com os vendedores que são usados para escalar e acompanhamento com as equipes de suporte do fornecedor. • Gestão de recursos técnicos estarão envolvidos na definição de codificação sistemas que são usados em Gestão de Incidentes e Problemas (Categorias por exemplo incidente). • Gestão de recursos técnicos são utilizados para apoiar a Gestão de Problemas na validação e manutenção da BDEC. • Gestão da Mudança depende do conhecimento técnico e experiência para avaliar as mudanças, e muitas mudanças será construído pela Direção Técnica. • Soltes são freqüentemente implementados com recursos gestão técnica. • Gestão Técnica irá fornecer informações para, e operacionalmente manter, o Sistema de gerenciamento de configuração e os seus dados. Isto será feito em cooperação com Aplicação de Gestão de para garantir que o CI correto atributos e os relacionamentos são criados a partir da desenvolvimento de serviços e da manutenção contínua ao longo da vida de CIs. • Gestão Técnica está envolvido na Melhoria de Serviço Continuada processos, especialmente na identificação de oportunidades de melhoria e, em seguida, para ajudar a avaliar as soluções alternativas. • Como um guardião do conhecimento técnico e experiência, Gestão Técnica garante que todo o sistema operacional e documentação está atualizada e devidamente utilizado. Isto inclui assegurar que toda a gestão, administração e usuário manuais estão em dia e concluir e que a equipe técnica está familiarizado com seu conteúdo. • Atualização e manutenção de dados utilizados para elaboração de relatórios sobre as capacidades técnicas e de serviço, por exemplo, Capacidade e Gestão de Desempenho, Gerenciamento de Disponibilidade, Gerenciamento de Problemas, etc • Auxiliar de TI Gestão Financeira para identificar o custar de TI e recursos humanos utilizados para gerenciar De serviços de TIs. • Envolvimento na definição do operacional atividades realizadas como parte de TI Gestão de Operações. Muitos departamentos de gestão técnica, grupos ou equipes também executam as atividades operacionais, como parte de um organização'S TI Gestão de Operações função. ITIL V3 - Operação de Serviço - Página: 235 de 423
    • 6.3.4 organização Gestão Técnica Gestão Técnica normalmente não é fornecido por um único departamento ou grupo. Um ou mais Suporte técnico equipes ou departamentos serão necessários para fornecer gerenciamento e apoio técnico para a Infraestrutura de TI. Ao todo, mas as menores organizações, onde uma equipe única, combinada ou departamento pode ser suficiente, as equipes ou departamentos separados serão necessários para cada tipo de infra-estrutura utilizada. TI Gestão de Operações consiste de um certo número de áreas tecnológicas. Cada uma delas requer um conjunto específico de habilidades para gerenciar e operar lo. Alguns conjuntos de competências são relacionado e pode ser realizada por generalistas, enquanto outros são específicos de um componente,sistema ou plataforma. O principal critério de estrutura organizacional de Gestão Técnica é a de especialização ou divisão do trabalho. O princípio é que as pessoas são agrupadas de acordo com suas habilidades técnicas, e que estes conjuntos de habilidades são determinadas pela tecnologia que precisa ser gerenciado. Seções 6.6 e 6.7 abrangem os aspectos organizativos de Gestão Técnica em detalhes, mas esta lista apresenta alguns exemplos típicos de equipas de gestão técnicos ou departamentos: • Mainframe equipe ou departamento - se um ou mais tipos de mainframe ainda estão sendo usados pelo organização • Servidor equipe ou departamento - muitas vezes dividir novamente por tipos de tecnologia (por exemplo, Unix servidor, Wintel servidor) • Equipe de armazenamento ou departamento, responsável pela gestão de todos os dispositivos de armazenamento de dados e mídia • Equipe de suporte de rede ou departamento, cuidando de WANs internos da organização / LANs e gestão de qualquer rede externa fornecedors • Área de trabalho da equipe ou departamento, responsável por todos os equipamentos desktop instalado • Equipe de banco de dados ou departamento, responsável pela criação, manutenção e suporte de bases de dados da organização • Middleware equipe ou departamento, responsável pela integração, teste e manutenção de todas as middleware em uso na organização • Serviço de DiretórioA equipe ou departamento, responsável por manter o acesso e direitos de elementos de serviço na infra-estrutura • Internet ou Web equipe ou departamento, responsável pela gestão do disponibilidade e segurança de acesso aos servidores e conteúdo por cliente externos, usuários e parceiros • Mensagens equipe ou departamento, responsável por serviços de correio electrónico • Baseada em IP Telephony equipe ou departamento (por exemplo, VoIP). ITIL V3 - Operação de Serviço - Página: 236 de 423
    • 6.3.5 Manutenção Design e Técnico de Apoio Técnico e Gestão Técnica consiste de arquitetos especializados técnicos e designers (que estão principalmente envolvidos durante Design de Serviços) E pessoal especializado de manutenção e suporte (que são principalmente envolvidos durante Operação de Serviço). Nesta publicação, eles são vistos como sendo parte da mesma função, Mas muitas organizações vê-los como duas equipes distintas ou mesmo departamentos. O problema com esta abordagem é que boa projeto precisa de entrada das pessoas que são necessários para gerenciar a solução - e bom operação requer o envolvimento das pessoas que projetaram a solução. O problemas que precisam ser superados são semelhantes aos enfrentados na gestão da Aplicação Ciclo de Vida (Ver secção 6.5 para uma discussão mais detalhada). A solução irá incluir os seguintes elementos: • Pessoal de apoio devem ser envolvidos durante o projeto ou arquitetura de uma solução. Equipe de projeto deve ser envolvido na criação de manutenção objetivos e resolver problemas de suporte. • A mudança na forma como o projeto ea equipe de suporte são medidos. Designers deve ser realizada, em parte, responsáveis por falhas de projeto que criam operacional interrupções. Equipe de apoio deverá ser realizada, em parte, responsável pela contribuição para a arquitetura técnica. 6.3.6 Técnicas de Gestão de métricas Métricas para Gestão Técnica dependerá em grande parte da tecnologia que está a ser gerido, mas alguns genéricos métricos incluem: • Medição de resultados acordados. Estas podem incluir: • Contribuição para a realização dos serviços para o negócio. Apesar de muitas das equipas de gestão técnicos não estarão em contato direto com a empresa, a tecnologia que gerem impacto no negócio. Métricas devem refletir tanto (incidentes traçadas para a sua equipe) negativos e positivos (sistema atuação e disponibilidadeContribuições) • Transação taxas e disponibilidade para operações críticas de negócios • Service Desk treinamento • Gravação problema resoluçãos para o BDEC • Usuário medidas do qualidade de saídas, tal como definidos no SLA • Instalação e configuração de componentes sob seu controlar. ITIL V3 - Operação de Serviço - Página: 237 de 423
    • • Métricas de processo. As equipas de gestão técnica executar Gerenciamento de Serviços de muitos processo actividades. A sua capacidade de fazê-lo será medido como parte das métricas de processo se for o caso (ver secção sobre cada processo para mais detalhes). Os exemplos incluem: • O tempo de resposta para eventos e as taxas de conclusão do evento • Incidente resolução vezes por segundo e terceira linha de apoio • Resolução de problemas estatísticas • Número de escaladas e razão para as escalações • Número de mudanças implementadas e saiu • Número de alterações não autorizadas detectado • Número de liberars implantado, com sucesso total e • Questões de segurança detectados e resolvidos • Real sistema utilização contra Plano de capacidade previsões (onde a equipe tem contribuído para a desenvolvimento do plano) • Rastreamento contra PIS • Despesas contra orçamento. • Tecnologia atuação. Estes métricos são baseados Design de Serviços especificaçãos e desempenho técnico padrãos definir por vendedores, e serão normalmente contido em OLAs ou Procedimentos Operacionais Padrão. Métricas reais variam de acordo com a tecnologia, mas é provável que incluem: • Taxas de utilização (por exemplo, memória ou processador para servidor, Largura de banda para redes, etc) • Disponibilidade (De sistemas, de rede, dispositivos, etc), que é útil para a medição da equipa ou o desempenho do sistema, mas não deve ser confundida com a disponibilidade de serviço - o que requer a capacidade para medir a disponibilidade geral do serviço e pode usar os números de disponibilidade para um certo número de sistemas individuais ou componentes • Performance (e.g. tempo de respostas, filas taxas, etc.) • Tempo médio entre falhas dos equipamentos especificados. Esta métrica é utilizado para assegurar que as decisões de compra boas e estão a ser feitos, quando comparado com os programas de manutenção, se o equipamento está a ser correctamente mantido • A medição da atividade de manutenção, Incluindo: • Manutenção realizada por horário • Número de janelas de manutenção ultrapassado • Manutenção objetivos alcançado (número e porcentagem). • Formação e competências desenvolvimento. Essas métricas garantir que a equipe tem as habilidades e treinamento para gerenciar a tecnologia que está sob a sua controlar, E também identificar as áreas em que a formação ainda é necessária. ITIL V3 - Operação de Serviço - Página: 238 de 423
    • 6.3.7 documentação Gestão Técnica Gestão Técnica está envolvido na elaboração e manutenção de várias documentos como parte de outros processos (por exemplo, Planejamento de Capacidade,Gestão da Mudança,Gerenciamento de Problemas, Etc.) Estes documentos são discutidos com algum detalhe no relevante processo descrições. No entanto, existem alguns documentos que são específicos para os grupos técnicos de gestão ou as equipes que irão documentar gestão e controle de documentos relativos à tecnologia sob seu controle. Documentação Gestão Técnica inclui o seguinte. 6.3.7.1 A documentação técnica O fornecimento e manutenção de documentação técnica para todos os itens de configuração é de responsabilidade do gerenciamento técnico. Estes incluem: • Manuais Técnicos • Manuais de gestão e administração • Usuário manuais para CEI. Estes serão geralmente excluem aplicação manuais do usuário, que são mantidos por Aplicação de Gestão de. 6.3.7.2 programações de manutenção Estes esquemas são elaborados e acordados durante a Design de Serviços fase relacionada com a disponibilidade e Gerenciamento da Capacidade, Mas são essencialmente as propriedades dos vários Gestão Técnica departamentos, grupos ou equipes. Isso é porque eles tem o conhecimento técnico para tecnologias específicas e são mais susceptíveis de saber o que é necessário para mantê-los em funcionamento. Para mais detalhes sobre a definição de programas de manutenção e Objetivo de manutenção do serviços, referem-se a ITIL Design de Serviços publicação. 6.3.7.3 Inventário de Habilidades Um Inventário de Habilidades é um sistema ou ferramenta que identifica as competências necessárias para dar suporte De serviços de TIs e também os indivíduos que possuem essas habilidades. Estoques habilidades são mais eficazes se elas estão alinhadas com os processos, arquiteturas e atuação padrãos. Além disso, estoques habilidades devem identificar o treinamento disponível para cultivar cada habilidade deve deixar o pessoal existente organização. ITIL V3 - Operação de Serviço - Página: 239 de 423
    • Estoques habilidades também podem ser usados como parte do Portfólio de Serviços para avaliar se um novo serviço pode ser entregue com o pessoal existente e conjuntos de habilidades, ou se um investimento tem de ser feito em equipe nova ou treinamento. Estoques habilidades pode, portanto, contribuir significativamente para a Planejamento de Capacidade. A definição e manutenção de estoques Habilidades requer uma boa interface com processos de Recursos Humanos e ferramentas na organização. ITIL V3 - Operação de Serviço - Página: 240 de 423
    • 6,4 TI Gestão de Operações Nos negócios, o termo 'Gestão de Operações"É usada para significar o departamento, grupo ou equipe de pessoas responsáveis por executar a organização do dia-a-dia operacional - actividades como correr da linha de produção de uma fabricação ambiente ou a gestão dos centros de distribuição e os movimentos da frota dentro de uma organização logística. Gestão de Operações geralmente tem as seguintes características: • Há trabalho para assegurar que um dispositivo, sistema ou processo é, na verdade, correr ou de trabalho (em oposição a estratégia ou planejamento) • Isto é onde planos são transformados em ações • O foco é sobre as actividades diárias ou a curto prazo, mas deve notar-se que estas actividades serão geralmente realizada e repetida ao longo de um período relativamente longo (em oposição a one-off projeto atividades do tipo) • Essas atividades são executadas por pessoal técnico especializado, que muitas vezes têm de receber formação técnica para aprender a executar cada atividade • Há um foco na construção de ações consistentes repetíveis, que - se repetido com freqüência suficiente no nível certo de qualidade - Se assegurar o sucesso do operação • Isto é, onde o valor real da organização é entregue e medido • Existe uma dependência sobre o investimento em equipamentos ou recursos humanos ou de ambos • O valor gerado, deve exceder o custar do investimento e todos os outros organizacional despesas geraiss (tais como gestão e custos de marketing) se o negócio é de sucesso. De um modo semelhante, TI Gestão de Operações pode ser definida como a função de responsável pela gestão e manutenção constantes de uma organização de Infraestrutura de TI para garantir a entrega do nível acordado de De serviços de TIs para o negócio. Operações de TI pode ser definido como o conjunto de actividades envolvidas no funcionamento do dia-a-dia da Infraestrutura de TI com o objetivo de entregar serviços de TI em níveis acordados para atender negócios declarado objetivos. 6.4.1 Funções de Gerenciamento de Operações de TI O papel de Gestão de Operações é executar as actividades em curso e procedimentos necessárias para gerenciar e manter a infra-estrutura de TI, de modo a entregar e suportar serviços de TI nos níveis acordados. Estes já foram descritos na seção 5, mas são resumidas aqui para ser completo: ITIL V3 - Operação de Serviço - Página: 241 de 423
    • • Operações de controle, Que supervisiona a execução e monitoramento do operacional actividades e eventos na Infra-estrutura de TI. Isto pode ser feito com o auxílio de um Operações Ponte ou Centro de Operações de Rede. Além de executar as tarefas de rotina de todas as áreas técnicas, Controle de Operações também executa as seguintes tarefas específicas: • Console de Gerenciamento de, Que se refere à definição de observação central e monitoramento capacidade e em seguida, usando os consoles para exercer o acompanhamento e controlar atividades • Job Scheduling, Ou a gestão de trabalhos em lote de rotina ou scripts • Faça backup e Restaurar em nome de todos os técnicos e equipes de gerenciamento de aplicativos e serviços e, muitas vezes, em nome da usuários • De impressão e de saída de gestão para a recolha e distribuição de toda a impressão centralizada ou saída eletrônica • Desempenho das atividades de manutenção em nome técnico ou Aplicação de Gestão de equipes ou departamentos. • Gestão de Instalações, Que se refere à gestão da TI física ambiente, Normalmente um Centro de Dados ou salas de informática e recuperação locais, juntamente com toda a potência e equipamentos de refrigeração. Facilities Management também inclui a coordenação de grande escala de consolidação projetos, por exemplo, Consolidação de dados ou Centro servidor projetos de consolidação. Em alguns casos, a gestão de um data center é terceirizado, no qual Facilities Management caso refere-se à gestão do terceirização contrato. Tal como acontece com muitos IT Service Management processos e funções, TI Gestão de Operações desempenha um duplo papel. • Gerenciamento de Operações é responsável pela execução das atividades e atuação padrãos definido durante Design de Serviços e testado durante a Transição de Serviço. Neste sentido, o papel de operações de TI "é, principalmente, manter o status quo. A estabilidade do Infraestrutura de TI e consistência de De serviços de TIs é uma preocupação primordial de Operações de TI. Mesmo operacional melhorias visam encontrar formas mais simples e melhor de se fazer a mesma coisa. • Ao mesmo tempo, as operações de TI é parte do processo de agregação de valor para os diferentes linhas de negócios e apoiar a rede de valor (Veja o ITIL Estratégia de Serviço publicação). A capacidade da empresa para cumprir o seu objetivos e para manter a competitividade depende da saída e confiança do dia-a-dia operação de TI. Como tal, TI Gestão de Operações deve ser capaz de se adaptar continuamente a actividade exigências e procura. O negócio não se importa que operações de TI ITIL V3 - Operação de Serviço - Página: 242 de 423
    • cumprido um padrão procedimento ou que um servidor realizada de forma otimizada. Como a demanda de negócios e mudança de requisitos, Gerenciamento de Operações deve ser capaz de manter o ritmo com eles, muitas vezes desafiando o status quo. Operações de TI deve alcançar um equilíbrio entre essas funções, o que exigirá o seguinte: • A compreensão de como a tecnologia é usada para fornecer serviços de TI • A compreensão da importância relativa e impacto desses serviços sobre o negócio • Procedimentos e manuais que delineiam o papel das operações de TI, tanto na gestão da tecnologia e da entrega de De serviços de TIs • Um conjunto claramente diferenciada de métricos de informar a empresa sobre a realização dos objectivos de serviço, e de informar os gestores de TI na eficiência e eficácia de Operações de TI • Todos a equipe de TI Operações entender exatamente como o atuação da tecnologia afeta serviços da entrega de TI • Acustar estratégia destinado a equilibrar as exigências de diferentes unidade de negócioss com a redução de custos através da otimização disponíveis da tecnologia existente ou o investimento em novas tecnologias • Um valor, em vez de custo, retorno com base na estratégia de investimento. 6.4.2 Operações de TI objectivos de gestão Os objetivos do Gerenciamento de Operações incluem: • Manutenção do status quo para alcançar a estabilidade do organizaçãoDia-a-dia 's processos e atividades • Escrutínio regular e melhorias para alcançar um melhor serviço a custos reduzidos, mantendo a estabilidade • Rápido aplicação de habilidades operacionais para diagnosticar e resolver quaisquer operações de TI falhas que ocorrem. 6.4.3 Operações de TI Gestão de organização Figura 6.1 na introdução do Capítulo 6 ilustra que a TI Gestão de Operações é visto como um função em seu próprio direito, mas que, em muitos casos equipe, do técnico e Aplicação de Gestão de grupos formam parte desta função. Isso significa que alguns departamentos de Gestão Técnica e Aplicação ou grupos vão gerenciar e executar os seus próprios operacional actividades. ITIL V3 - Operação de Serviço - Página: 243 de 423
    • Outros vão delegar essas atividades a um dedicado Operações de TI departamento. Não existe um método único para a atribuição de actividade, uma vez que depende da maturidade e estabilidade da infra-estrutura que está sendo gerenciado. Por exemplo, Técnico e áreas de aplicação de gerenciamento que são relativamente novo e instável tendem a gerenciar suas próprias operações. Grupos onde a tecnologia ou aplicação é estável, maduro e bem compreendido tendem a ter suas operações mais padronizadas e, portanto, se sentem mais confortáveis delegar essas atividades. Algumas opções de como estruturar operações de TI são discutidos em detalhes na seção 6.7 desta publicação. 6.4.4 Operações de TI métricas de gestão TI Gestão de Operações é medida em termos da sua execução eficaz das atividades especificadas e procedimentos, bem como a sua execução processo actividades. Exemplos destes são os seguintes: • A conclusão bem sucedida de trabalhos agendados • Número de exceções para as atividades programadas e empregos • Número de dados ou sistema restaurars exigido • Equipamentos estatísticas de instalação, incluindo o número de itens instalados por tipo, instalações bem-sucedidas, etc • Processo métricos. Gestão de Operações de TI Service Management executa muitos processo actividades. A sua capacidade de fazê-lo será medido como parte das métricas de processo se for o caso (ver secção sobre cada processo para mais detalhes). Os exemplos incluem: • O tempo de resposta para eventos • Incidente resolução vezes por incidentes • Número de segurançaIncidentes relacionados • Número de escaladas e razão para as escalações • Número de mudanças implementadas e saiu • Número de alterações não autorizadas detectado • Número de liberars implantado, com sucesso total e • Rastreamento contra PIS • Despesas contra orçamento. • Se as atividades de manutenção ter sido delegada, então métricas relacionadas a essas atividades também será apropriado: • Manutenção realizada por horário • Número de janelas de manutenção ultrapassado • Manutenção objetivos alcançado (número e porcentagem). • Métricas relacionadas a Gestão de Instalações são extensas, mas geralmente incluem: ITIL V3 - Operação de Serviço - Página: 244 de 423
    • • Custos versus orçamento relacionados com a construção, manutenção, segurança, Transporte, etc • Incidentes relacionados com a construção, por exemplo, reparos necessários para a instalação de • Relatórios sobre acesso à facilidade • Número de segurança eventos e incidentes e suas resolução • Estatísticas de utilização de energia, além de aspectos relacionados a mudanças no layout e estratégias de condicionamento ambiental • Eventos ou incidentes relacionados com o transporte e distribuição. 6.4.5 Operações de TI Gestão de documentação Um certo número de documentos são produzidos e utilizados durante TI Gestão de Operações. Esta lista é um resumo de alguns dos mais importantes e não inclui relatórios que são produzidos pela TI Gestão de Operações em nome de outros processos ou funçãos. 6.4.5.1 Procedimentos Operacionais Padrão Os POPs são um conjunto de documentos que contêm instruções detalhadas e atividade horários para cada equipe de Gerenciamento de Operações de TI, departamento ou grupo. Esses documentos representam a rotina de trabalho que precisa ser feito para cada dispositivo, sistema ou procedimento. Eles também descrevem os procedimentos a serem seguidos se uma exceção é detectada ou se um mudar é necessária. Documentos SOP também pode ser utilizado para definir níveis padrão de atuação para dispositivos ou procedimentos. Em alguns organismos os documentos SOP são referidos no OLA. Em vez de listar medidas de desempenho detalhadas no OLA, uma cláusula é inserida para se referir ao desempenho padrãos no POP e como estes serão medidos e relatados. 6.4.5.2 Operações Logs Qualquer atividade que é realizada como parte de Operações de TI devem ser registados para uma série de razões, incluindo: • Elas podem ser usadas para confirmar a conclusão bem sucedida de trabalhos ou actividades específicas • Elas podem ser usadas para confirmar que um De serviços de TI foi entregue conforme acordado • Eles podem ser utilizados por Gerenciamento de Problemas para pesquisar o causa raiz de incidentes ITIL V3 - Operação de Serviço - Página: 245 de 423
    • • Eles são a base para relatórios sobre o desempenho das equipes de TI de Gestão de Operações e departamentos. O formato destes registros é tão variada quanto o número de sistemas e Gestão de Operações equipes ou departamentos. Exemplos de Logs operações incluem o seguinte: • Sistema operacional registra armazenados em cada dispositivo • Aplicação registros de atividades armazenados em um arquivo no aplicação servidor • Evento Troncos armazenados no monitoramento servidor ferramenta • Logs de utilização de dispositivos-chave • Gravação de logs de acesso físico que acessou edifícios mais seguros e quando • Registros manuscritos das ações realizadas pelos operadores. Este deve ser em um diário de bordo formal ou fichário, numeradas e armazenadas de forma segura ambiente. Os cheques devem assegurar que as páginas não são removidos. Apolítica precisa ser estabelecido como parte dos POPs, para afirmar como os logs de longas precisam ser mantidos, como são arquivados e quando eles podem ser excluídos. Essas políticas levarão em conta estatutária e observância exigências. Políticas também devem especificar os parâmetros para o armazenamento adequado e apoio estratégias para armazenar e recuperar arquivos de log. 6.4.5.3 Shift Schedules e Relatórios Horários de turnos são documentos que delineiam as atividades exatas que precisam ser realizadas durante o deslocar. Eles também irá listar todas as dependências e atividade seqüências. Haverá provavelmente mais do que um programa de mudanças, onde cada equipe terá um versão por sua própria sistemas. É importante que todos os horários são coordenados, antes do início da passagem. Isso geralmente é feito por uma pessoa que é especializada em turno programação, com a ajuda de ferramentas de programação. A Programação deslocamento pode consistir de um número de itens de rotina que estão incluídos no POP. Neste caso, os artigos podem simplesmente ser listados sucintamente com uma referência para a secção ou da página na SOP. Horários mais turnos assumir a forma de uma lista onde os operadores podem marcar o item como ela for concluída, juntamente com o tempo de conclusão. Isto torna mais fácil para ver o andamento das atividades e também ajuda a identificar possíveis problemas onde os trabalhos estão demorando muito. ITIL V3 - Operação de Serviço - Página: 246 de 423
    • Relatórios de turnos são uma forma de registrar as operações, mas têm o adicional funçãos como se segue: • Para gravar grande eventos e ações que ocorreram durante o turno • Para fazer parte da transferência de soberania entre os líderes de mudança • Para denunciar qualquer exceção à Objetivo de manutenção do serviços • Para identificar qualquer incompleto atividade que podem resultar em degradação atuação em qualquer serviço durante a próxima horas de serviço. 6.4.5.4 Horário de Operações As listas de Operações são semelhantes a mudar programações mas cobrem todos os aspectos da Operações de TI a um nível elevado. Essa programação vai incluir uma visão geral de todas as alterações planejadas, manutenção, trabalhos de rotina e trabalho adicional, juntamente com informações sobre o negócio ou eventos de fornecedores. O Cronograma de Operações é usado como base para a Reunião de operações diárias e é a referência principal para todos os gerentes de operações de TI para acompanhar o progresso e detectar exceções. 6,5 Gerenciamento de Aplicativos Aplicação de Gestão de é responsável pela gestão aplicaçãos ao longo da sua ciclo de vida. A função de gerenciamento de aplicativos é realizada por qualquer departamento, grupo ou equipe envolvida na gestão e suporte operacional aplicações. Gerenciamento de Aplicativos também desempenha um importante papel no projeto, Teste e aperfeiçoamento de aplicações que fazem parte do De serviços de TIs. Como tal, ele pode estar envolvido em desenvolvimento projetos, mas normalmente não é o mesmo que as equipas de desenvolvimento de aplicações. 6.5.1 papel Gerenciamento de Aplicativos Gerenciamento de Aplicativos é a aplicações que Gestão Técnica é o Infraestrutura de TI. Aplicação de Gestão desempenha um papel em todas as aplicações, se comprados ou desenvolvidos in-house. Uma das principais decisões que contribuam para a decisão de se comprar um aplicativo ou construir -o (isto é discutido em detalhe no Design de Serviços publicação). Uma vez que a decisão é tomada, Gerenciamento de Aplicativos irá desempenhar um duplo papel: • Ele é o guardião do conhecimento técnico e experiência relacionada com aplicações de gestão. Neste Aplicação de Gestão de papel, trabalhando em conjunto com a Gestão Técnica, garante que o conhecimento ITIL V3 - Operação de Serviço - Página: 247 de 423
    • necessário para projetar, teste, Gerir e melhorar os serviços de TI é identificado, desenvolvido e aperfeiçoado. • Ele oferece a real recursos para suportar o ITSM Ciclo de Vida. Neste papel, Gerenciamento de Aplicativos garante que os recursos sejam efetivamente treinados e distribuídos para projetar, construir, Transição, operar e melhorar a tecnologia necessária para entregar e suportar os serviços de TI. Ao realizar essas duas funções, gerenciamento de aplicativos é capaz de garantir que o organização tem acesso ao tipo certo e nível de recursos humanos para gerenciar aplicações e, portanto, para atender empresas objetivos. Esta começa em Estratégia de Serviço e é expandido em Design de Serviço, testado em Transição de Serviço e refinado em Melhoria de Serviço Continuada (Ver outro ITIL publicações nesta série). Parte desse papel é garantir um equilíbrio entre o nível de habilidade e do custar desses recursos. Para além destes dois papéis de alto nível, Application Management também executa as seguintes funções específicas: • Fornecer orientação para Operações de TI sobre a melhor forma de proceder à gestão em curso operacional de aplicações. Este papel é parcialmente realizado durante o Design de Serviços processo, Mas é também uma parte da comunicação diária com TI Gestão de Operações , que procuram alcançar a estabilidade e ótima atuação. • A integração do Ciclo de Vida do Gerenciamento de Aplicativos para o Ciclo de Vida de ITSM. Isto é discutido abaixo. Os objetivos, atividades e estruturas que permitem Gerenciamento de Aplicativos para jogar esses papéis efetivamente são discutidas abaixo. 6.5.2 Aplicação objectivos de gestão Os objetivos do gerenciamento de aplicativos são apoiar a organização do processo de negócioes, ajudando a identificar funcional e capacidade de gerenciamento exigências para o software de aplicação e, em seguida, para auxiliar na concepção e desenvolvimento dessas aplicações e suporte contínuo e melhoria dessas aplicações. Estes objectivos são alcançados através de: • Os aplicativos que são bem desenhados, resistente e de baixo custo • Garantir que a funcionalidade está disponível para realizar o negócio exigido resultado ITIL V3 - Operação de Serviço - Página: 248 de 423
    • • O organização de competências técnicas adequadas para manter operacional aplicaçãos em condição ideal • Swift uso de habilidades técnicas para diagnosticar e resolver rapidamente qualquer técnica falhas que ocorrem. 6.5.3 Gestão de princípios de aplicação 6.5.3.1 Construir ou comprar? Uma das principais decisões em Aplicação de Gestão de é se comprar uma aplicação que suporta a funcionalidade necessária, ou se a construir a aplicação específica para a organização do exigências. Estas decisões são muitas vezes feitas por um Diretor Técnico (CTO) ou Comitê Gestor, mas são dependentes da informação a partir de um número de fontes. Estes são discutidos em detalhe na Design de Serviços, Mas estão aqui resumidas a partir de uma Aplicação de Gestão função perspectiva. Gerenciamento de Aplicativos irá ajudar nesta decisão durante Design de Serviços como se segue: • Aplicação dimensionamento e carga de trabalho previsões (ver secção 4.6.4) • Especificação de gerenciamento exigências • Identificação de curso custo operacionals • Dados os requisitos de acesso para o relatório ou a integração de outras aplicações • Investigar até que ponto a funcionalidade necessária pode ser atendida pelas ferramentas existentes - e quanto personalização será necessário para alcançar este • Estimar o custo de personalização • Identificar quais habilidades serão necessárias para apoiar a solução (por exemplo, se um aplicativo é comprado, vai exigir um novo conjunto de empregados, ou empregados existentes podem ser treinados para apoiá- lo?) • Requisitos de administração • Requisitos de segurança. Se a decisão é construir a aplicação, uma decisão ainda precisa ser feita se o desenvolvimento será terceirizada ou construído usando funcionários. Isto é detalhado no Estratégia de Serviço e Serviço de publicações de design, mas há algumas considerações importantes que afetam a operação de serviço, por exemplo: • Como os requisitos de gerenciamento ser especificadas e acordadas (por exemplo, aplicação de concepção e transação monitoramento)? Estas ITIL V3 - Operação de Serviço - Página: 249 de 423
    • são algumas vezes esquecida quando operacional equipes ou departamentos não estão representados no projeto • Quais são os Aceitação Critérios para operacional atuação, Como e onde vai ser a solução testada e que irá realizar os testes? • Quem será o proprietário e gerir a Biblioteca definitivo para essa aplicação? • Quem vai projeto e manter o operacional gestão e administração scripts para estas aplicações? • Quem é responsável pelo ambiente de set-up e possuir e manter a infra- estrutura diferente componentes? • Como vai ser a solução instrumentada de forma que ele é capaz de gerar o requerido eventos? 6.5.3.2 Modelos Operacionais Um Operacional Modelo é o especificação do operacional ambiente em que o aplicação acabará por correr quando ele vai viver. Isto irá ser utilizado durante a fase de ensaio e de transição para simular e avaliar o viver ambiente. Esta é uma forma de garantir que o aplicativo pode ser dimensionados corretamente e as condições ambientais necessárias podem ser documentados e compreendidos por todos. A Operacional Modelo devem ser definidas e utilizadas em testes, durante o Design de Serviços e Transição de Serviço fases, respectivamente (ver Design de Serviços e publicações Transição de Serviço). 6.5.4 Aplicação de Gestão do Ciclo de Vida O ciclo de vida seguido para desenvolver e gerenciar aplicações tem sido referido por muitos nomes, incluindo o software Ciclo de Vida (SLC) e Software Development Lifecycle (SDLC). Estes são geralmente utilizados pelas equipes de desenvolvimento de aplicações e sua Projeto Gestores para definir o seu envolvimento na concepção, construção, testes, implantação e suporte de aplicações. Exemplos dessas abordagens são Análise de Sistemas Estruturado e Metodologia Design (SSADM), Dynamic Método de Desenvolvimento de Sistemas (DSDM), Rapid Application Development (RAD), etc ITIL está interessado principalmente na gestão global de aplicativos como parte de De serviços de TIs, sejam eles desenvolvidos internamente ou comprado de um terceiro. Por esta razão, o termo Aplicação de Gestão de Ciclo de vida tem sido utilizada, uma vez que implica uma visão mais holística. Isso não deve substituir o SDLC, que ainda é uma abordagem válida usado por desenvolvedores, especialmente por empresas de software de terceiros. No entanto, isso não significa que deve haver um maior alinhamento entre o desenvolvimento ver de aplicaçãos e da gestão "ao vivo" dessas aplicações. ITIL V3 - Operação de Serviço - Página: 250 de 423
    • Isso é mais difícil em grandes aplicativos adquiridos, tais como e-mail, já que os desenvolvedores não costumam interagir individualmente com seu aplicativo usuários. No entanto, o ciclo de vida básico ainda é válido na medida em que a aplicação precisa exigências, projeto, Customização, operação e desenvolvimento. A otimização é obtida através de uma melhor gestão, melhorias para a personalização e upgrades. O Ciclo de Vida do Gerenciamento de Aplicativos é ilustrado da seguinte forma: Figura 6.5 Aplicação de Gestão do Ciclo de Vida Processos de ITSM e processos de desenvolvimento de aplicações têm de ser alinhadas como parte do total estratégia de entrega de serviços de TI em apoio ao negócio. Aplicações Desenvolvimento e Operações fazem parte do ciclo de vida do mesmo conjunto e ambas devem ser envolvidas em todas as fases, embora o seu nível de envolvimento pode variar, dependendo da fase do ciclo de vida. ITIL V3 - Operação de Serviço - Página: 251 de 423
    • Relação entre o gerenciamento de aplicativos e Serviço de Gestão de Ciclo de Vidas O Aplicação de Gestão de Ciclo de Vida não deve ser visto como uma alternativa para o Lifecycle Management Service. As aplicações são parte dos serviços e têm de ser gerenciados como tal. No entanto, aplicaçãos são uma mistura única de tecnologia e funcionalidade e isso requer um foco especializado em cada fase do ciclo de vida de Gerenciamento de Serviços. Cada etapa do ciclo de vida de gerenciamento de aplicativos tem seu próprio conjunto específico de objetivos, atividades entregas e equipes dedicadas. Cada estágio tem também uma responsabilidade clara para garantir que suas saídas igualar-se aos objetivos específicos do Lifecycle Management Service. Diferentes aspectos do gerenciamento de aplicativos são abordados em detalhes em cada uma das publicações da ITIL, como segue: • Estratégia de Serviço: Define o total arquitetura de aplicações e infra- estrutura. Isso irá incluir a definição dos critérios para o desenvolvimento in-house, terceirização desenvolvimento, Ou a compra e personalização de aplicativos. Estratégia de Serviço também vai ajudar a definir o Portfólio de Serviços (Incluindo as aplicações), que também inclui informações sobre o retorno do investimento de aplicações e os serviços que eles suportam. Assim, de alto nível exigências são definidos durante esta fase. • Design de Serviços: Ajuda a estabelecer requisitos para a funcionalidade e capacidade de gerenciamento de aplicações e trabalha com equipes de desenvolvimento para que possam cumprir com esses objetivos. Design de Serviços cobre a maior parte da fase de Requisitos e está envolvido durante a Construir fase do Ciclo de Vida do Gerenciamento de Aplicativos. • Transição de Serviço: Equipes de desenvolvimento de aplicativos e Gestão estão envolvidos em testar e validar o que foi construído e implantá-lo operacionalmente. • Operação de Serviço:Este abrange a fase Operate do Lifecycle Management Application. Esses processos e estruturas são discutidas em pormenor nesta publicação. • Melhoria de Serviço Continuada: Cobre o Otimizar fase do Ciclo de Vida do Gerenciamento de Aplicativos. Melhoria de Serviço Continuada mede a qualidade e relevância de aplicações em operação e fornece recomendações sobre como melhorar as aplicações se há um retorno claro sobre o investimento para o fazer. 6.5.4.1 Requisitos Esta é a fase durante a qual o exigências para uma nova aplicação estão reunidos, com base nas necessidades comerciais do organização. Esta fase é ITIL V3 - Operação de Serviço - Página: 252 de 423
    • ativa principalmente durante a fase de Design de Serviços do Ciclo de Vida de ITSM. Existem seis tipos de requisitos para qualquer aplicação, seja sendo desenvolvido in-house, terceirizado ou adquirido: • Os requisitos funcionais são aqueles especificamente necessária para suportar um negócio particular função • Gerenciabilidade exigências, olhou de um Serviço de Gestão de perspectiva, abordar a necessidade de um serviço ágil, seguro e disponível, e lidar com questões como a desenvolvimento, Operações sistema de gestão e segurança • Usabilidade requisitos são aqueles que abordar as necessidades da extremidade usuário, E em consequência as características do sistema que facilitam a sua facilidade de uso • Requisitos arquitetônicos, especialmente se este exige uma mudar a existente arquitetura padrãos • Requisitos de interface, onde existem dependências entre existentes aplicaçãos ou ferramentas e da nova aplicação • Exigência de Nível de Serviços, que especificam como o serviço deve realizar, a qualidade de sua produção e outros aspectos qualitativos medidos pelo usuário ou cliente. 6.5.4.2 Desenho Esta é a fase durante a qual são traduzidos em requisitos especificaçãos. Projeto inclui a projeto da aplicação em si, eo design do ambiente, ou operacional modelo que a aplicação tem que correr. Considerações de arquitectura é o aspecto mais importante desta fase, uma vez que eles podem impacto sobre a estrutura eo conteúdo de ambos aplicação e modelo operacional. Considerações de arquitetura para a aplicação (projeto da arquitetura do aplicativo) e considerações arquitetônicas para o operação modelo (projeto da arquitetura do sistema) estão fortemente relacionados e precisam ser alinhados. No caso de aquisição de software, a maioria das organizações não será permitida a entrada direta para o design do software (o qual já tenha sido construído). No entanto, é importante que o Gerenciamento de aplicativo é capaz de fornecer feedback para o fornecedor de software sobre a funcionalidade de gerenciamento e atuação do software. Isto irá, por sua vez, ser assumida pelo fornecedor do software, como parte de um aperfeiçoamento do software. Parte da avaliação processo para o software adquirido deve incluir uma avaliação de se o vendedor é sensível a tais comentários. Ao mesmo tempo, devem assegurar que existe um equilíbrio entre ser sensível e mudando o seu ITIL V3 - Operação de Serviço - Página: 253 de 423
    • software de tal forma que é perturbador ou que muda algumas funcionalidades básicas. Design para software adquirido também irá incluir o projeto de qualquer personalização que é necessário. De especial importância aqui é avaliar se o futuro versão do software irá apoiar a personalização. 6.5.4.3 Construção No Construir fase, tanto a aplicação e do modelo operacional estão prontas para implantação. Aplicação componentes são codificados ou adquirida, integrado e testado. Por favor note que Teste não é uma fase separada no ciclo de vida, Ainda que seja um discreto atividade, E mesmo que os testes são realizados de forma independente de ambos os desenvolvimento e atividades operacionais. Sem a criar e implantar as fases, não haveria nada de testar e, sem testes, não haveria controle sobre o que é desenvolvido e implantado. O teste é um componente integral de ambos os criar e implantar as fases, como um validação do atividade e saída das referidas fases - mesmo que utiliza diferentes ambientes e pessoal. Teste em fase de desenvolvimento concentra-se em saber se o pedido preenche sua funcionalidade e especificações de gerenciamento. Muitas vezes, a distinção entre uma e desenvolvimento ambiente de teste. O ambiente de teste permite testar a combinação da aplicação e do modelo operacional. O teste é coberto na publicação Transição de Serviço ITIL. Para o software comprado, isso vai envolver a compra real da aplicação, qualquer exigido middleware eo relacionado ao hardware e equipamentos de rede. Qualquer personalização que é necessária terá de ser feita aqui, como se verá a criação de tabelas, categorias, etc, que irá ser utilizado. Isto é feito muitas vezes como um piloto implementação pelo relevante Aplicação de Gestão de equipe ou departamento. 6.5.4.4 Implantar Nesta fase, tanto a operacional modelo e a aplicação são implantados. O modelo operativo é incorporado no ambiente de TI existente e a aplicação é instalada na parte superior do modelo de operação, utilizando o Gerenciamento de Liberação e Implantação processo descrito na ITIL Transição de Serviço publicação. Teste também acontece durante esta fase, embora aqui a ênfase está em garantir que o processo de implantação e os mecanismos de trabalhar de forma eficaz, por exemplo, testar se o aplicativo ainda funçãos para especificação ITIL V3 - Operação de Serviço - Página: 254 de 423
    • depois de ter sido baixado e instalado. Isto é conhecido como Life Support cedo e cobre um período de garantia pré-definido que a validação, testes e monitoramento de uma nova aplicação ou serviço durante esse período, ocorre. Suporte início da vida é abordada em detalhes na publicação Transição de Serviço. 6.5.4.5 Operar Na fase de operar, o De serviços de TIsorganização opera o aplicativo como parte da prestação de um serviço exigido pela empresa. O atuação de aplicação em relação ao serviço total é medido continuamente contra o Nível de Serviços e de negócios-chave motoristas. É importante distinguir que os aplicativos em si não equivale a um serviço. É comum em muitas organizações, para se referir a aplicações como 'serviços', no entanto, as aplicações são apenas um componente muitos dos necessários para fornecer uma serviço de negócio. A fase Operate não é exclusiva de aplicações e é discutido ao longo desta publicação, com uma lista mais detalhada das atividades mencionadas na seção 6.5.5 abaixo. 6.5.4.6 Otimizar No Otimizar fase, os resultados do nível de serviço atuação medições são medidos, analisados e tratados. Possíveis melhorias são discutidas e desenvolvimentos iniciado, se necessário. As duas estratégias principais nesta fase são para manter e / ou melhorar a Nível de Serviços e para baixar custar. Isso poderia levar a iteração no ciclo de vida ou à aposentadoria justificada de um aplicativo. Uma coisa importante a lembrar sobre o Aplicação de Gestão de Ciclo de Vida é que, uma vez que é circular, a mesma aplicação pode residir em diferentes fases do ciclo de vida, ao mesmo tempo. Por exemplo, quando o próximo versão de um aplicativo está sendo projetado, ea versão atual está sendo implantado, a versão anterior ainda pode ser em operação em partes de uma organização. Isto, obviamente, requer a versão forte, configuração e liberar controlar. Determinadas fases pode demorar mais ou parecem mais significativos do que outros, mas todos eles são cruciais. Cada aplicação tem de passar por todos eles, pelo menos, uma vez e, por causa da natureza circular do ciclo de vida, vai passar por um pouco mais do que uma vez. Esta abordagem também suporta iterativo abordagens de desenvolvimento, onde o software está sendo continuamente desenvolvidas em passos incrementais. Cada passo segue o ciclo de vida e que o aplicativo é construído em incrementos, com as prioridades de negócios como motorista. ITIL V3 - Operação de Serviço - Página: 255 de 423
    • Uma boa comunicação é a chave como um aplicativo funciona seu caminho através das fases do ciclo de vida. É crítico que a altaqualidade informação é repassada por aqueles lidar com a aplicação em uma fase da sua existência para aqueles que manipulam-lo na próxima fase. Também é importante que a organização monitora a qualidade do Lifecycle Management Application. Alterações no ciclo de vida, por exemplo, na forma de uma organização transfere as informações entre as diferentes fases, irá afectar a sua qualidade. Compreender as características de cada fase do ciclo de vida de gerenciamento de aplicativos é crucial para a melhoria da qualidade da totalidade. Métodos e ferramentas utilizadas em uma fase pode ter um impacto em outros, enquanto a optimização de uma fase pode sub-otimizar o todo. 6.5.5 Aplicação de Gestão de actividades de carácter genérico Enquanto a maioria Aplicação de Gestão de equipes ou departamentos são dedicados a específica aplicaçãos ou conjuntos de aplicativos, há uma série de actividades que têm em comum. Estes incluem: • Identificar o conhecimento ea experiência necessários para gerenciar e operar aplicações na entrega de De serviços de TIs. Este processo começa durante a Estratégia de Serviço fase, é expandido em detalhe em Design de Serviços e é realizado em Operação de Serviço. Contínuo avaliação e atualização destas competências são feitas durante Melhoria de Serviço Continuada. • Iniciando treinamento programas para desenvolver e refinar as habilidades no gerenciamento de aplicativos apropriado recursos e treinamento manter registros para estes recursos. • O recrutamento ou contratação recursos com habilidades que não podem ser desenvolvidas internamente, ou onde há pessoas suficientes para realizar as atividades de gestão necessárias Aplicação. • Concepção e execução de fim-usuário treinamento. O treinamento pode ser desenvolvido e entregue tanto pelo desenvolvimento de aplicativos ou grupos de gerenciamento de aplicativos, ou por um terceiro, Mas Aplicação de Gestão de é responsável por assegurar que o treinamento é realizado conforme o caso. • Insourcing para atividades específicas, onde as habilidades necessárias não estão disponíveis internamente ou no mercado aberto, ou onde ela é mais custo-eficiente para fazer isso. • Definição de padrãos utilizados no projeto de novas arquiteturas e participação na definição de aplicação arquiteturas durante os processos de estratégia de serviço. • Pesquisa e Desenvolvimento de soluções que podem ajudar a expandir o portfólio de serviços, ou que pode ser usado para simplificar ou automatizar Operações de TI, Reduzir custars ou aumentar os níveis de serviço de TI. ITIL V3 - Operação de Serviço - Página: 256 de 423
    • • Participação na concepção e construção de novos serviços. Todas as equipes ou departamentos Application Management irá contribuir para a concepção das normas técnicas Arquitetura e desempenho para serviços de TI. Além disso, eles também será responsável por especificar a operacional atividades necessárias para gerenciar as aplicações em uma base contínua. • Envolvimento em projetos, não só durante o projeto do Serviço de processo, Mas também para Melhoria de Serviço Continuada ou projetos operacionais, tais como atualizações do sistema operacional, servidor projetos de consolidação ou movimentos físicos. • Concepção e realização de testes para a funcionalidade, atuação e gerenciamento de serviços de TI (tendo em conta que o teste deve ser controlada e realizada por um laboratório independente - veja Transição de Serviço publicação). • Disponibilidade e Gerenciamento da Capacidade são dependentes de Gerenciamento de Aplicativos para contribuir para a concepção de aplicações para atender os níveis de serviço exigidas pela empresa. Isto significa que, modelagem e carga de trabalho previsão são muitas vezes feito em conjunto com técnicas e de gestão de aplicativos. • Assistência na avaliação risco, Identificando o serviço e críticas sistema dependências e definição e implementação de contramedidas. • Gestão de fornecedores. Muitos Aplicação de Gestão de departamentos ou grupos são os únicos que sabem exatamente o que é exigido de um fornecedor e como medir e gerenciá-los. Por esta razão, muitas organizações dependem de Gerenciamento de Aplicativos para gerenciar contratos com fornecedores de específico aplicaçãos. Se este for o caso, é importante para assegurar que estes relaçãos são gerenciados como parte do SLM processo. • Envolvimento na definição de Gestão de Eventos padrãos e, especialmente, na instrumentação de aplicações para a geração de significativa eventos. • Gerenciamento de Aplicativos como um função fornece o recursos que executam o Gerenciamento de Problemas processo. É a sua competência técnica e conhecimento que é usado para diagnosticar e resolver problemas. É também a sua relação com os vendedores que são usados para escalar e acompanhamento com as equipes de apoio de fornecedores ou departamentos. • Recursos de gerenciamento de aplicativos estarão envolvidos na definição de sistemas de codificação que são usados em Gestão de Incidentes e Problemas (Categorias por exemplo incidente). • Recursos de gerenciamento de aplicativos são utilizados para apoiar Gerenciamento de Problemas na validação e manutenção da BDEC conjunto com as equipes de desenvolvimento de aplicativos. • Gestão da Mudança depende do conhecimento técnico e experiência para avaliar as mudanças e muitas mudanças serão construídos por equipes de gerenciamento de aplicativos. ITIL V3 - Operação de Serviço - Página: 257 de 423
    • • Bem sucedido Gerenciamento de Liberação depende de envolvimento da equipe de gerenciamento de aplicativos. Na verdade, eles são freqüentemente a motoristas da Gerenciamento de Liberação processo para suas aplicações. • Aplicação de Gestão vai definir, gerir e manter atributos e os relacionamentos de IC aplicação no CMS. • Aplicação de Gestão está envolvido na Melhoria de Serviço Continuada processos, especialmente na identificação de oportunidades de melhoria e, em seguida, para ajudar a avaliar as soluções alternativas. • Aplicação de Gestão assegura que todo o sistema operacional e documentação está atualizada e devidamente utilizado. Isto inclui assegurar que todos os projeto, Gestão e usuário manuais estão em dia e concluir e que a equipe de gerenciamento de aplicativos e usuários estão familiarizados com seu conteúdo. • Colaboração com Gestão Técnica sobre a realização de Análise de necessidades de formação e manutenção de estoques de Habilidades. • Auxiliar de TI Gestão Financeira para identificar o custar do gerenciamento contínuo de aplicações. • Envolvimento na definição do operacional atividades realizadas como parte de TI Gestão de Operações. Muitos departamentos de aplicativos de gestão, grupos ou equipes também executam as atividades operacionais, como parte de um organização'S TI Gestão de Operações função. • Introduzidos e manutenção de, software configuração políticas. • Juntamente com as equipes de desenvolvimento de software, a definição e manutenção de documentação relacionada com as aplicações. Estes incluirão usuário manuais de administração e gestão de manuais, bem como quaisquer POPs necessários para gerenciar operacional aspectos da aplicação. Aplicação de Gestão de equipes ou departamentos serão necessários para todas as aplicações-chave. A natureza exata do papel irá variar, dependendo das aplicações sendo suportados, mas as responsabilidades genéricas são susceptíveis de incluir: • Terceiro nível de suporte de incidentes relacionados com a aplicação (s) coberto por essa equipe ou departamento • Envolvimento em operação teste planos e desenvolvimento questões • Rastreamento de bugs e aplicação de gerenciamento de patches (correções para codificação em casa código, transportes / patches para código de terceiros) • Envolvimento na operacionalidade aplicação e problemas de suporte, tais como erro projeto do código, erro de mensagens, gestão de eventos ganchos ITIL V3 - Operação de Serviço - Página: 258 de 423
    • • Aplicação dimensionamento e atuação, Volume métricos e etc testes de carga Este é em apoio de Capacidade e Gerenciamento de Disponibilidade processos • Envolvimento no desenvolvimento Solte Políticas • Identificação de melhorias para o software existente, tanto a partir de uma perspectiva de funcionalidade e capacidade de gerenciamento. 6.5.6 Aplicação de Gestão de organização Apesar de todos os departamentos Application Management, grupos ou equipes de atividades similares, cada aplicação ou conjunto de aplicações tem um conjunto diferente de gestão e operacionais exigências. Os exemplos de tais diferenças incluem: • A finalidade da aplicação. Cada aplicativo foi desenvolvido para atender um conjunto específico de objetivos, normalmente objetivo de negócios. Para apoio efetivo e melhoria, o grupo que gerencia esse aplicativo precisa ter uma compreensão abrangente do contexto dos negócios e como o aplicativo é utilizado para atender seus objetivos. Isso é muitas vezes conseguida por analistas de negócios que estão perto de o negócio e responsável por garantir que o negócio exigências se traduzirem em aplicação especificaçãos. Analistas de Negócios deveriam reconhecer que o negócio exigências deve ser traduzida em funcional e capacidade de gerenciamento especificaçãos. • A funcionalidade da aplicação. Cada aplicativo foi projetado para trabalhar de uma forma diferente e para executar diferentes funçãos em momentos diferentes. • A plataforma em que o aplicativo é executado. Apesar de a plataforma ser geralmente administrado por uma Gestão Técnica equipe ou departamento, cada um deles afeta a maneira em que um aplicativo precisa ser administrada e explorada. • O tipo ou marca de tecnologia utilizada. Mesmo aplicações que têm funcionalidade semelhante operar de forma diferente em diferentes bancos de dados ou plataformas. Estas diferenças têm que ser entendidas no sentido de gerir a aplicação eficaz. Mesmo que as atividades para gerenciar esses aplicativos são genéricas, o cronograma específico de atividades ea forma como eles são realizados será diferente. Por esta razão, as equipes de Application Management e departamentos tendem a ser organizado de acordo com as categorias de aplicaçãos que suportam. Exemplos típicos de organizações de gestão de aplicações incluem: • Aplicações financeiras. Em organizações maiores onde um número de aplicações diferentes são usados para diferentes aspectos da Gestão Financeira, Pode haver vários departamentos, grupos ou equipas de ITIL V3 - Operação de Serviço - Página: 259 de 423
    • gestão dessas aplicações, por exemplo, Devedores e Credores e análise da idade, General Ledger, etc • Aplicativos de mensagens e colaboração • Aplicações de RH • Fabricação aplicações de suporte • Automação da força de vendas • Vendas de processamento de aplicações de ordem • Call center e aplicações de marketing • Empresas aplicativos específicos (por exemplo, cuidados de saúde, seguros, banca, etc) • Aplicações de TI, tais como Service Desk, Enterprise Sistema de Gestão de, Etc • Portais web • Compras on-line. ITIL V3 - Operação de Serviço - Página: 260 de 423
    • 6.5.6.1 papéis organizacionais Tradicionalmente, as equipes de desenvolvimento de aplicativos e Gestão e departamentos foram unidades autônomas. Cada um gere a sua própria ambiente à sua maneira e cada um tem uma interface separada para o negócio. Isto está ilustrado na Tabela 6.2. Desenvolvimento de Aplicações Aplicação de Gestão de Foco principal Funcionalidade de construção para a sua cliente. O que o aplicativo faz é mais importante para eles do que como ele é operado Concentre-se no que a funcionalidade é bem como a forma de entregá-lo. Aspectos de gerenciamento da aplicação, ou seja, como garantir a estabilidade e atuação da aplicação Modo de gestão A maioria desenvolvimento o trabalho é feito em projetos, onde o foco está em fornecer unidades específicas de trabalho para especificação, No prazo e dentro orçamento. Isto significa que muitas vezes é difícil para os desenvolvedores a entender e construir para as operações em curso, especialmente porque eles não estão disponíveis para apoio do pedido, uma vez que se mudaram para o próximo projeto Maioria do trabalho é feito como parte de repetíveis e processos em andamento. Um número relativamente pequeno de pessoas trabalham em projetos. Isto significa que é muito difícil para operacional pessoal para se envolver em projetos de desenvolvimento, como que os leva longe de seus "empregos reais" Medição Funcionários são recompensados para a criatividade e para concluir um projeto para que eles possam passar para a próxima projeto Funcionários são recompensados de coerência e de prevenção inesperado eventos e funcionalidade não autorizada ("sinos e assobios", por exemplo adicionado por desenvolvedores) Custar Projetos de desenvolvimento são relativamente fáceis de quantificar uma vez que o recursos são conhecidos e é fácil de vincular suas despesas para um determinado aplicação ou De serviços de TI Gerenciamento contínuo custars são muitas vezes misturados com os custos de outros serviços de TI desde recursos são muitas vezes compartilhados entre vários serviços de TI e aplicações Ciclo de Vidas Foco de desenvolvimento pessoal em ciclos de vida de desenvolvimento de software, que destacam as dependências para sucesso operação, Mas não atribuir a responsabilidade por estes Pessoal envolvido na gestão em curso normalmente só controlar uma ou duas fases destes ciclo de vidas - Operação e Melhoria Tabela 6.2 papéis organizacionais Ao longo dos últimos anos, estes dois mundos estão sendo reunidos por movimentos recentes para Object Oriented abordagens e SOA, juntamente com a pressão crescente do negócio a ser mais ágil e fácil de trabalhar. ITIL V3 - Operação de Serviço - Página: 261 de 423
    • Isto significa que o desenvolvimento de aplicativos terá uma maior responsabilidade para o bom funcionamento de aplicativos que projeto, Enquanto Aplicação de Gestão de terá um maior envolvimento na desenvolvimento de aplicações. Isto não muda a fundamental papel de cada grupo, mas requer uma abordagem mais integrada do SLC. Isso também significa que a saída de Desenvolvimento de Aplicativos será mais comoditizado e que Gerenciamento de Aplicativos será mais envolvidos em projetos de desenvolvimento. Isso exigirá as seguintes alterações: • Uma única interface para o negócio para todas as fases do ciclo de vida e uma comum exigências e especificação-Definição processo. • A mudança na forma como ambos Desenvolvimento e Gestão de pessoal são medidos. As equipes de desenvolvimento deve ser realizada, em parte, responsáveis por falhas de projeto que criam operacional interrupções. Equipe de gestão deve ser realizada, em parte, responsável pela contribuição para o técnico arquitetura eo projeto de gerenciamento de aplicações. • Uma única Gestão da Mudança processo para ambos os grupos, com controle de mudanças em cada grupo sendo subordinado à autoridade geral de Gestão de Mudança (veja Transição de Serviço publicação). • Um mapeamento claro de Desenvolvimento e Gestão de atividades do ciclo de vida, que é ilustrado em um alto nível na Figura 6.5. As atividades exatas e como eles interagem deve ser definido em cada organização, Embora alguns genérico diretrizs são dadas em cada um dos ITIL publicações. • Maior foco na integração de funcionalidade e capacidade de gerenciamento exigências no início do projeto. ITIL V3 - Operação de Serviço - Página: 262 de 423
    • Figura 6.6 Papel das equipes na aplicação de gestão do ciclo de vida A Figura 6.6 mostra uma comum Aplicação de Gestão de Ciclo de Vida com a participação de ambos os grupos. Neste diagrama, é evidente que Aplicação Desenvolvimento estará dirigindo algumas fases com a entrada de Gerenciamento de Aplicativos. Em outros casos, Gerenciamento de Aplicativos será a condução da fase com a entrada e apoio de desenvolvimento de aplicativos. Ambos os grupos são subordinados ao TI Estratégia de Serviço do organização e seus esforços são coordenados através Transição de Serviço mecanismos e processos. 6.5.7 Aplicação funções de gerenciamento e responsabilidades 6.5.7.1 Aplicações Gerentes / ou chefes de equipa Um Applications Manager ou líder de equipe (dependendo do tamanho e / ou importância da equipe ou departamento e da aplicação que suportam, e ITIL V3 - Operação de Serviço - Página: 263 de 423
    • estrutura da organização e cultura) Serão necessários para cada uma das equipas aplicações ou departamentos. O papel irá: • Assumir a responsabilidade total para a liderança, controlar e tomada de decisão para a equipe de aplicações ou departamento • Fornecer conhecimento técnico e liderança nas atividades específicas de aplicações de apoio abrangidos pela equipe ou departamento • Garantir níveis técnicos necessários sensibilização, formação e experiência são mantidos dentro da equipe ou departamento relevante para os aplicativos que estão sendo apoiados e processos que estão sendo usados • Envolvem a comunicação permanente com usuários e clientes em relação à aplicação atuação e em evolução exigências do negócio • Relatar à alta administração sobre todas as questões relevantes para os aplicativos que estão sendo apoiados • Executar linha de gestão para toda a equipe ou membros do departamento. 6.5.7.2 Aplicações Analista / Arquiteto Analistas aplicativos e arquitetos são responsáveis por correspondência requisitos para aplicação especificaçãos. Atividades específicas incluem: • Trabalhando com usuários, patrocinadores e todos os outros das partes interessadass para determinar suas necessidades em evolução • Trabalhando com Gestão Técnica para determinar o nível máximo de sistema requisitos necessários para cumprir os requisitos de negócios dentro orçamento e limitações tecnológicas • Execução de análises custo-benefício para determinar os meios mais adequados para atender a exigência declarada • Em desenvolvimento Operacional Modelos que vai garantir uma utilização óptima dos recursos e o nível apropriado de desempenho • Garantindo que os aplicativos são projetados para ser gerido de forma eficaz dada a tecnologia da organização arquitetura, Habilidades e ferramentas disponíveis • Desenvolvimento e manutenção de padrãos para aplicação dimensionamento,atuação modelagem, Etc • Gerando um conjunto de aceitação teste exigências, em conjunto com os designers, engenheiros de teste e os usuário, Que determinam que todos os requisitos de alto nível foram cumpridos relativamente à funcional e capacidade de gerenciamento • Entrada para o projeto de configuração dados necessários para gerenciar e rastrear o aplicação eficazmente. ITIL V3 - Operação de Serviço - Página: 264 de 423
    • Um número apropriado de analistas de aplicação serão necessários para cada uma das equipes Application Management ou departamento para realizar as atividades genéricas descritas no parágrafo 6.5.5. As formas em que Aplicação de Gestão de grupos podem ser organizados, e as opções disponíveis, são discutidos em detalhe na seção 6.7 abaixo. 6.5.8 Gestão de métricas de aplicação Métricos para Gerenciamento de Aplicativos dependerá em grande parte os aplicativos que estão sendo gerenciados, mas algumas métricas genéricas incluem: • Medição de resultados acordados. Estas podem incluir: • Capacidade dos usuários de acessar o aplicativo e sua funcionalidade • Relatórios e arquivos são transmitidos para os usuários • Transação taxas e disponibilidade para operações críticas de negócios • Service Desk treinamento • Gravação problema resoluçãos para o BDEC • Medidas de usuário do qualidade de saídas, tal como definidos no SLA. • Métricas de processo. Gestão Técnica equipes de executar Serviço de Gerenciamento de muitos processo actividades. A sua capacidade de fazê-lo será medida como parte do processo métricas se for o caso (ver secção sobre cada processo para mais detalhes). Os exemplos incluem: • O tempo de resposta para eventos e as taxas de conclusão do evento • Incidente resolução vezes por segundo e terceira linha de apoio • Resolução de problemas estatísticas • Número de escaladas e razão para as escalações • Número de mudanças implementadas e saiu • Número de alterações não autorizadas detectado • Número de liberars implantado, total e bem sucedida, incluindo a garantia de adesão às Políticas lançamento do organização • Questões de segurança detectados e resolvidos • Real sistema utilização contra Plano de capacidade previsões (onde a equipe tem contribuído para a desenvolvimento do plano) • Rastreamento contra PIS • Despesas contra orçamento. • Aplicação atuação. Estes métricos são baseados Design de Serviços especificaçãos e desempenho técnico padrãos definir por fornecedores e normalmente será contida OLAs ou SOPs. Métricas reais variam de acordo com a aplicação, mas é provável que incluem: • O tempo de respostas ITIL V3 - Operação de Serviço - Página: 265 de 423
    • • Aplicação disponibilidade, Que é útil para medir a equipe ou aplicação desempenho, mas não deve ser confundido com disponibilidade de serviço - o que requer a capacidade para medir a disponibilidade geral do serviço, e pode utilizar os dados de disponibilidade para um número de indivíduos sistemas ou componentes • Integridade de dados e relatórios. • Medição de manutenção atividade, Incluindo: • Manutenção realizada por horário • Número de janelas de manutenção ultrapassado • Manutenção objetivos alcançado (número e porcentagem). • Aplicação de Gestão de equipes são propensos a trabalhar em estreita colaboração com as equipes de desenvolvimento de aplicativos em projetos, E as métricas apropriadas devem ser usados para medir esta, incluindo: • Tempo gasto em projetos • Cliente e usuário satisfação com a saída do projecto • Custo de participação no projeto. • Treinamento e desenvolvimento de competências. Essas métricas garantir que a equipe tem as habilidades e treinamento para gerenciar a tecnologia que está sob a sua controlar, E também identificar as áreas em que a formação ainda é necessária. 6.5.9 documentação Gerenciamento de Aplicativos Um certo número de documentos são produzidos e utilizados durante Gerenciamento de Aplicativos. Esta lista é um resumo de alguns dos mais importantes e não inclui relatórios ou documentos que são produzidos por Gerenciamento de Aplicativos em nome de outro processo ou funçãos (por exemplo, RFC, Erro Conhecido documentação, Registro de Lançamentos, etc.) Note que os documentos devem ser controladas como IC e relacionado com as aplicações relevantes ou equipes de gerenciamento de aplicativos. 6.5.9.1 Application Portfolio O Application Portfolio é usado primariamente como parte de Estratégia de Serviço, Mas é referenciado aqui para ser completo. O portfólio de aplicativos é uma lista (mais precisamente um sistema ou banco de dados) de todos os aplicativos em uso dentro do organização, Em conjunto com as seguintes informações: Chave atributos da aplicação • Clientes e os utilizadores • Finalidade comercial • Nível de importância do negócio ITIL V3 - Operação de Serviço - Página: 266 de 423
    • • Arquitetura (Incluído o Infraestrutura de TI dependências) • Desenvolvedores, grupo de apoios, fornecedors ou fornecedores • O investimento feito no aplicação até o momento. A este respeito, a carteira de aplicações pode ser utilizada como um ativos registo para as aplicações, O objetivo do portfólio de aplicativos é analisar a necessidade eo uso de aplicações no organização. Ele pode ser usado para ligar a funcionalidade e de investimento para negócios atividade e é, portanto, uma parte importante do curso de TI planejamento e controlar. Outro benefício da Carteira de aplicação é que ele pode ser usado para identificar a duplicação e licenciamento excessivo de aplicações. A Carteira de Aplicação faz parte do total De serviços de TI Carteira, que é discutida em detalhe na Estratégia de Serviço publicação. O portfólio de aplicativos e do Catálogo de Serviços A Carteira do aplicativo não deve ser confundido com o Catálogo de Serviço e não deve ser anunciado como uma lista de serviços para clientes ou usuários. Os aplicativos são um dos componentes usado para fornecer serviços de TI, geralmente não os serviço si. O portfólio de aplicativos deve, portanto, ser usado como um documento de planejamento apenas pelos gerentes e funcionários que estão envolvidos com o desenvolvimento e gestão da estratégia de TI da organização, bem como a equipe de TI, que têm a tarefa de gerir as aplicações ou as plataformas em que os aplicativos são executados. O Catálogo de Serviços deve se concentrar em listar os serviços que estão disponíveis, em vez de simplesmente listar aplicações e assumindo que os usuários e clientes podem fazer a ligação. Dito isto, há momentos em que a aplicação é sinônimo de serviço, por exemplo de processamento de aplicativos são normalmente conhecido por seu nome, um pedido de serviço de hospedagem irá mencionar os nomes dos hospedado aplicação, etc 6.5.9.2 Requisitos da Aplicação Há dois conjuntos de documentos que contêm exigências para aplicações: • Requisitos de Negócio delinear o Business Case para a aplicação desejada, em outras palavras, o que a empresa vai fazer com a aplicação. Isso irá incluir o retorno sobre o investimento para a aplicação, bem como todas as melhorias relacionadas ao negócio. Requisitos de negócios também incluem a Exigência de Nível de Serviços, tal como definido pelos clientes e utilizadores de serviços. ITIL V3 - Operação de Serviço - Página: 267 de 423
    • • Requisitos da Aplicação documentos baseiam-se nos requisitos de negócio e especificar exatamente como a aplicação irá atender a esses requisitos. Em resumo, os documentos de requisitos de aplicação reunir informações que serão utilizadas para nova comissão aplicaçãos ou alterações nos aplicativos existentes, por exemplo: • Para projeto o arquitetura da aplicação (especificação dos diferentes componentes da sistema, Como eles se relacionam entre si e como eles serão geridos) • Para especificar uma Request for Proposal (RFP) para um Comercial Off the Shelf (COTS) aplicação • Para iniciar o projeto e construção de uma aplicação em casa. Requisitos documentos são normalmente de propriedade de um projeto líder, ou de um desenvolvimento equipe do projeto, ou para uma equipe de elaboração das especificações para uma RFP. Exigênciadocumentos s estão sujeitos a documento controlar para o projeto, que fazem parte do total escopo do projeto. Quatro tipos diferentes de Aplicação Exigências precisam ser definidos (para informações mais detalhadas, por favor consulte o ITIL Design de Serviços e Transição de Serviço publicações): • Requisitos Funcionais descrever as coisas de um pedido se destina a fazer, e pode ser expressa como serviços, tarefas ou funçãos a aplicação é necessário para executar. • Requisitos de gerenciamento são usados para definir o que é necessário para gerenciar a aplicação ou para garantir que ele executa as funções necessárias de forma consistente e no nível certo. Capacidade de gerenciamento também identificar constrangimentos de TI sistema. Estes requisitos de servir como base para o dimensionamento do sistema inicial e estimativas de custar, E pode apoiar o avaliação da viabilidade do sistema de TI proposto. Mais importante, eles dirigem projeto do operacional modelos e atuação padrãos utilizado em TI Gestão de Operações. • Usabilidade Requisitos são normalmente especificados pelo usuários do pedido, e referem-se a sua facilidade de uso. Quaisquer requisitos especiais para usuários com deficiência também precisam ser especificados aqui. • Requisitos de Teste especificar o que é necessário para assegurar que o teste ambiente é representativa do ambiente operacional, e que o teste é válido (ou seja, que realmente testa o que é suposto). 6.5.9.3 mudanças de uso e Casos Use e Caso alteres são gerenciados como parte do projeto do Serviço e Melhoria de Serviço Continuada processos, mas são mantidas pela Aplicação de ITIL V3 - Operação de Serviço - Página: 268 de 423
    • Gestão de. Para o software comprado, é comum para a equipe que desenvolve as especificações funcionais para manter a Caso de Uso para essa aplicação. • Casos de Uso documentar o uso pretendido do aplicativo com cenários da vida real para demonstrar seus limites e as suas funcionalidades. Casos de uso podem também ser usados como modelagem e dimensionamento cenários e para facilitar a comunicação entre usuários, desenvolvedores e pessoal de Gerenciamento de Aplicativos. • Alterar Casos usar cenários para prever o impacto de possíveis mudanças na arquitetura, utilização ou funcionalidade e projeto o impacto do específico mudar cenários. Casos de Mudança são usadas para esclarecer escopo ea direção com o patrocinador. Arquitetura extra e trabalho de design será necessária neste momento para garantir a Caso alteres podem ser atendidas no futuro a razoável custar. O patrocinador deve estar preparado para pagar o custo extra. Se não, os Casos de Mudança deve ser reduzida para que o patrocinador está preparado para pagar. Casos de Mudança também são utilizados para avaliar a arquitetura. Eles influenciam a desenvolvimento processo permitindo o projeto da apropriadas características arquitetônicas para minimizar o impacto de mudanças futuras. Para mais informações, consulte o ITIL Design de Serviços e Melhoria de Serviço Continuada publicações. 6.5.9.4 documentação de projeto Este não é um específico documento, Mas refere-se a qualquer documento produzido pelo desenvolvimento de aplicativos ou a equipe de gerenciamento que especifica como uma aplicação será construído. Como esses documentos geralmente são possuídos e geridos por equipes de desenvolvimento, esta publicação não cobri-los em detalhe. No entanto, para assegurar o êxito operação, Gerenciamento de Aplicativos deve assegurar que a documentação projeto contém: • Dimensionamento especificaçãos • Workload perfis e as previsões de utilização • Técnico de Arquitetura • Dados modelos • Codificação padrãos • Os padrões de desempenho • Software Gerenciamento da Configuração definições • Ambiente definições e considerações de construção (se for o caso). Para aplicações COTS, estes documentos assumir a forma de aplicação Especificaçãos que são utilizados como entrada para a escrita de RFPs. Nestes ITIL V3 - Operação de Serviço - Página: 269 de 423
    • casos, os documentos são de propriedade e gerido pela Aplicação de Gestão de. Para mais informações sobre documentação de projeto, consulte a publicação Projeto ITIL Service. 6.5.9.5 Manuais Application Management é responsável pela gestão de manuais para todas as aplicações. Embora estes são normalmente desenvolvidas pelas equipes de desenvolvimento de aplicativos ou terceiro fornecedors, Gerenciamento de Aplicativos é responsável por garantir que os manuais são relevantes para a operacional versãos das aplicações. Três tipos de manuais são geralmente mantidas pela Administração Aplicação: • Manuais de design contêm informações sobre a estrutura e arquitetura do aplicativo. Estes são úteis para a criação de relatórios ou a definição evento regras de correlação. Eles também podem ajudar no diagnóstico problemas. • Manuais de administração ou de direcção descrever as atividades necessárias para manter e operar a aplicação nos níveis de atuação especificada na fase de projeto. Estes manuais também irá fornecer solução de problemas detalhada, Erro Conhecido e descrições de falhas, e passo-a-passo as instruções para tarefas comuns de manutenção. • Manuais de usuário descrever a funcionalidade do aplicativo, uma vez que é usado por um fim-usuário. Estes manuais contêm passo-a-passo sobre como usar o aplicação, Bem como descrições do que normalmente deve ser inserido em determinados campos, ou o que fazer se houver uma erro. Manuais e Procedimento Operacional Padrãos Manuais não deve ser vista como um substituto para PHF, mas como entrada para os PON. Os POPs devem conter todos os aspectos de aplicações que precisam ser gerenciados como parte das operações normais. Se eles não são extraídos dos manuais, existe uma grande probabilidade de que eles serão ignorados ou realizados de uma forma não-padrão. Aplicação de Gestão de deve garantir que tais instruções são extraídas dos manuais e inserido documentação SOP separado para Operações. Também é responsável por garantir que estas instruções são atualizados a cada mudar ou novos liberar do software. ITIL V3 - Operação de Serviço - Página: 270 de 423
    • 6,6 Serviço de Operação papéis e responsabilidades A chave para ITSM eficiente é assegurar que há uma responsabilidade clara e papéis definidos para efectuar a prática de Operação de Serviço. Um papel é muitas vezes ligada a um descrição do trabalho ou trabalhar descrição do grupo, mas não necessariamente precisa ser preenchido por um indivíduo. O tamanho de um organização, Como ela está estruturada, a existência de parceiros externos e outros fatores influenciam como os papéis são atribuídos. Se uma determinada função é preenchida por um único indivíduo ou compartilhadas entre dois ou mais, o importante é a consistência da prestação de contas e execução, juntamente com a interação com outras funções na organização. 6.6.1 Posto de Serviço papéis As funções que se seguem são necessários para o Service Desk. 6.6.1.1 Service Desk Manager Em organizações maiores onde o atendimento é de dimensão significativa, um serviço de função Desk Manager pode ser justificada com o Supervisor de Service Desk (s) reportar a ele ou ela. Em tais casos, esse papel pode assumir a responsabilidade por algumas das atividades listadas acima, e pode ainda realizar as seguintes atividades: • Gerenciar as atividades secretária geral, incluindo os supervisores • Atuar como mais um escalada ponto para o supervisor (s) • Assumir uma maior cliente-Serviços de papel • Relatório para gerentes seniores em qualquer problema que poderia significativamente impacto o negócio • Assistir Alterar Conselho Consultivo reuniões • Assumir total responsabilidade pelas incidente e Solicitação de Serviço manipulação no Service Desk. Isto também pode ser expandido para qualquer outra atividade assumida pelo Service Desk - por exemplo monitoramento certas classes de evento. Nota: Em todos os casos, claramente definida descrição do trabalhos deve ser elaborado e acordado para que responsabilidades específicas são conhecidos. 6.6.1.2 Supervisor de Service Desk Em mesas muito pequenas, é possível que o idoso Service Desk Analista também vai atuar como Supervisor - mas em mesas maiores, é provável que um Supervisor de Posto de Serviço dedicado papel será necessário. Onde deslocar horas ditam, pode haver dois ou mais pós-titulares que cumprem o papel, geralmente em uma base de sobreposição. O papel do supervisor é provável que incluem: ITIL V3 - Operação de Serviço - Página: 271 de 423
    • • A garantia de que os níveis de pessoal e habilidade são mantidas ao longo operacional horas de gestão deslocar horários de pessoal, etc • Realização de atividades de RH como necessário • Atuando como um escalada apontar onde as chamadas difíceis ou controversas são recebidos • Produção de estatísticas e relatórios gerenciais • Representando o Service Desk em reuniões • Organizando formação e sessões de sensibilização • Ligação com a gerência sênior • Ligação com Gestão da Mudança • Realizar briefings para equipe de Service Desk em mudanças ou desenvolvimentos que podem afetar volumes no Service Desk • Auxiliar analistas no fornecimento suporte de primeira linha quando carga de trabalhos são elevados, ou em que a experiência adicional é necessária. 6.6.1.3 Posto de Serviço Analistas O principal papel do Analista de Serviço de Recepção é o de fornecer suporte de primeiro nível através da adopção de chamadas e lidar com os incidentes resultantes ou Solicitação de Serviços usando o Relatório de Incidentes e Cumprimento de Requisição processos, em conformidade com a objetivos descritas anteriormente. O número exato de funcionários requerida é discutida no ponto 6.2.4.1. 6.6.1.4 Superusuários Super Users são discutidos em detalhes na seção de pessoal Service Desk no ponto 6.2.4. Em resumo, este papel será, de negócio usuários que atuam como pontos de ligação com TI em geral e do Service Desk, em particular. O papel do Superusuário pode ser resumido como se segue: • Para facilitar a comunicação entre a TI e os negócios a nível operacional • Para reforçar expectativas dos usuários em relação ao que Nível de Serviços foram acordados • Formação de pessoal para os usuários em sua área • Fornecendo suporte para incidentes menores ou no cumprimento simples pedido • Envolvimento com o novo liberars e lançamentos. 6.6.2 Técnicas funções de gerenciamento A seguir papels são necessários no Gestão Técnica áreas 6.6.2.1 Os gerentes técnicos / ou chefes de equipa ITIL V3 - Operação de Serviço - Página: 272 de 423
    • A Gerente Técnico ou líder de equipe (dependendo do tamanho e / ou importância da equipe e do organizaçãoEstrutura 's e cultura) Pode ser necessário para cada uma das equipas técnicas ou departamentos. O papel vai: • Assumir a responsabilidade total para a liderança, controlar e tomada de decisão para a equipe técnica ou do departamento • Fornecer conhecimento técnico e liderança nas áreas técnicas específicas abrangidas pela equipe ou departamento • Garantir níveis técnicos necessários sensibilização, formação e experiência são mantidos dentro da equipe ou departamento • Relatório para a gerência sênior em todas as questões técnicas relevantes para a sua área de responsabilidade • Executar linha de gestão para toda a equipe ou membros do departamento. 6.6.2.2 Os analistas técnicos / Arquitetos Este termo refere-se a qualquer membro da equipe de Gestão Técnica, que realiza as atividades enumeradas no parágrafo 6.3.3, excluindo o dia operacional ações, que são realizadas por operadores em qualquer técnica ou TI Gestão de Operações. Com base na lista de atividades genéricos no ponto 6.3.3, o papel dos Analistas Técnicos e Arquitetos inclui: • Trabalhando com usuários, patrocinadores, Aplicação de Gestão de e todos os outros das partes interessadass para determinar suas necessidades em evolução • Trabalhando com o Gerenciamento de Aplicativos e outras áreas de Gestão Técnica para determinar o nível mais alto de sistema exigências necessárias para cumprir as exigências dentro orçamento e limitações tecnológicas • Definir e manter o conhecimento sobre como os sistemas estão relacionados e garantir que as dependências são compreendidos e geridos de acordo • Execução de análises custo-benefício para determinar os meios mais adequados para atender aos requisitos estabelecidos • Desenvolver Operacional Modelos que vai garantir uma utilização óptima dos recursos e o nível apropriado de atuação • Garantir que a infra-estrutura está configurado para ser gerido de forma eficaz dada a tecnologia da organização arquitetura, Habilidades e ferramentas disponíveis • Garantir o desempenho consistente e confiável da infra-estrutura para entregar o nível de serviço necessário para o negócio • Definir todas as tarefas necessárias para gerenciar a infra-estrutura e garantir que essas tarefas são realizadas de forma adequada • Entrada para o projeto de configuração dados necessários para gerenciar e controlar a aplicação eficaz. ITIL V3 - Operação de Serviço - Página: 273 de 423
    • As formas em que Gestão Técnica podem ser organizados, e as opções disponíveis, são discutidos em detalhe na seção 6.7. 6.6.2.3 Operador Técnico Este termo é usado para se referir a qualquer agente que exerce no dia-a-dia operacional tarefas na gestão técnica. Normalmente, essas tarefas são delegadas a um dedicado Operações de TI equipe, e isso papel é, portanto, discutido no parágrafo 6.6.3.4 Operadores de TI. 6.6.3 Operações de TI funções de gerenciamento As seguintes funções e necessárias no TI Gestão de Operações área: 6.6.3.1 TI Gerente de Operações Um gerente de operações de TI serão necessários para assumir total responsabilidade por toda a TI Gestão de Operações atividades, que incluem: • Operações de controle, Que supervisiona a execução e monitoramento das atividades operacionais no Infraestrutura de TI. Isto pode ser feito com o auxílio de um Operações Ponte ou Centro de Operações de Rede. Além de executar as tarefas de rotina de todas as áreas técnicas, Controle de Operações também executa as seguintes tarefas específicas: • Console de Gerenciamento de, Que se refere à definição de observação central e monitoramento capacidade e em seguida, usando os consoles para exercer o acompanhamento e controlar atividades • Job Scheduling, Ou a gestão de trabalhos em lote de rotina ou scripts • Faça backup e Restaurar em nome de todos os técnicos e equipes de gerenciamento de aplicativos ou departamento e, muitas vezes, em nome da usuários • De impressão e gestão de saída para a recolha e distribuição de toda a impressão centralizada ou saída eletrônica. • Gestão de Instalações, Que se refere à gestão da TI física ambiente, Normalmente um Centro de Dados ou salas de informática e recuperação locais, juntamente com toda a potência e equipamentos de refrigeração. Facilities Management também inclui a coordenação de grande escala de consolidação projetos, por exemplo, consolidação de data centers ou servidor projetos de consolidação. Em alguns casos, a gestão de um Centro de Dados é terceirizado, no qual Facilities Management caso refere-se à gestão do terceirização contrato. O papel do Operações de TI Gerente é: ITIL V3 - Operação de Serviço - Página: 274 de 423
    • • Fornecer liderança geral, controle e tomada de decisões e assumir a responsabilidade pelas equipes de TI e departamento de Gestão de Operações • Relatório para a gerência sênior em todas as questões de TI Operações • Executar linha de gestão para todos Operações de TI equipe ou departamento gerentes / supervisores. 6.6.3.2 Líderes Turno Muitas áreas de TI Operações irá trabalhar horas extras - em cada um de dois ou trêsdeslocar base. Em tais casos, uma deslocar líder será necessário em cada um dos turnos, para executar as seguintes atividades: • Assumir a responsabilidade total para a liderança, controlar e tomada de decisões durante o período de mudança • Garantir que todas as operacional atividades são realizadas de forma satisfatória dentro de prazos acordados, e de acordo com as políticas da empresa e procedimentos • Cooperar com o chefe de turno outro (s) para assegurar entrega, continuidade e coerência entre os turnos • Atuar como gerente de linha para todos os Analistas de Operações em seu / sua mudança • Assumir a saúde geral e a segurança, e segurança responsabilidade para a mudança (a menos que especificamente designada para outros membros da equipe). 6.6.3.3 Operações de TI Analistas Analistas de TI são Operações de TI sênior equipe de operações que são capazes de determinar a maneira mais eficaz e eficiente para realizar uma série de operações, geralmente em alto volume, diversificada ambientes. Este papel normalmente é realizada como parte de Gestão Técnica, Mas grandes organizações podem achar que o volume ea diversidade de atividades operacionais requer um pouco mais de profundidade em planejamento e execução. Exemplos incluem Job Scheduling e a definição de uma cópia de segurança estratégia e agendar. 6.6.3.4 Operadores de TI Operadores de TI são os funcionários que realizam as atividades do dia-a-dia operacionais que são definidas no Técnico ou Aplicação de Gestão de e, em alguns casos, operações de TI analistas. Operador papéis típicos incluem: • Executando apoios ITIL V3 - Operação de Serviço - Página: 275 de 423
    • • Operações do console, ou seja, monitoramento o estado de sistemas específicos, filas de emprego, etc, e dando o primeiro nível de intervenção, se apropriado • Gerenciando dispositivos de impressão, o repovoamento com papel, toner, etc • Garantir que os trabalhos em lote, arquivo, etc são realizadas • Executar trabalhos de casa programadas de manutenção, tais como manutenção de banco de dados, arquivo de limpeza, etc • Gravar imagens para a distribuição e instalação em novo servidors, desktops ou laptops • Instalação física do equipamento padrão no Centro de Dados. 6.6.4 Gestão funções de aplicativo 6.6.4.1 Aplicações Gerentes / ou chefes de equipa Um Applications Manager ou chefe de equipa deve ser considerado para cada um dos aplicaçãos equipes ou departamentos. O papel vai: • Assumir a responsabilidade total para a liderança, controlar e tomada de decisão para a equipe de aplicações ou departamento • Fornecer conhecimento técnico e liderança nas atividades específicas de aplicações de apoio abrangidos pela equipe ou departamento • Garantir níveis técnicos necessários sensibilização, formação e experiência são mantidos dentro da equipe ou departamento relevante para os aplicativos que estão sendo apoiados e processos que estão sendo usados • Envolvem a comunicação permanente com usuários e clientes em relação à aplicação atuação e em evolução exigências do negócio • Relatar à alta administração sobre todas as questões relevantes para os aplicativos que estão sendo apoiados • Executar linha de gestão para toda a equipe ou membros do departamento. 6.6.4.2 Aplicações Analista / Arquiteto Analistas aplicativos e arquitetos são responsáveis por correspondência requisitos para aplicação especificaçãos. Atividades específicas incluem: • Trabalhando com usuários, patrocinadores e todos os outros das partes interessadass para determinar suas necessidades em evolução • Trabalhando com Gestão Técnica para determinar o nível mais elevado de requisitos de sistema necessários para cumprir os requisitos dentro orçamento e limitações tecnológicas • Execução de análises custo-benefício para determinar os meios mais adequados para atender a exigência declarada ITIL V3 - Operação de Serviço - Página: 276 de 423
    • • Desenvolver Operacional Modelos que vai garantir uma utilização óptima dos recursos e o nível apropriado de desempenho • Garantir que aplicaçãos destinam-se a ser tratado eficazmente dado o organização"Tecnologia s arquitetura, Habilidades e ferramentas disponíveis • Desenvolvimento e manutenção de padrãos para aplicação dimensionamento, Desempenho modelagem, Etc • Gerando um conjunto de aceitação teste requisitos, juntamente com os designers, engenheiros de teste e para o utilizador, que determinam que todos os requisitos de alto nível foram cumpridos, tanto funcionais e capacidade de gerenciamento • Entrada para o projeto de configuração dados necessários para gerenciar e controlar a aplicação eficaz. Um número apropriado de analistas de aplicação serão necessários para cada um dos Aplicação de Gestão de equipes ou departamentos para realizar as atividades descritas no restante desta publicação, principalmente no ponto 6.5.5. As formas pelas quais os grupos de Gerenciamento de Aplicativos podem ser organizadas, e as opções disponíveis, são discutidos em detalhes na seção 6.7. 6.6.5 Gestão de papéis de Eventos É incomum para um organização a nomeação de um "gerente de eventos", como eventos tendem a ocorrer em vários contextos e por muitas razões diferentes. No entanto, é importante que Gestão de Eventos procedimentos são coordenadas para evitar a duplicação de esforços e ferramentas. O papels da Operação de Serviço funçãos em Gestão de Eventos são os seguintes. 6.6.5.1 O papel do Service Desk O Service Desk normalmente não é envolvido em Gestão de Eventos, como tal, a menos que um evento requer alguma resposta que esteja dentro do escopo do Service Desk é definido atividade, Por exemplo, a notificação de um usuário que um relatório está pronto. Geralmente, no entanto, este tipo de actividade é realizada pela Operações Ponte, A menos que o Service Desk e Operações Ponte foram combinados. A investigação e resolução de eventos que foram identificados como sendo Incidentes inicialmente será realizado pela Central de Serviços e, em seguida, encaminhado para a equipe apropriada Operação de Serviço (s) O Service Desk também é responsável pela comunicação de informações sobre este tipo de incidente para o técnico relevante ou Aplicação de Gestão de equipa e, se for o caso, o utilizador. ITIL V3 - Operação de Serviço - Página: 277 de 423
    • 6.6.5.2 O papel do Técnico e Gerenciamento de Aplicativos Técnica e Gerenciamento de Aplicativos desempenha vários papéis importantes, como segue: • Durante Design de Serviços, Eles vão participar da instrumentação do serviço, Classificar eventos, atualizar mecanismos de correlação e garantir que todas as respostas automáticas são definidas • Durante Transição de Serviço eles vão testar o serviço, para assegurar que os eventos são gerados adequadamente e que as respostas definidas são adequadas • Durante a Operação Serviço estas equipas normalmente executar o gerenciamento de eventos para o sistemas sob seu controle. É incomum para equipes de ter uma pessoa dedicada a gerenciar Gestão de Eventos, mas cada gerente ou chefe de equipa irá assegurar que os procedimentos adequados são definidas e executadas de acordo com a processo e política exigências • Técnica e Gerenciamento de Aplicativos também serão envolvidos em lidar com incidentes e problemas relacionados com eventos • Se as atividades de gestão de eventos são delegadas ao Posto de Serviço ou de TI Gestão de Operações, Técnica e Gerenciamento de Aplicativos deve garantir que os funcionários estão devidamente treinados e que têm acesso às ferramentas necessárias para que possam desempenhar essas tarefas. 6.6.5.3 O papel da TI Gestão de Operações Onde Operações de TI é separado de Gestão Técnica ou aplicativo, é comum para Monitoramento de Eventos e de primeira linha de resposta deve ser delegada a TI Gestão de Operações. Operadores para cada área terá a tarefa de monitoramento eventos, responder, conforme necessário, ou garantir que os incidentes são criados conforme o caso. As instruções de como fazê-lo deve ser incluído nos POPs para essas equipes. Monitoramento evento é delegada ao Operações Ponte onde ele existe. O Operações Ponte pode iniciar e coordenar, ou mesmo realizar, as respostas exigidas pelo serviço, ou fornecer suporte de primeiro nível para aqueles eventos, os quais geram incidente. 6.6.6 Gestão de Incidentes papéis A seguir papels são necessários para o Gerenciamento de Incidentes processo. 6.6.6.1 Gerente de Incidentes Um Gerente de Incidentes tem a responsabilidade de: ITIL V3 - Operação de Serviço - Página: 278 de 423
    • • Conduzir o eficiência e eficácia do Gerenciamento de Incidentes processo • Produtor gestão da informação • Gestão do trabalho do pessoal de apoio incidente (de primeira e segunda linha) • Acompanhamento da eficácia da Gestão de Incidentes e fazer recomendações para a melhoria • Desenvolvimento e manutenção do Gerenciamento de Incidentes sistemas • Gerenciando Incidente graves • Desenvolvimento e manutenção do Gerenciamento de Incidentes processo e procedimentos. Em muitas organizações a papel do Gerente de Incidentes é atribuído ao Supervisor de Service Desk - embora em grandes organizações com grandes volumes de papel separada pode ser necessária. Em ambos os casos, é importante que o Gestor de Incidentes é dada autoridade para gerir incidentes eficazmente através da linha de primeiro, segundo e terceiro. 6.6.6.2 Primeira linha Isto é coberto em detalhes no Service Desk (Secção 6.1) e não serão repetidas aqui. 6.6.6.3 de segunda linha Muitas organizações optam por ter um segunda linha de apoio grupo, composto de funcionários com maior (embora ainda geral) habilidades técnicas do que o Service Desk - e com mais tempo para se dedicar a incidente diagnóstico e resolução sem a interferência de interrupções telefônicas. Tal grupo pode lidar com muitos dos incidentes menos complicados, deixando mais especialista (terceira linha) grupo de apoios para se concentrar em lidar com mais profundas incidentes e / ou novos desenvolvimentos, etc Quando um grupo de segunda linha é usado, muitas vezes há vantagens de localizar este grupo próximo ao Posto de Serviço para ajudar com uma boa comunicação e facilitar circulação de pessoal entre os grupos, que podem ser úteis para a formação / sensibilização e durante períodos ocupados ou falta de pessoal. A gerente de suporte de segunda linha (ou supervisor, se apenas um pequeno grupo) normalmente dirigir este grupo. É concebível que este grupo pode ser terceirizado - e isso é mais provável e prático se o Service Desk si tem sido terceirizado. 6.6.6.4 Terceira linha ITIL V3 - Operação de Serviço - Página: 279 de 423
    • Terceira linha de apoio será proporcionada por um certo número de grupos técnicas e / ou de terceiros fornecedors / mantenedores. A lista irá variar de organização a organização, mas é provável que incluem: • Suporte de rede • Suporte de voz (se separar) • Servidor Apoiar • Suporte de mesa • Aplicação de Gestão de - Provável que pode haver grupos separados para diferentes aplicações ou aplicação tipos - alguns dos quais podem ser fornecedor externo / mantenedores. Em muitos casos, a mesma equipe será responsável pela aplicação Desenvolvimentos, bem como suporte - e, portanto, é importante que recursos são priorizadas para que o apoio é dado destaque adequada • Suporte de banco de dados • Manutenção engenheiros de hardware • Ambientais Mantenedores Equipamentos / Fornecedores. Nota: Dependendo de onde uma organização decide fonte seus serviços de apoio, qualquer um dos grupos acima referidos podem ser grupos internos ou externos. 6.6.7 A realização de papéis Pedido Tratamento inicial da Solicitação de Serviços será realizado pelo Service Desk e Gerenciamento de Incidentes pessoal. Eventual cumprimento do pedido será feita pela equipe apropriada Operação de Serviço (s) ou departamentos e / ou por fornecedores externos, conforme o caso. Muitas vezes, Gestão de Instalações, Procurement e outros negócios ajuda áreas no cumprimento da solicitação de serviço. Na maioria dos casos, não haverá necessidade de adicional papels ou posts para ser criado. Em casos excepcionais, em que um número muito elevado de solicitações de serviços são tratados, ou onde os pedidos são de fundamental importância para a organização, pode ser apropriado ter uma ou mais da equipe de Gerenciamento de Incidentes dedicado ao tratamento e gestão de solicitações de serviço. 6.6.8 Problema funções de gerenciamento As funções que se seguem são necessários para o Gerenciamento de Problemas processo. 6.6.8.1 Gestor Problema ITIL V3 - Operação de Serviço - Página: 280 de 423
    • Não deve ser uma pessoa designada (ou, em organizações maiores, uma equipe), responsável pela Gestão de Problemas. Organizações menores podem não ser capazes de justificar a tempo inteiro recurso para este papel, e pode ser combinado com outros papéis em tais casos, mas é essencial que não é apenas à esquerda para os recursos técnicos para executar. Não precisa ser um ponto único de coordenação e um proprietário de processo de Gerenciamento de Problema. Este papel será coordenar todas as atividades de Gerenciamento de Problemas e terá a responsabilidade, para: • Ligação com tudo problema resolução grupos para assegurar uma resolução rápida de problemas dentro SLA alvos • Propriedade e proteção do BDEC • Gatekeeper para a inclusão de todos Erro Conhecidos e de gestão dos algoritmos de busca • Formal fecho de todos Grave problemas • Ligação com fornecedors, empreiteiros, etc, para garantir que terceiros cumpram as suas obrigações contratuais, especialmente no que diz respeito à resolução de problemas e fornecendo informações de problemas relacionados e dados • Arranjar, execução, documentação e todas as atividades de acompanhamento relativo à grande problema Comentes. 6.6.8.2 resolução de problemas Grupos A resolução de problemas de real é susceptível de ser realizada por uma ou mais técnicas grupo de apoios e / ou fornecedores ou empreiteiros de apoio - sob a coordenação do Gestor de Problemas. Quando um problema individual é suficientemente grave para justificar, um dedicado gestão de problemas equipe deve ser formulado para trabalhar juntos para superar esse problema específico. O Gerente de problema tem uma papel a desempenhar para garantir que o número eo nível de recursos está disponível na equipe e para escalada e comunicação na cadeia de gestão de todas as organizações envolvidas. 6.6.9 Acesso funções de gerenciamento Desde Gerenciamento de Acesso é uma execução de Segurança e Gerenciamento de Disponibilidade, Estas duas áreas será responsável por definir as funções apropriadas. É incomum para um organização a nomeação de um "Access Manager", embora seja importante que haja um único Gerenciamento de Acesso processo e um único conjunto de políticas relativas à gestão direitos e acesso. Este processo e as políticas relacionadas são susceptíveis de ser definida e mantida por Gestão de Segurança da Informação e executado pelos diversos Operação de Serviço funçãos. As suas actividades podem ser resumidos como se segue. ITIL V3 - Operação de Serviço - Página: 281 de 423
    • 6.6.9.1 O papel do Service Desk O Service Desk é tipicamente utilizado como um meio para solicitar acesso a um serviço. Isso normalmente é feito através de um Solicitação de Serviço. O Service Desk vai validar o pedido de verificação de que o pedido foi aprovado no nível apropriado de autoridade, que o usuário é um legítimo empregado, empreiteiro ou cliente e que se qualificam para o acesso. Uma vez que tenha realizado essas verificações (normalmente acessando os bancos de dados relevantes e Nível de Serviço Gestão documentos) que vai passar a solicitação para a equipe apropriada para fornecer acesso. É bastante comum para o Service Desk para ser delegada a responsabilidade de proporcionar o acesso para serviços simples durante o chamar. O Service Desk também será responsável pela comunicação com o usuário para garantir que eles sabem quando o acesso foi concedido e para garantir que eles recebam qualquer outro apoio necessário. O Service Desk também está bem situado para detectar e relatar incidentes relacionados com o acesso. Por exemplo, os usuários que tentarem acessar serviços sem autoridade; ou usuários notificação de incidentes que indicam que uma sistema ou serviço tem sido usado de forma inadequada, ou seja, por um ex-funcionário que usou um antigo nome de usuário para ter acesso e fazer alterações não autorizadas. 6.6.9.2 O papel do Técnico e Gerenciamento de Aplicativos Técnico e Aplicação de Gestão de desempenham vários papéis importantes, como segue: • Durante Design de Serviços, Que irá assegurar que os mecanismos são criados para simplificar e controlar Gerenciamento de Acesso em cada serviço que é projetado. Eles também especificar maneiras em que o abuso de direitos pode ser detectado e parado • Durante Transição de Serviço eles vão testar a serviço para garantir que o acesso pode ser concedido, controlado e evitado como projetado • Durante Operação de Serviço essas equipes normalmente executar o gerenciamento de acesso para os sistemas sob seu controle. É incomum para equipes de ter uma pessoa dedicada a gerenciar Gerenciamento de Acesso, mas cada gerente ou líder de equipe irá garantir que o apropriado procedimentos são definidos e executado de acordo com a processo e política exigências • Técnica e Gerenciamento de Aplicativos também serão envolvidos em lidar com Incidentes e Problemas relacionados ao acesso de gerenciamento ITIL V3 - Operação de Serviço - Página: 282 de 423
    • • Se as atividades de gerenciamento de acesso são delegadas ao Service Desk ou TI Gestão de Operações, Técnica e Aplicação de Gestão deve assegurar que os funcionários estão devidamente treinados e que têm acesso às ferramentas necessárias para que possam desempenhar essas tarefas. 6.6.9.3 O papel da TI Gestão de Operações Onde Operações de TI é separado de Gestão Técnica ou aplicativo, é comum que operacional Acesse tarefas de gestão a ser delegada a TI Gestão de Operações. Operadores para cada área será encarregado de fornecer ou revogar o acesso aos sistemas-chave ou recursos. As circunstâncias em que podem fazê-lo, e as instruções de como fazê-lo, deve ser incluída nos POPs para essas equipes. O Operações Ponte, Se existir, pode ser usado para monitorar eventos relacionadas com o acesso de Gestão e pode até mesmo fornecer suporte de primeira linha e coordenação na resolução daqueles eventos onde for apropriado. ITIL V3 - Operação de Serviço - Página: 283 de 423
    • 6,7 Serviço Organização Estruturas de Operação Algumas informações gerais já foram apresentadas sobre considerações organizacionais para cada função (Ver os pontos 6.2.3, 6.3.4 e 6.5.6). Esta seção considera algumas estruturas organizacionais específicos para todas as funções. Há uma série de maneiras de organizar a operação de serviço de funções, e cada organização terá que tomar suas próprias decisões, com base em sua escala, geografia, cultura e de negócios ambiente. Algumas opções são discutidas no restante desta secção. 6.7.1 Organização pela especialização técnica Neste tipo de organização, os departamentos são criados de acordo com a tecnologia e as habilidades e atividades necessárias para gerenciar essa tecnologia. Operações de TI seguirá a estrutura da técnica e os departamentos de Gerenciamento de Aplicativos. A implicação disso é que operações de TI é voltado para o operacional agendas do técnico e serviços de gerenciamento de aplicações. Esta estrutura pode funcionar bem, desde que esses grupos estão completamente representado no Design de Serviços, Teste e melhoria de processos, que irá garantir que suas agendas estão alinhados com o exigências do negócio. Essa estrutura também pressupõe que todos os departamentos técnico e gerenciamento de aplicativos claramente a distinção entre a sua gestão atividade e actividade operações. Ele também exige que eles têm padronizado estes operacional atividades, para que possam ser efetivamente gerenciado pelo Gerente de Operações de TI, sem a interferência indevida do Técnico e Aplicação de Gestão de equipes ou departamentos. Um exemplo de uma de Operações de TI organização estrutura baseada no conhecimento técnico é dada na Figura 6.7 ITIL V3 - Operação de Serviço - Página: 284 de 423
    • Figura 6.7 Operações de TI organizados de acordo com a especialização técnica (amostra) As vantagens deste tipo de estrutura organizacional incluem o seguinte. • É mais fácil definir interna atuação objetivos desde todos os funcionários em um único departamento tem um conjunto semelhante de tarefas em uma tecnologia similar ITIL V3 - Operação de Serviço - Página: 285 de 423
    • • Individuais dispositivos, sistemas ou plataformas, pode ser gerido de forma mais eficaz já que as pessoas com as competências adequadas são dedicados a gerenciar esses e medido de acordo com o seu desempenho • Gestão de treinamento programas é mais fácil, pois os conjuntos de habilidades são claramente definidas e separadas em grupos específicos. As desvantagens deste tipo de estrutura organizacional incluem. • Quando as pessoas são divididas em departamentos separados das prioridades de seu próprio grupo tendem a substituir as prioridades de outros departamentos. Um exemplo desta situação é quando departamentos recusar aceitar a propriedade de um incidente, Cada um culpando o outro, enquanto o negócio continua a ser interrompido. • Conhecimento sobre a infra-estrutura e relaçãos entre componentes é difícil coletar e fragmentada. Grupos individuais tendem a coletar e manter apenas os dados que são necessários para apoiar a sua própria função, E não dá acesso a ele de forma muito fácil. • Cada tecnologia gerido por um grupo é visto como uma entidade separada. Isso se torna um problema em sistemas que consistem de componentes gerenciados por equipes diferentes, por exemplo, um aplicação, Gerenciado pela equipe de Gerenciamento de Aplicativos, executado em um servidor gerido pelo departamento de gerenciamento de servidor, usando um segmento de rede gerenciada pelo departamento de Área Local Networking. Se um mudar é feita por uma equipe ou departamento, sem consultar os outros, isso pode ser desastroso para a serviço. • É mais difícil de compreender o impacto do mau desempenho de um único departamento sobre o De serviços de TI uma vez que existem muitos grupos diferentes que contribuem para o mesmo serviço, cada um com seu próprio conjunto de objetivos de desempenho. • É mais difícil para acompanhar o desempenho de serviço de TI geral já que cada grupo está sendo medido em uma base individual. • Alterar coordenando as avaliações e Horários é mais difícil, já que muitos departamentos diferentes têm de fornecer dados para cada alteração. • Trabalho que exige conhecimento de várias tecnologias é mais difícil desde recursos só são treinados para e preocupadas com a gestão de uma única tecnologia. Projetos, por conseguinte, tem de incluir a formação transversal, o que é demorado e caro. 6.7.2 Organização pela atividade Este tipo de organização estrutura centra-se no facto de que as actividades semelhantes têm de ser realizados em todas as tecnologias na organização. Isto significa que as pessoas que realizam atividades similares, independentemente ITIL V3 - Operação de Serviço - Página: 286 de 423
    • da tecnologia, devem ser agrupadas, embora dentro de cada departamento pode haver equipes com foco em uma tecnologia específica, aplicação, Etc Neste tipo de organização, não há diferenciação clara entre o técnico diferente e áreas de Gerenciamento de Aplicativos. Atividades semelhantes de diversas áreas podem ser agrupados em um único departamento. Exemplos de serviços que foram criados para executar um conjunto específico de atividades em várias tecnologias incluem: • Manutenção (o que implica que uma equipe irá coordenar e realizar toda a manutenção em todas as tecnologias) • Gestão de contrato ou Terceiros Gestão • Monitoramento e Controle • Operações Ponte • Centro de Operações de Rede • Estratégia e Operações Planejamento (A qual, como parte do Design de Serviços processos, normalmente define o padrãos para ser usado em Operações de TI) - Este departamento pode definir estratégia ou padrões para cada tipo de técnica e área de Gerenciamento de Aplicativos. A Estratégia de Operações e Planejamento do departamento é usada para ilustrar este tipo de estrutura na Figura 6.8. Figura 6.8 Um departamento com base na execução de um conjunto de atividades ITIL V3 - Operação de Serviço - Página: 287 de 423
    • As vantagens deste tipo de estrutura organizacional incluem o seguinte. • É mais fácil para gerenciar grupos de atividades relacionadas já que todas as pessoas envolvidas nessas atividades relatar ao mesmo gerente • Medição de equipes ou departamentos se baseia mais na saída do que em atividades isoladas. Isso ajuda a construir os níveis mais altos de segurança que um serviço pode ser entregue. As desvantagens deste tipo de estrutura organizacional incluem o seguinte. • Recursos com capacidades semelhantes podem ser duplicados entre diferentes funçãos, o que resulta em maior custars • Embora a medição é mais baseada nos resultados, ainda é focada na atuação de actividades internas em vez de impulsionada pela experiência da cliente ou extremidade usuário. 6.7.3 Organização para gerenciar processos Não é uma boa idéia para toda a estrutura organização de acordo com os processos. Os processos são utilizados para ultrapassar o "efeito silo 'de departamentos, para não criar silos. No entanto, há uma série de processos que necessitam de uma estrutura específica para apoiar organização e gestão. Por exemplo, vai ser muito difícil para os Gestão Financeira para ser bem sucedido sem um departamento dedicado Finanças - mesmo que o departamento é composto por um pequeno número de funcionários. Em processoBaseados em pessoas das organizações são organizados em grupos ou departamentos que realizam ou gerenciar um processo específico. Isto é semelhante ao atividadeEstrutura baseada, exceto que os seus serviços se concentrar no fim-de-final conjuntos de atividades, em vez de um tipo específico de atividade. Deve notar-se que este tipo de estrutura, a organização apenas deve ser usado se TI Gestão de Operações é responsável por mais do que apenas Operações de TI. Em algumas organizações, por exemplo, operações de TI é responsável por definir SLAs e negociação de UCs. Além disso, os processos existentes para ligar especificamente as actividades de grupos diferentes para atingir um determinado resultado. Usando processos como base para criar departamentos pode derrotar o propósito de ter processos em primeiro lugar. Baseadas em processos departamentos são realmente eficazes apenas quando eles são capazes de coordenar a execução do processo através de toda a organização. ITIL V3 - Operação de Serviço - Página: 288 de 423
    • Isto significa que o processo baseados serviços devem ser consideradas apenas se TI Gestão de Operações é jogar o papel de Proprietário do Processo para um determinado processo. Exemplos de processos baseados em grupos ou departamentos incluem: • Operações capacidade • Monitoramento e Controle de disponibilidade • TI Gestão Financeira • Administração de Segurança • Ativos e Gerenciamento da Configuração (Incluindo a instalação de equipamentos e desenvolvimento). As vantagens deste tipo de estrutura organizacional incluem o seguinte. • Os processos são mais fáceis de definir • Há menos conflitos papel como descrição do trabalhos e descrições de papéis de processo são os mesmos. Em outras estruturas uma descrição do trabalho único normalmente incluem atividades para várias funções • Métricos da equipe ou do desempenho de departamentos e de desempenho do processo são os mesmos, efetivamente alinhar métricas "internas" e "externo". As desvantagens deste tipo de estrutura organizacional incluem o seguinte. • Um princípio básico de processos é que eles são um meio de associar as atividades de vários departamentos e grupos. Usando processos como base para a organização projeto, Processos adicionais necessitam de ser definido para assegurar que os departamentos de trabalhar em conjunto. • Mesmo que um departamento é responsável pela execução de um processo, Ainda haverá dependências externas. Os grupos não podem ver as atividades do processo fora do seu próprio processo como sendo importante, resultando em processos que não podem ser plenamente executados porque dependências não podem ser cumpridas. • Embora alguns aspectos de um processo podem ser centralizados, haverá sempre um certo número de actividades, que terão de ser realizados por outros grupos. O relação entre a equipe dedicada ou departamento e as pessoas que executam as atividades descentralizadas é muitas vezes difícil de definir e gerenciar. 6.7.4 Organização de Operações de TI por geografia Operações de TI pode ser fisicamente distribuído e, em alguns casos, cada localização precisa de ser organizada de acordo com o seu próprio contexto particular. ITIL V3 - Operação de Serviço - Página: 289 de 423
    • Esta estrutura é normalmente usado nos seguintes casos: • Centros de dados são distribuídos geograficamente • Diferentes regiões ou países têm diferentes tecnologias ou fornecer um conjunto diferente de serviços • Há negócio diferente modelos ou estruturas organizacionais, nas diferentes regiões, ou seja, o negócio é descentralizada pela geografia e cada Unidade de Negócios é bastante autônomo • Legislação diferente se aplica a países ou regiões diferentes (por exemplo, regulamentos de segurança) • Diferente padrãos aplicar em países ou regiões diferentes • As diferenças culturais ou idioma existir entre o pessoal gestão de TI. Um exemplo deste tipo de estrutura é dada na Figura 6.9. Observe que, neste exemplo, cada departamento geográfico está estruturado internamente usando Especialização Técnica. Isto poderia ser diferente em cada região. Por exemplo, uma região pode ser estruturada desta maneira, enquanto que uma outra região utiliza um processo ou atividadeBaseada em estrutura. ITIL V3 - Operação de Serviço - Página: 290 de 423
    • Figura 6.9 Operações de TI organizados de acordo com a geografia Figura 6.9 também ilustra que um local pode realizar operações centralizadas para todas as regiões, se eles são bastante semelhantes. Neste exemplo, o servidor americana Operations Department gere todas servidor operações em todos os locais, Bruxelas gerencia todas as operações de banco de dados e Cingapura gerencia todas as operações de armazenamento. As vantagens deste tipo de estrutura organizacional incluem o seguinte. • Estrutura organizacional pode ser personalizado para atender às condições locais • Operações de TI pode ser personalizado para atender diferentes níveis de De serviços de TI de região para região. As desvantagens deste tipo de estrutura organizacional incluem o seguinte. ITIL V3 - Operação de Serviço - Página: 291 de 423
    • • Reportagem linhas e estruturas de autoridade pode ser confuso. Por exemplo, se informar Operações de Rede no Gerenciador de dados locais ou para um Centro centralizado Gerente de Operações de Rede? • Operacional padrãos são difíceis de impor, resultando em atividades inconsistentes e duplicados e ferramentas, resultando na redução economias de escala, Que por sua vez aumenta o global custar das operações. • Duplicação de papels, atividades, ferramentas e instalações em vários locais pode ser muito caro. • Serviços compartilhados, tais como e-mail, são mais difíceis de se entregar como cada regional organização opera de forma diferente. • Comunicação com clientes e no interior, será mais difícil, pois eles não são co-localizado e pode ser difícil para o pessoal em um único local para entender as prioridades dos clientes ou funcionários em outro local. 6.7.5 híbridos estruturas de organização É pouco provável que TI Gestão de Operações será estruturada usando apenas um tipo de estrutura de organização. A maioria das organizações usam uma especialização técnica, com alguns adicionais atividade- Ou de processos baseados em departamentos. O tipo de estrutura utilizada e a exata combinação de especialização técnica, baseada em actividades e processoBaseadas em serviços irá depender de uma série de variáveis de organização. Organizacionais variáveis de estrutura Os critérios exactos escolhido e da estrutura organizacional resultante dependerá de um número de variáveis, que podem incluir: • A natureza do negócio • Negócio exigências e expectativas • A técnica e tecnológica arquitetura • A estabilidade da corrente Infraestrutura de TI e a disponibilidade de habilidades para gerenciá-lo • O governo da organização (ou seja, a forma como a autoridade é atribuído e são tomadas as decisões - bem como qualquer estrutura de governança formal que é utilizado, tal como COBIT ou SOX) • O legislativo, político e sócio-econômico ambiente da organização • O tipo eo nível de habilidades à disposição da organização • O tamanho, idade e maturidade do organização • O estilo de gestão da organização • Dependência de TI para negócios críticos atividades, processos e funçãos • A maneira em que participa na rede de valor (Ou seja, a forma como ele interage com o negócio e seus parceiros, fornecedors e clientes) ITIL V3 - Operação de Serviço - Página: 292 de 423
    • • O relação entre a TI e seus fornecedores. Para uma descrição mais completa de como esses fatores influenciam organizacional projeto, Por favor consulte a seção "Desenvolvimento Organizacional" do Estratégia de Serviço publicação. 6.7.5.1 Funções combinadas Um último tipo de organização deve ser discutido. Esta estrutura incorpora operações de TI, técnicos e Aplicação de Gestão de departamentos dentro de uma estrutura única. Isso às vezes é o caso em que todos os grupos são co- localizado em um centro de dados único. Aqui, o Data Centre Manager assume a responsabilidade por toda a aplicação, Técnico e TI Gestão de Operações. Este tipo de estrutura, a organização encontra-se ilustrada na Figura 6.10. ITIL V3 - Operação de Serviço - Página: 293 de 423
    • Figura 6.10 Centralizado operações de TI, técnicos e estrutura de Gerenciamento de Aplicativos Nesta estrutura, TI Gestão de Operações é responsável pela técnica e Aplicação de Gestão de funçãos, que por sua vez são responsáveis por sua própria operacional actividades. Cada departamento é capaz de delegar algumas dessas atividades para o Operações de controle departamento. As vantagens desta estrutura de organização são: • Há uma maior consistência e controlar entre o mais tático e operacional Gestão Técnica atividades • É mais fácil de aplicar o atuação padrãos e técnicas arquiteturas que são criadas Design de Serviços, Já que as pessoas que estiveram envolvidas ITIL V3 - Operação de Serviço - Página: 294 de 423
    • em projeto estão a gerir as atividades das pessoas que estão executando as atividades • Como não há duplicação entre localização ou atividade, Esta estrutura é muitas vezes mais custo-efetiva. A desvantagem desta estrutura da organização é: • O escopo desta estrutura torna muito difícil de gerir de forma eficaz em grandes organizações ou em organizações com múltiplas Centros de Dados. 6.7.5.2 Aplicação de Organização e Gestão Técnica Técnico e Aplicação de Gestão de organizações tendem a ser bastante simples. Expressa nos pontos 6.3.4 e 6.5.6, Gestão Técnica departamentos são geralmente baseados na tecnologia que gerem e departamentos de gerenciamento de aplicativos no aplicaçãos e conjuntos de aplicativos que gerenciam. No entanto, existem algumas alternativas organização estruturas e variações, que são discutidos nesta seção. 6.7.5.3 Geografia Em organizações com múltiplos locais, é comum para o técnico e Aplicação de Gestão de departamentos para ser representados em cada local físico. No entanto, isso não significa que cada local terá todos os mesmos serviços, ou que todos eles são responsáveis pelas mesmas ações. Como ferramentas de suporte e gestão amadurecer mais e mais Infraestrutura de TI e cis aplicação pode ser gerenciado remotamente. Isto significa que cada departamento terá uma forte equipe de gestão técnica centralizada ou aplicativo, com os membros locais para fornecer especializados, actividades no hotel ou suporte. Por exemplo, em Servidor Gestão, a equipe central vai ajudar a criar padrãos para servidor configuração, Eles vão monitorar e controlar dispositivos remotos, executar apoios, realizar atualizações de sistema operacional, etc As equipes locais irão fornecer básico suporte on-site manutenção de hardware, e reparar e configuração e instalação de novos servidores. Em Gerenciamento de Aplicativos, a equipe central poderia participar de curso projeto e ensaio da aplicação,monitoramento e controlar, executar backups, dados integridade cheques, etc A equipe local poderia fornecer suporte on-site e educação para acabar usuários e trabalho com o local Gestão Técnica equipe para resolver mais complexo problemas envolvendo equipamentos local. ITIL V3 - Operação de Serviço - Página: 295 de 423
    • Há um potencial problema que precisa ser resolvido no entanto, e é isso o que a equipe local reporta. Em algumas organizações relatam que o gerente da equipe centralizada. Isto tem a vantagem adicional de acordo atuação e gestão de toda a empresa. Em outras organizações as equipes locais informar o mais antigo Gerente de TI no local. Isto tem a vantagem adicional de que Serviços de TIs pode ser personalizado para atender às condições locais, mas ele cria uma grande confusão sobre o que as equipes locais devem tomar a direcção de. As vantagens deste tipo de estrutura organizacional incluem o seguinte. • Estrutura organizacional pode ser personalizado para atender às condições locais • Técnica e Gerenciamento de Aplicativos podem ser personalizados para atender diferentes níveis de serviços de TI de região para região. As desvantagens deste tipo de estrutura organizacional incluem o seguinte. • Reportagem linhas e estruturas de autoridade pode ser confuso • Padrões são difíceis de impor, resultando em atividades inconsistentes e duplicados e ferramentas, resultando na redução economias de escala, Que por sua vez aumenta o global custar das operações • Duplicação de papels, atividades, ferramentas e instalações em vários locais pode ser muito caro. 6.7.5.4 Técnica Combinada e estrutura de Gerenciamento de Aplicativos Algumas organizações organizar sua Gestão Técnica e Aplicação funçãos de acordo com os sistemas. Isto significa que cada departamento será composto de especialistas em aplicações e Infraestrutura de TI especialistas técnicos, todos voltados para a gestão dos serviços com base em que o conjunto de sistemas. Componentes que são compartilhados entre todos estes sistemas, tais como a rede, será gerido pelo dedicado Gestão Técnica departamentos. A vantagem desta organização estrutura é a seguinte: • É mais fácil de produzir produtos de altaqualidade a saída para a extremidade usuário porque todos os membros de departamentos estão focados no sucesso do sistema como um todo, em vez de o atuação de um componente individual ou de tecnologia aplicação. As desvantagens desta estrutura de organização são: ITIL V3 - Operação de Serviço - Página: 296 de 423
    • • Duplicação de competências e recursos através de vários departamentos irá aumentar a custar da organização. Por exemplo, cada grupo é provável que tenha uma pessoa ou equipe dedicada à gestão servidors - cada um dos quais vai fazer tarefas muito semelhantes. • Comunicação entre os funcionários que estão a gerir tecnologia semelhante é reduzido. Isso reduz a quantidade de aprendizado por experiência e aumenta a dependência de colaboração gestão do conhecimento ferramentas. • Quando as pessoas com habilidades semelhantes estão no mesmo departamento, o departamento irá compensar para os membros com menor habilidade e níveis de competência. Quando há apenas uma pessoa com habilidades Management Server em um departamento baseado no sistema, e sua competência é mínima, isso afetará o desempenho de todo o departamento. ITIL V3 - Operação de Serviço - Página: 297 de 423
    • 7 considerações de tecnologia Cada função e processo é definida na secção relevante nos capítulos 4 e 6. Este capítulo traz toda a tecnologia exigências em conjunto para definir a exigência geral de um conjunto integrado de tecnologia de Gestão de Serviços para Operação de Serviço. A mesma tecnologia, com algumas adições possíveis, deve ser usado para as demais fases do ITSM - Estratégia de Serviço,Design de Serviços,Transição de Serviço e Melhoria de Serviço Continuada - Para dar consistência e permitir uma eficaz ITSM Ciclo de Vida a ser devidamente geridos. Os principais requisitos para operação de serviço, são os estabelecidos neste capítulo. ITIL V3 - Operação de Serviço - Página: 298 de 423
    • 7,1 requisitos genéricos Uma visão integrada de ITSM tecnologia (ou conjunto de ferramentas, como alguns fornecedors vender sua tecnologia como "módulos" enquanto algumas organizações podem optar por integrar os produtos de fornecedores alternativos) é necessário que inclui a funcionalidade do núcleo seguinte. 7.1.1 Auto-Ajuda Muitas organizações consideram que é benéfico para oferecer capacidades de "auto-ajuda" para os seus utilizadores. A tecnologia deve apoiar esta capacidade com alguma forma de web front-end permitindo que páginas web para ser definido oferecendo uma gama menu-driven de auto-ajuda e Solicitação de Serviços com uma interface direta para o back-end processo-Manipulação de software. 7.1.2 Fluxo de Trabalho ou processo motor Um fluxo de trabalho ou controle de processo motor é necessário para permitir a definição de pré-e controlo de processos definidos, tais como um ciclo de vida de incidentes, Cumprimento de Requisição Lifecycle, Ciclo de Vida problema, altere Modelo, Etc Isso deve permitir que responsabilidades, atividades, prazos, escalada caminhos e alertando para ser pré-definidos e, então, automaticamente gerenciado. 7.1.3 Integrado CMS A ferramenta deve ter um CMS integrado para permitir que o organização'S Infraestrutura de TI ativoss, componentes, serviços e qualquer CIs auxiliares (como contratos, locais, licenças, fornecedors etc - qualquer coisa que os desejos de TI da organização para controlar) A ser realizada, em conjunto com todas as partes atributos, em uma localização centralizada - e permitir relaçãos entre cada ser armazenados e mantidos, e ligado a incidentes, problemas, Erro Conhecido e Alteração do registros conforme apropriado. 7.1.4 Descoberta de Implantação / / licenciamento de tecnologia A fim de preencher ou verificar os dados do CMS e para auxiliar no gerenciamento de licença, descoberta ou automatizado auditar são necessárias ferramentas. Tais ferramentas deve ser capaz de ser executado a partir de qualquer local na rede e permitir uma interrogação e recuperação de informações relativas a todos os componentes que compõem, ou está conectado, a infra-estrutura de TI. ITIL V3 - Operação de Serviço - Página: 299 de 423
    • Essa tecnologia deverá permitir "filtragem" de modo que os dados que estão sendo realizadas para a frente pode ser controlados e apenas os dados necessários extraído. Também é muito útil se "apenas" mudanças desde a última auditoria pode ser extraído e reportados. A mesma tecnologia pode ser usada freqüentemente para implantar um novo software para locais de destino - este é um elemento essencial exigência para todos Operação de Serviço equipes ou departamentos, para permitir correções, transporta etc, para ser distribuído para a correta usuários. Uma interface com capacidade de 'auto-ajuda' é desejável permitir downloads de software aprovados a ser solicitado desta forma, mas manipulada pelo desenvolvimento software. Ferramentas que permitem a comparação automática de detalhes licenças de software realizada (no CMS, de preferência) e números de licença reais implantado - com a notificação de qualquer discrepância - são extremamente desejável. 7.1.5 O controle remoto Muitas vezes, é útil para o Service Desk Analistas e outros grupo de apoios para ser capaz de tomar controlar do usuário desk-top (sob devidamente controlada segurança condições), de modo a permitir-lhes a realização de investigações ou as configurações corretas, instalações, etc para que esse nível de controle remoto será necessário. 7.1.6 utilitários de diagnóstico Pode ser extremamente útil para o Service Desk e outros grupos de apoio, se a tecnologia incorporada a capacidade para criar e utilizar script de diagnósticos e outros utilitários de diagnóstico (tais como, por exemplo, ferramentas de raciocínio baseado em casos) para auxiliar anteriormente diagnóstico de incidentes. Idealmente, estes devem ser "sensível ao contexto" apresentação e dos scripts automatizados, tanto quanto possível. 7.1.7 Relatórios Não há nenhum uso em armazenamento de dados, a menos que ele pode ser facilmente recuperado e usado para atender fins da organização. A tecnologia deve, portanto, incorporar capacidades de comunicação bons, bem como permitir interfaces padrão que pode ser usado para entrada de dados para pacotes padrão da indústria, relatórios, painel de instrumentoss, etc Idealmente, instantânea, na tela, bem como relatórios impressos podem ser fornecidas através do uso de sensíveis ao contexto 'top 10' relatórios. ITIL V3 - Operação de Serviço - Página: 300 de 423
    • 7.1.8 Dashboards Do tipo painel tecnologia é útil para permitir "ver de relance" visibilidade global De serviços de TI atuação e disponibilidade níveis. Tais monitores podem ser incluídos no nível de gestão de relatórios para usuários e clientes -, mas também pode dar informações em tempo real para a inclusão nas páginas web de TI para dar informação dinâmica, e pode ser usado para o suporte e para fins de investigação. Capacidades para apoiar visualizações personalizadas de informações para atender aos níveis específicos de interesse pode ser particularmente útil. No entanto, às vezes eles representam uma técnica em vez de serviço vista da infra-estrutura e, nesses casos, pode ser de menor interesse para os clientes e usuários. 7.1.9 Integração com o Business Service Management Há uma tendência na indústria de TI para tentar reunir negócios relacionados a TI com os processos e disciplinas de IT Service Management - Alguns chamam isso de Business Service Management. Para facilitar este negócio, aplicaçãos e ferramentas precisam ser conectado com ferramentas de apoio ITSM para dar a funcionalidade necessária. Isso pode ser ilustrado pelo seguinte exemplo: Uma empresa de telecomunicações do Leste Europeu foi capaz de interface seu telefone celular net- monitoramento e faturamento sistema ao seu Gestão de Eventos,Gerenciamento de Incidentes e Gerenciamento da Configuração processos. Desta forma, foi capaz de detectar qualquer incomuns de uso / faturamento padrões e interpretá-los de tal forma que ele pode identificar, com um alto grau de certeza, que um telefone tinha sido roubado e estava sendo usado para fazer chamadas ilícitas. Ele foi capaz de aumentar eventos para tais padrões e automatizar ações para suspender o uso dos dispositivos de telefonia móvel e, em paralelo, identificar a localização exata do usuário ilícito (usando a tecnologia GPRS) e levantar os incidentes de modo que a polícia tinha a capacidade de encontrar o ladrão e recuperar suspeita do dispositivo. Capacidades mais avançadas ferramentas de integração são necessários para permitir uma maior exploração deste tipo de negócio e integração de TI. ITIL V3 - Operação de Serviço - Página: 301 de 423
    • 7.2 Gestão de Eventos As seguintes características são desejáveis para qualquer tecnologia de gerenciamento de eventos: • Multi-ambiental, interface aberta para permitir monitoramento e alerta em todos os serviços heterogêneos e um organização'S inteira Infraestrutura de TI. • Fácil de implantar, com o mínimo de configurar custars. • "Standard" agentes para monitorar mais comum ambientes /componentes / sistemas. • Interfaces abertas a aceitar qualquer SNMP (por exemplo) padrão evento de entrada e geração de alerta múltipla. • Roteamento centralizado de todos eventos para um único local, programável para permitir local diferente (s) em vários momentos. • Suporte para projeto/teste fases - de modo que o novo aplicaçãos / serviços podem ser monitoradas durante o projeto / teste fases e resultados alimentado de volta para o projeto e de transição. • Programável avaliação e manipulação de alertars dependendo dos sintomas e impacto. • A capacidade de permitir que um operador de reconhecer um alerta, e se nenhuma resposta for inserido dentro de um prazo definido, para escalar o alerta. • Funcionalidade de relatórios para permitir bom feed-back em design e fases de transição, bem como um significativo gestão da informação e de negócios usuário 'painel de instrumentos'. Essa tecnologia deve permitir uma interface direta para o organização'S Gerenciamento de Incidentes processos (via entrada no Registro de Incidentes), bem como a capacidade de escalar para apoiar a equipe, outros fornecedores, engenheiros etc via e-mail, mensagens SMS, etc Instalações especializadas, ou talvez ferramentas especializadas separados, será exigido para o site monitoramento. Essas instalações devem ser capazes de simular cliente tráfego para o site e para informar sobre disponibilidade e atuação em relação à "experiência do cliente". ITIL V3 - Operação de Serviço - Página: 302 de 423
    • 7,3 Gerenciamento de Incidentes 7.3.1 Integrado ITSM tecnologia Tecnologia integrada de ITSM é exigido que tem as seguintes funcionalidades: • Um integrante CMS para permitir automatizado relaçãos a ser feita e mantida entre incidentes, solicitação de serviços, problemas, Erro Conhecidos e todas as outras item de configuraçãos. • O CMS que pode ser usada para ajudar a determinar prioridade e ajuda na investigação e diagnóstico. • Aprocesso mecanismo de fluxo de processos para permitir a ser pré- definido (incluindo pré-definidos incidente modelos, ver o ponto 3.2.1.5) e controlada automaticamente - com roteamento interno flexível para todos relevantes grupo de apoios e interfaces externas e-mail/SMS. • Automatizado de alerta e escalada capacidades para evitar um incidente que está sendo ignorado ou adiado. • Abra a interface para Gestão de Eventos ferramentas, de modo que qualquer falhas pode ser automaticamente criado como incidentes. • A interface web para permitir que os pedidos de auto-ajuda e serviço para ser a entrada através da Internet / Intranet telas. • Um BDEC integrada para que o diagnóstico e / ou resolvidos incidentes / problemas podem ser gravadas e procurou ajudar no incidente futuro excesso de velocidade resolução. • Fácil de usar instalações de relatórios para permitir incidente métricos para ser produzido e para facilitar a análise de incidentes de Gerenciamento de Problemas e Gestão fins disponibilidade. • Ferramentas de diagnóstico (integrada ou interfaces para produtos separados), como já mencionado no Service Desk. 7.3.2 Fluxo de Trabalho e escalonamento automatizado Os tempos de alvo devem ser incluídos em ferramentas de apoio, o que deve ser usada para automatizar o fluxo de trabalho controlar e escalada caminhos. Se, por exemplo, um segunda linha de apoio grupo não resolveu uma incidente dentro de uma meta de 60 minutos acordado, o incidente deve ser automaticamente encaminhado para a adequada (determinada pela categorização incidente) linha de terceira grupo de apoio - E caso seja necessário escalada hierárquica deve ser realizada automaticamente (por exemplo, mensagem SMS para o Service Desk Manager, Gerente de Incidentes e / ou IT Services Manager e talvez para o usuário, Se for o caso). A segunda linha grupo de apoio deve ser informado da acção de escalonamento como parte do automático processo. ITIL V3 - Operação de Serviço - Página: 303 de 423
    • 7,4 cumprimento Pedido Integrated ITSM tecnologia é necessária a fim de que Solicitação de Serviços pode ser ligado a ou incidentes eventos que iniciaram eles (e foi armazenado no CMS mesmo, que pode ser interrogado para relatar contra SLAs). Algumas organizações se contentar em usar a Gerenciamento de Incidentes elemento de tais ferramentas e tratar solicitações de serviços como um subconjunto e definidas categoria de incidentes. Quando um organização escolhe para levantar Pedidos de serviço separada, será necessária uma ferramenta que permite que este capacidade. Front-end de Auto-Ajuda recursos que serão necessários para permitir que os usuários enviem solicitações via alguma forma de web-based processo de seleção, menu-driven. Em todos os outros aspectos, as instalações necessárias para gerenciar solicitações de serviço são muito semelhantes aos de gestão de incidentes: pré- definido de controle de fluxo de trabalho de Solicitação Modelos, prioridade níveis, de escalonamento automatizado, comunicação eficaz, etc ITIL V3 - Operação de Serviço - Página: 304 de 423
    • 7,5 Gerenciamento de Problemas 7.5.1 Integrated Service Management Technology Uma ferramenta integrada de ITSM é necessário que diferencia entre incidentes e problemas - para que em separado Grave problemas pode ser elevado para lidar com as causas dos incidentes, mas ligado aos incidentes relacionados. A funcionalidade de registos problema deve ser semelhante às que são necessárias para Grave incidentes e também para permitir incidente múltipla correspondência contra registros de problemas. 7.5.2 Gestão da Mudança Integração com Gestão da Mudança É muito importante, para que Pedido, Evento de Incidentes e Grave problemas pode ser relacionado com RFCs que causaram problemas. Trata-se de avaliar o sucesso da gerência da mudança processo - Incidente, bem como e Grave erro conhecidos - e para que RFCs pode ser facilmente aumentado para controlar as atividades necessárias para superar os problemas que foram identificados através da análise de causa raiz ou Proactive Análise de Tendências. 7.5.3 Integrado CMS É também importante ter um CMS integrado que permite registos problema a ser ligada ao componentes afetados e os serviços afetados - e de qualquer outros CIs relevante. Gerenciamento da Configuração faz parte de um SKMS maiores que inclui ligações a muitos dos repositórios de dados utilizados na Operação de Serviços. O processo e práticas de Gerenciamento de Configuração e suas tecnologias subjacentes exigências são incluídos na Transição de Serviço publicação. 7.5.4 Banco de Dados Erro Conhecido Um BDEC eficaz será como requisito essencial, o que deve permitir fácil armazenamento e recuperação de Erro Conhecido dados. Instalações boas reportagens são necessários para facilitar a produção de relatórios de gestão, permitindo que os dados sejam incorporados automaticamente, sem a necessidade de re-digitação de dados - e para permitir capacidades de drill-down para a Incidentes e Análise de Problemas. Nota: Em alguns casos, os componentes ou sistemas sendo investigado pela Gerenciamento de Problemas pode ser fornecido por outros fornecedores ou ITIL V3 - Operação de Serviço - Página: 305 de 423
    • fabricantes. Para resolver este problema, as ferramentas de vendedores de suporte e / ou KEDBs também pode precisar de ser utilizado. ITIL V3 - Operação de Serviço - Página: 306 de 423
    • 7,6 Gerenciamento de Acesso Gerenciamento de Acesso usa uma variedade de tecnologias, principalmente: • Tecnologia de Gestão de Recursos Humanos, para validar o identidade de usuários e para acompanhar a sua estado • Serviço de Diretórios Technology (ver secção 5.8 para uma descrição de Serviços de Diretório). Esta tecnologia permite que gerentes de tecnologia para atribuir nomes a recursos sobre uma rede e, em seguida, fornecer acesso a esses recursos com base no perfil do utilizador. Ferramentas Directory Services também permitem Gerenciamento de Acesso para criar papels e grupos e de vincular estes para ambos os usuários e recursos • Acesse os recursos de gestão em Aplicativos, Middleware, Sistemas Operacionais e Sistemas Operacionais de Rede • Gestão da Mudança sistemas • Cumprimento de Requisição tecnologia (ver secção 7.4). ITIL V3 - Operação de Serviço - Página: 307 de 423
    • 7,7 Service Desk Ferramentas adequadas e apoio a tecnologia deve ser fornecida para permitir Service Desk pessoal para desempenhar seus papéis de forma eficiente e eficaz possível. Isto vai incluir o seguinte. 7.7.1 Telefonia Porque uma elevada percentagem de incidentes são susceptíveis de ser levantado através de chamadas telefónicas a partir de usuários, o Service Desk deve ser fornecido com bons serviços de telefonia modernos. Isto deve incluir: • Um sistema automatizado chamar distribuição (ACD) sistema para permitir que um único número de telefone (ou números se um Service Desk distribuída ou segmentado é a opção preferida) e grupo pick-up capacidades. Aviso: Se as opções são oferecidos através do DAC, via teclado ou Interactive Voice Recognition seleção (IVR), não use muitos níveis de opções ou oferecer opções ambíguas. Também não incluem qualquer "becos sem saída" ou opções que, uma vez escolhido, não permitem que o chamador para voltar aos menus anteriores. • Computer Telephony Interface de software (CTI) para permitir o reconhecimento de chamadas (ACD via ligada) e população automatizada do usuárioDetalhes S 'para o registro de incidente da CMS. • VoIP - uso desta tecnologia pode reduzir significativamente telefonia custars ao lidar com usuários remotos e internacionais • Software estatístico permitir que as estatísticas de telefonia devem ser recolhidas e facilmente interrogado / impressos para análise - este deve permitir a seguinte informação a ser obtida por qualquer período selecionado: • Número de chamadas recebidas, no total e discriminado por qualquer 'racha' - onde qualquer chamada de roteamento foi escolhido e está sendo fornecida por um IVR sistemaResposta / teclado • Chame perfis de chegada e tempos de resposta • Chame taxas de abandono • Gestão de chamadas taxas por pessoa Service Desk chamar manipuladores • Média de duração de chamadas • Auriculares mãos-livres, com capacidades de dual-acesso do usuário (pelo menos em alguns dos fones de ouvido) para uso durante o treinamento de novos funcionários, etc 7.7.2 Ferramentas de suporte Há uma gama de free-standing ferramentas de serviço Posto de apoio disponíveis no mercado - e algumas organizações podem optar por produzir seu ITIL V3 - Operação de Serviço - Página: 308 de 423
    • próprio simples incidente log /sistema de gestãos. Se um organização seriamente pretende implementar ITSM então um sistema totalmente integrado conjunto de ferramentas ITSM será necessário que tenha um CMS no centro e fornece suporte integrado para todo o ITILDefinida processos. Elementos específicos de uma ferramenta que irá ser particularmente benéfico para a central de serviços incluem o seguinte. 7.7.2.1 Banco de Dados Erro Conhecido Um BDEC integrado deve ser usado para armazenar detalhes de incidentes anteriores /problemas e a sua resoluçãos -, de modo que quaisquer recidivas podem ser mais rapidamente diagnosticada e fixado. Para facilitar isso, a funcionalidade é necessário para categorizar e recuperar rapidamente anterior Erro Conhecidos, usando a correspondência de padrão e palavra-chave busca contra os sintomas. Gestão do BDEC é de responsabilidade do Gerenciamento de Problemas, Mas o Service Desk será usado para ajudar tratamento de incidentes de velocidade. 7.7.2.2 os scripts de diagnóstico Multi-nível script de diagnósticos devem ser desenvolvidos, armazenados e gerenciados para permitir que o pessoal Service Desk para identificar a causa da falhas. Especialista grupo de apoios e fornecedors deve ser solicitado a fornecer detalhes sobre as falhas prováveis e as questões-chave a serem feitas para identificar exatamente o que deu errado - e para os detalhes da resolução ações a serem tomadas. Esses detalhes devem então ser incluído em scripts sensíveis ao contexto que devem aparecer na tela, dependentes da categorização multi-nível do incidente, E deve ser impulsionada pelo usuário'S respostas a perguntas de diagnóstico. 7.7.2.3 interface web de Auto-Ajuda Muitas vezes, é rentável e conveniente para fornecer algum tipo de funcionalidade automática 'auto-ajuda', assim os usuários podem procurar e obter a assistência que lhes permita resolver suas próprias dificuldades. Idealmente isto deve ser através de uma interface de 24/7 web que é impulsionado pela seleção de menu e pode incluir, conforme apropriado: • Perguntas mais frequentes (FAQ) e soluções. • 'Como fazer' capacidades de busca para orientar os usuários através de uma lista de contexto de tarefas ou atividades. • Um boletim do tipo serviço contendo detalhes de questões de serviço pendentes / problemas junto com tempos de restauração de antecipados. ITIL V3 - Operação de Serviço - Página: 309 de 423
    • • Senha capacidades de mudança - usando software de proteção de senha segura para verificar identidades, senhas de autorização e realizar a mudança sem a necessidade de Service Desk intervenção. • Download de software de correção (patches, service packs, etc correções de bugs, onde é determinado que o usuário tem o errado versão ou uma correção seja necessário) - ferramentas estão disponíveis para automatizar a verificação processo, Para comparar a imagem do desktop real com o acordado 'padrão' construirs e para permitir atualizações para ser oferecido e aceito, quando necessário. • Software reparars - onde se detectou que a corrupção pode ter ocorrido, para permitir correções de software, remoção e / ou re-instalação. • Pedidos de remoção de software - automaticamente preenchido com qualquer licença a ser retornado para o pool. • Downloads de pacotes de software adicionais - ferramentas estão disponíveis para verificar um software pré-definido política e para permitir o download de pacotes de software adicionais, se coberto pela apólice. Isso pode incluir verificações automatizadas de software de licenças e aprovações financeiras, bem como CMS atualização. • Aviso prévio de qualquer tempo de inatividade planejado ou interrupções de serviços ou degradações. A solução de auto-ajuda deve incluir o capacidade para usuários para registrar incidentes em si, que podem ser usadas durante períodos em que o Service Desk está fechado (se não funcionar 24/7) e atendidas pela equipe de Service Desk no início do próximo deslocar. Alguns cuidados devem ser tomados para garantir que as atividades de auto- ajuda selecionados para inclusão não são demasiado avançado para o usuário médio, e que as salvaguardas são incluídos para evitar um "pouco conhecimento de ser uma coisa perigosa '! Pode ser possível para oferecer um pouco mais avançadas de Auto-Ajuda instalações para 'Usuários super' que tiveram treinamento extra. Também é necessário ter muito cuidado com suposições feitas ao pessoal um Service Desk com a quantidade de uso que os usuários irão fazer de Auto-Ajuda instalações. Observação: Como já foi abordado na lista acima, é possível combinar algumas simples Cumprimento de Requisição atividades como parte de uma estratégia global de Auto-Ajuda sistema - Que também pode ser um benefício significativo na redução de chamadas para a Central de Serviço (ver parágrafo 7.1.1 para mais detalhes). 7.7.2.4 O controle remoto Como já foi dito, mas repetiu aqui para ser completo, muitas vezes é útil para os analistas do Service Desk para ser capaz de tomar controlar da área de trabalho do usuário, de modo a permitir-lhes a realização de investigações ou ITIL V3 - Operação de Serviço - Página: 310 de 423
    • configurações corretas, instalações etc para permitir esse nível de controle remoto será necessário. 7.7.3 Planejamento da Continuidade dos Serviços de TI para ferramentas de suporte ITSM Organizações tendem a tornar-se rapidamente dependentes de suas ferramentas de ITSM e vai achar que é difícil trabalhar sem eles. Um completo Análise de Impacto no Negócio e Risco A análise deve ser realizada e planos, em seguida, desenvolvido para assegurar a adequada De serviços de TI Continuidade e resiliência níveis. ITIL V3 - Operação de Serviço - Página: 311 de 423
    • 8 considerações sobre a aplicação Deve notar-se que Operação de Serviço é uma fase em ciclo de vida e não uma entidade em seu próprio direito. No momento em que um serviço, processo,organização estrutura ou a tecnologia está a funcionar, já foi implementado. No entanto, há um número de processos e funçãos descritos nesta publicação, e, portanto, é importante abordar as considerações de implementação que deveriam ter sido abordados no momento em que entrar em operação. Alguns destes foram abordados na seção relevante - por exemplo é dada orientação sobre estruturas de organização e papels no Capítulo 6. Isto não será repetida aqui. Em vez disso, esta secção irá se concentrar em alguma orientação implementação genérica para operação de serviço como um todo. ITIL V3 - Operação de Serviço - Página: 312 de 423
    • 8,1 mudança de gestão, em Operação de Serviço Operação de Serviço deve se esforçar para alcançar a estabilidade - mas não a estagnação! Há muitas razões válidas e vantajoso porque 'mudar é uma coisa boa "-, mas o pessoal Operação de Serviço deve assegurar que quaisquer mudanças são absorvidas sem efeitos impacto sobre a estabilidade dos serviços de TI oferecidos. 8.1.1 Mudança desencadeia Há muitas coisas que podem desencadear uma mudar na Operação de Serviço ambiente. Estes incluem: • Hardware novo ou atualizado ou rede componentes • Novo ou atualizado aplicaçãos software • Novo ou atualizado sistema software (sistemas operacionais, utilitários, middleware etc, incluindo patches e correções de bugs • Mudanças de conformidade, Legislativo ou governança • Obsolescência - alguns componentes podem se tornar obsoletos e exigem substituição ou deixar de ser apoiada pelo fornecedor/ Mantenedor • Imperativo do negócio - você tem que ser flexível para trabalhar em ITSM, particularmente durante a Operação de Serviço, e haverá muitas ocasiões em que as necessidades do negócio de TI muda para atender negócios dinâmico exigências • Melhorias para processos, procedimentos e / ou subjacente ferramentas para aprimorar a entrega ou reduzir financeira custars • Mudanças de gestão ou pessoal (que vão desde perda ou transferência de indivíduos para a direita através de importantes aquisições de empresas ou aquisições) • Mudança de nível de serviços ou em serviço prestação - terceirização, In- sourcing, parcerias, etc 8.1.2 Avaliação de Mudança Operação de Serviço equipe deve estar envolvida na avaliação de todas as mudanças de assegurar que operacional questões sejam plenamente tidas em conta. Esse envolvimento deve começar o mais cedo possível (ver ponto 4.6.1) não apenas nas fases posteriores do mudar - Ou seja, a adesão CAB e ECAB - época em que muitas decisões fundamentais foram feitas e influência é provável que seja muito limitado. O Gerente de Mudanças deve informar todas as partes afetadas da mudança que está sendo avaliada para entrada pode ser preparados e disponíveis antes das reuniões do CAB. No entanto, é importante que o pessoal de operação de serviço estão envolvidas nestas últimas fases em que possam estar envolvidos na execução efectiva e ITIL V3 - Operação de Serviço - Página: 313 de 423
    • eles desejar assegurar que a programação é realizada cuidado para evitar contentions potenciais ou períodos particularmente sensíveis. 8.1.3 Medição de mudança bem sucedida A última medida de sucesso em matéria de alterações feitas Operação de Serviço é que clientes e usuários não sentir qualquer alteração ou interrupção do serviço. Na medida do possível, os efeitos das mudanças deve ser invisível, para além de qualquer funcionalidade melhorada, qualidade ou poupança financeira resultante da mudança. ITIL V3 - Operação de Serviço - Página: 314 de 423
    • 8.2 Operação de Serviços e Gerenciamento de Projetos Porque Operação de Serviço é geralmente visto como 'business as usual' e muitas vezes focada em executar procedimentos definidos de uma forma padrão, há uma tendência a não usar Projeto Gestão de processos quando eles de fato seria apropriado. Por exemplo, as principais atualizações de infra- estrutura, ou as desenvolvimento de novo ou modificado procedimentos, são tarefas importantes onde Gerenciamento de Projetos formal pode ser usada para melhorar controlar e gerir custars /recursos. Usando o Gerenciamento de Projeto para gerenciar esses tipos de atividade teria as seguintes vantagens: • Os benefícios do projeto estão claramente definidas e acordadas • Há mais visibilidade do que está sendo feito e como está sendo gerenciado, o que torna mais fácil para os outros grupos de TI e do negócio para quantificar as contribuições feitas por operacional equipes • Este, por sua vez, torna mais fácil obter financiamento para projetos que têm sido tradicionalmente difícil justificar o custo • Maior consistência e melhor qualidade • Realização de objetivoS resulta em maior credibilidade para grupos operacionais ITIL V3 - Operação de Serviço - Página: 315 de 423
    • 8,3 Avaliação de risco e gestão na Operação de Serviço Haverá um número de ocasiões em que é imperativo que avaliação de risco a operação de serviço é realizada rapidamente e posta em prática. A área mais óbvio é a avaliação da risco de possíveis mudanças ou Erro Conhecidos (já coberta em outros lugares) mas, além disso Operação de Serviço equipe podem precisar de ser envolvido na avaliação do risco e impacto de: • Falhas ou potenciais falhas - ou relatados por Gestão de Eventos ou Incidente /Gerenciamento de Problemas, Ou avisos levantadas pelos fabricantes, fornecedors ou contratados • Novos projetos que acabará por resultar em entrega ao viver ambiente • Risco ambiental (abrangendo De serviços de TI Continuidade do tipo de riscos para o ambiente físico e localidade, bem como políticos, comerciais ou industriais de relações riscos relacionados) • Fornecedores, especialmente quando novos fornecedores estão envolvidos ou onde o serviço chave componentes estão sob a controlar de terceiros • Os riscos de segurança - tanto teórico ou real decorrente de segurança incidentes relacionados ou eventos • Novo clientes / serviços a serem apoiadas ITIL V3 - Operação de Serviço - Página: 316 de 423
    • 8,4 pessoal operacional em Design de Serviços e Transição Todos os grupos de TI estarão envolvidos durante Design de Serviços e transição de serviço para assegurar que novos componentes ou serviços são projetados, testados e implementados para fornecer os níveis corretos de funcionalidade, usabilidade,disponibilidade,capacidade, Etc Além disso, o pessoal Operação de Serviço devem estar envolvidos, durante os estágios iniciais de Design de Serviços e Transição de Serviço para garantir que quando chegar a novos serviços viver ambiente eles são apto para o efeito, A partir de uma perspectiva de operação de serviço, e são "suportável" no futuro. Neste contexto, "suportável" significa: • Capaz de ser suportado a partir de um ponto de vista técnico e operacional de dentro de adicional existente, ou pré-acordo recursos e os níveis de qualificação • Sem impacto adverso sobre trabalho existente outro técnico ou operacional práticas, processos ou horários • Sem qualquer inesperado custo operacionals ou despesas de apoio em curso ou escalada • Sem quaisquer complicações inesperadas contratuais ou legais • Nenhum complexos caminhos de apoio entre os departamentos de apoio múltiplas organizações de terceiros. Nota: Mudar não é apenas tecnologia. Também requer a conscientização, treinamento, mudança cultural, as questões motivacionais e muito mais. Mais detalhes sobre maior gestão da mudança são abordados na publicação Transição de Serviço ITIL V3 - Operação de Serviço - Página: 317 de 423
    • 8,5 Planejamento e implementação de tecnologias de gerenciamento de serviços Há uma série de fatores que as organizações precisam para planejar em prontidão para, e durante desenvolvimento e implementação de ferramentas de apoio, de ITSM. Estes incluem os seguintes. 8.5.1 As licenças O total custar de ITSM ferramentas, em particular a ferramenta integrada que formará o centro do conjunto de ferramentas necessárias, é geralmente determinada pelo número e tipo de usuário licenças que o organização necessidades. Tais ferramentas são muitas vezes vendidos em formato modular, de forma a funcionalidade exata de cada módulo precisa ser bem compreendida e alguns dimensionamento inicial deve ser realizado para determinar quantos - e que tipo - de usuários terão acesso a cada módulo. As licenças estão frequentemente disponíveis nos seguintes tipos (a terminologia exacta pode variar dependendo do software fornecedor). 8.5.1.1 licenças dedicados Para uso por aqueles funcionários que requer o uso freqüente e prolongado do módulo (ex. Service Desk equipe precisaria de uma licença dedicada para usar um Gerenciamento de Incidentes módulo). 8.5.1.2 licenças partilhadas Para o pessoal que fazem uso bastante regular do módulo, mas com intervalos significativos no meio, então normalmente conseguem com uma licença partilhada (por exemplo, terceira linha de apoio funcionários pode precisar de acesso regular a um módulo de Gerenciamento de Incidentes - mas apenas nos momentos em que eles estão ativamente da actualização de um registro de incidente). A proporção de licenças para usuários precisa ser estimado, de modo que o número correto de licenças podem ser comprados - isso vai depender do número de usuários potenciais, a duração dos períodos de utilização e freqüência esperada entre usos para dar uma estimativa de simultaneidade nível. O custo de uma licença compartilhada é geralmente mais caro do que o de licenças dedicadas - mas o custo total é menor do que os usuários estão compartilhando e menos licenças, são necessárias no total. 8.5.1.3 licenças Web ITIL V3 - Operação de Serviço - Página: 318 de 423
    • Normalmente, permitindo alguma forma de 'interface luz' via acesso à web para as capacidades da ferramenta, esta é geralmente adequado para o pessoal que deva acesso remoto, apenas o acesso ocasional, ou o uso de apenas um pequeno subconjunto da funcionalidade (por exemplo, pessoal de engenharia que desejam registrar detalhes de ações tomadas em incidentes ou usuários apenas querendo registrar um incidente diretamente). Licenças web geralmente custam menos do que muitos outras licenças (pode até ser livre com outras licenças!) Ea proporção de uso também é muitas vezes menor - os custos de forma geral são reduzidos ainda mais. Note-se que alguns funcionários podem exigir o acesso a várias licenças (por exemplo, pessoal de apoio podem necessitar de uma licença dedicado ou compartilhado, quando no escritório durante o dia, mas pode ne