Este material foi desenvolvido especialmente para a disciplina Gestão da TI ministrada no curso de graduação em Sistemas de Informação da AES (Academia de Ensino Superior). Algumas imagens são de domínio público e foram obtidas através da Internet. É proibida a cópia deste conteúdo, no todo ou em parte, sem autorização prévia do autor. Gestão da TI Curso: Prof.: Sistemas de Informação Luis Claudio dos Santos, M.Sc. claudio@primmoris.com A ITIL é marca registrada da OGC. OGC é uma marca registrada do Office of Government Commerce. IT Infrastructure Library é uma marca registra pela CCTA. itsmf é uma marca registrada do IT Service Management Forum Ltda
Controle de Alterações Versão 0.9 01/03/2008 Versão resumida e sem revisão do texto. Apenas como primeira leitura para relembrar notas de aula. Contém apenas Introdução, Central de Serviço e Livro de Suporte. Versão 1.0 15/03/2008 Versão completamente revisada definitiva para estudo. Contém todo o conteúdo necessário para estudar para a prova: Introdução à ITIL, Processos de Suporte a Serviços e Processos de Entrega de Serviços. ATENÇÃO Esta é uma versão resumida do conteúdo completo somente para efeitos didáticos. Não é recomendado utilizar somente este material a fim de preparação para a certificação ITIL. 2
Sumário 1. INTRODUÇÃO... 5 2. Terminologia Básica... 7 3. CENTRAL DE SUPORTE... 9 3.1. Objetivos... 9 4. Os Processos de Suporte... 11 5. GERENCIAMENTO DE INCIDENTES (Incident Management)... 12 5.1. Objetivos... 12 5.2. Entradas, Atividades e Saídas... 12 5.3. Indicadores de Desempenho (KPIs)... 13 6. GERENCIAMENTO DE PROBLEMAS (Problem Management)... 14 6.1. Objetivos... 14 6.2. Entradas, Atividades e Saídas... 14 6.3. Indicadores de Desempenho (KPIs)... 15 7. GERENCIAMENTO DE MUDANÇAS (Change Management)... 16 7.1. Objetivos... 16 7.2. Entradas, Atividades e Saídas... 16 7.3. Indicadores de Desempenho (KPIs)... 17 8. GERENCIAMENTO DE LIBERAÇÃO (Release Management)... 18 8.1. Objetivos... 18 8.2. Entradas, Atividades e Saídas... 18 8.3. Indicadores de Desempenho (KPIs)... 19 9. GERENCIAMENTO DA CONFIGURAÇÃO (Configuration Management)... 20 9.1. Objetivos... 20 9.2. Entradas, Atividades e Saídas... 20 9.3. Indicadores de Desempenho (KPIs)... 21 10. Os Processos de Entrega de Serviços... 22 11. Gerenciamento do Nível de Serviço (Service Level Management)... 23 11.1. Objetivos... 23 11.2. Entradas, Atividade e Saídas... 23 11.3. Indicadores de Desempenho (KPIs)... 24 12. Gerenciamento da Disponibilidade (Avaiability Management)... 25 3
12.1. Objetivos... 25 12.2. Entradas, Atividades e Saídas... 25 12.3. Indicadores de Desempenho... 25 13. Gerenciamento da Capacidade (Capacity Management)... 26 13.1. Objetivos... 26 13.2. Entradas, Atividades e Saídas... 26 13.3. Indicadores de Desempenho... 26 14. Gerenciamento da Continuidade (Continuity Management)... 27 14.1. Objetivos... 27 14.2. Entradas, Atividades e Saídas... 27 15. Gerenciamento Financeiro da TI... 28 15.1. Objetivos... 28 15.2. Indicadores de Desempenho... 28 16. ANEXOS... 29 16.1. Matriz Impacto versus Prioridade... 29 16.2. Indicadores de Desempenho (KPI)... 29 16.3. Ciclo PDCA... 30 16.4. TNEF, TMPR e TMIS... 31 16.5. Qualidade de Serviço... 32 4
1. INTRODUÇÃO A ITIL se refere a um conjunto de boas práticas de TI que pode ser adaptado para as necessidades de cada empresa. A ITIL é escalável, ou seja, pode ser aplicada a qualquer tipo de empresa independente de seu tamanho. A razão principal da adoção de boas práticas é a construção e adoção de processos visando melhoria contínua. No caso da ITIL o foco é a criação de processos de Gerenciamento dos Serviços de TI. Os processos descritos na ITIL estão em conformidade com o British Standards Institution s Code of Practice for IT Service Management, de onde a ITIL foi baseada. O OGC (Office of Government Commerce) é o mantenedor da ITIL e o itsmf é o fórum homologado pelo OGC para discutir as melhores práticas e fomentar o crescimento da ITIL em todo o mundo. A versão 2 da ITIL foi finalizada e divulgada no ano de 2000 e é composta por 07 livros. Neste curso, vamos estudar apenas 02 destes livros, que são os livros: Suporte a Serviços (Service Support) e Entrega de Serviços (Service Delivery). O livro de Suporte contém processos de nível OPERACIONAL e o livro de Entrega contém processos de nível TÁTICO. A imagem abaixo representa os 07 livros da ITIL e demonstra que os livros de suporte e entrega são livros relacionados ao Gerenciamento de Serviços em TI (Service Management) que, como já dissemos, é foco principal da adoção dos processos da ITIL. 5 Os processos Operacionais contidos no livro de Suporte são:
Gerenciamento de INCIDENTES; Gerenciamento de PROBLEMAS; Gerenciamento de MUDANÇAS; Gerenciamento de LIBERAÇÃO; Gerenciamento da CONFIGURAÇÃO. Os processos Táticos contidos no livro de Entrega são: Gerenciamento de NÍVEL DE SERVIÇO; Gerenciamento de CONTINUIDADE; Gerenciamento de CAPACIDADE; Gerenciamento de DISPONIBILIDADE; Gerenciamento FINANCEIRO DA TI. Atualmente a TI possui vários desafios. Um dos principais é o alinhamento dos serviços prestados pela TI com as necessidades do negócio. A TI precisa entender de negócios para poder tomar decisões de investimentos levando em conta os objetivos estratégicos da empresa. Qualquer esforço relacionado à Tecnologia da Informação deve gerar bons resultados para o negócio. Por outro lado, aumenta cada vez mais a dependência dos negócios com relação à TI. Se alguns serviços prestados pela TI param, muitas operações da empresa também acabam parando. Óbvio que isso pode variar de negócio para negócio, mas, quanto mais moderno e lucrativo o negócio se torna, mais ele depende de tecnologias e, como conseqüência, mais ele depende da própria TI. 6 Outro fator importante é que o ambiente de TI vem se tornando cada vez mais complexo. O número de soluções, produtos e fornecedores aumenta a cada dia, fazendo com que a vida do gestor de TI se complique. A redução de custos também é sempre uma necessidade. Se por um lado o ambiente fica cada vez mais complexo, as organizações dependem cada vez mais da TI e o investimento em TI precisa sempre gerar retorno, por outro, a redução de custos sempre é mencionada! Ou seja, a TI precisa ter meios para justificar seus investimentos. Manter a segurança sobre as Informações também possui grande relevância para os gestores de TI e a organização proposta pela ITIL possui efeitos diretos de curto prazo relacionados à segurança da informação, assim como efeitos indiretos de médio e longo prazo. No mínimo, haverá um ambiente mais controlado onde qualquer nova implementação visando segurança será mais facilmente incorporadas ao ambiente. Finalmente, a conformidade com leis e regulamentos no século XXI tem sido um dos maiores impulsionadores das boas práticas em qualquer área. Construir e manter processos exige muito esforço. As vantagens e razões que justificam tal investimento nem sempre são claras na cabeça de diretores e presidentes. Algumas leis, como a Sarbanes
Oxley, a Basiléia, etc, têm cumprido um papel importante no sentido de regular e acelerar a adoção de normas e boas práticas no ambiente de TI. A ITIL se tornou padrão de fato e é utilizada por mais 10.000 empresas em todo o mundo. Ela é composta por um conjunto de processos vistos como um consenso na área de TI já testados e aprovados por várias empresas. Os processos da ITIL são compatíveis com a norma ISO 20.000 de Gerenciamento de Serviços de TI criada em dezembro de 2005. A ISO 20.000 é voltada para empresas prestadoras de serviços, que tem como foco avaliar a conformidade dos processos da empresa com as práticas sugeridas. 2. Terminologia Básica Alguns termos merecem esclarecimento, pois deverão ser utilizados ao longo do curso de acordo com o que é definido na ITIL. Ressalte se que o que está no livro da ITIL é o padrão de mercado aceito mundialmente. A ITIL é um conjunto de livros que contém boas práticas. Boas práticas são práticas já testadas e aceitas no mercado como o melhor caminho a ser seguido para se ter sucesso em uma determinada área. As boas práticas são recomendações, não exigências. Uma norma, por exemplo, contém requisitos que devem ser seguidos em sua totalidade. A ITIL não é uma norma. Um exemplo de norma relacionada a Gerenciamento de Serviços de TI é a norma ISO 20000. Ela contém mais de 150 requisitos que devem ser seguidos, todos, pelas empresas certificadas. Outro exemplo, é a norma ISO27001. Um processo é um conjunto de atividades executadas sequencialmente de acordo com procedimentos estabelecidos pela organização com o objetivo de gerar um ou mais resultados as saídas a partir de uma ou mais necessidades geradas pela organização as entradas. 7 ENTRADA SAÍDA Figura 1: Exemplo de processo com 05 atividades intermediárias. A figura acima representa um processo genérico que, para gerar a saída desejada a partir de uma entrada, necessita de 05 atividades. Cada atividade é desenvolvida seguindo procedimentos definidos pela organização. E qual é o objetivo de se adotar um processo em qualquer área? Buscar a melhoria contínua. Adotar processos permite à empresa padronizar a forma de se trabalhar, pois a empresa moderna precisa depender de processos e não de pessoas.
Através dos processos, a empresa poderá se tornar mais eficiente. Eficiência é fazer o que deve ser feito de uma maneira melhor (em menos tempo, consumindo menos recursos, etc). Eficácia é simplesmente fazer o que deve ser feito. Considere o exemplo de dois alunos que tiram 10 em uma prova. O aluno A estudou 02 horas em casa e o aluno B precisou estudar 10 horas. Ambos foram plenamente eficazes, pois resolveram todas as questões, mas o aluno A foi muito mais eficiente que o aluno B. Um processo será mais ou menos eficiente dependendo das atividades que contiver e das regras associadas a tais atividades. O aluno B poderá notar que uma atividade importante que falta em seu processo é: Assistir às aulas. Alguns procedimentos associados a esta atividade podem ser: Prestar atenção ao que o professor fala. ; Fazer anotações. ; Fazer perguntas para esclarecer dúvidas. ; etc. Por outro lado, o que acontece se não há processos na empresa? Cada pessoa trabalha da forma que acha ser correto e cada um terá o seu método mais correto que nem sempre será o melhor método para a empresa. Outra definição importante é a definição de usuário e de cliente. Usuários são aqueles que utilizam o serviço e clientes são aqueles que pagam pelo serviço. No caso de um pet shop, o usuário pode ser um cão ou um gato, mas o cliente será o dono do animal. No nosso caso de TI, nem sempre o cliente é o usuário em si. 8
3. CENTRAL DE SUPORTE 3.1. Objetivos A Central de Suporte não é um processo da ITIL. Ela é uma função desempenhada por uma ou mais pessoas. Um exemplo de Central de Suporte é o Call Center existente em muitas organizações com foco em receber e registrar chamadas telefônicas de usuários. O maior objetivo da Central de Suporte é implantar um ponto único de contato entre os usuários e o provedor de TI. A ITIL usa o termo SPOC (Single Point of Contact) para designar este ponto que é, na verdade, um número de telefone 0800, um email de suporte, uma página de abertura de chamado que pode ser acessada via browser, etc. No curto prazo, a adoção do SPOC deve gerar reatividade por parte dos usuários, mas, a médio e longo prazo, irá gerar maior eficiência na prestação de serviços. A implantação da Central de Suporte é o primeiro passo dentro de um projeto de práticas para Gerenciar os Serviços de TI com base na ITIL. Sem a central, é impossível implantar os processos essenciais do livro de suporte da ITIL (Problemas, Incidentes, Mudanças, Liberação e Configuração). 9 Alguns objetivos secundários da Central de Suporte são: Ser o ponto único de acesso entre o usuário e o provedor de TI (SPOC); Registrar todos os incidentes; Dar suporte à implantação do processo de Gerenciamento de Incidentes; Dar suporte à implantação de outros processos da ITIL. O processo de Gerenciamento de Incidentes é o primeiro processo implementado dentro da central. Dependendo do porte da empresa, a central pode se chamar: o Central de Chamados (Call Center): atende a um grande volume de chamados sem, necessariamente, prestar algum suporte inicial (o processo de Gerenciamento de Incidentes não é implementado dentro dela); o Central de Suporte (Help Desk): integra o processo de Gerenciamento de Incidentes com foco em resolver incidentes básicos prestando o suporte de 1º ou de 2º nível; o Central de Serviços (Service Desk): integra outros processos além do Gerenciamento de Incidentes.
As pessoas que trabalham na central precisam ter habilidades de relacionamento interpessoal, tais como ser paciente, comunicativo, assertivo e empático a fim de lidar diretamente com o usuário. Obviamente, dependendo do caso, também será necessário possuir conhecimento técnico especializado (equipes de suporte de 2º e 3º níveis). Para o suporte de 1º nível, as habilidades interpessoais não técnicas são essenciais e mais importantes que o conhecimento técnico, haja visto que o suporte inicial prestado se resumirá a aplicar soluções de contorno conhecidas e simples ou atender a requisições de serviços tais como responder a dúvidas administrativas dos usuários, alterar informações de cadastro, etc. 10
4. Os Processos de Suporte Costuma se dizer que estes são processos OPERACIONAIS. O principal objetivo deles é restabelecer a operação do serviço o mais rapidamente possível para o usuário. 11
5. GERENCIAMENTO DE INCIDENTES (Incident Management) 5.1. Objetivos Este processo tem como objetivo restaurar o serviço o mais rápido possível prestando suporte inicial de 1º, 2º ou 3º nível (depende do porte da empresa) aplicando uma solução de contorno conhecida durante o primeiro contato do usuário, se possível. 5.2. Entradas, Atividades e Saídas A principal entrada deste processo é o chamado do usuário relacionado à indisponibilidade total ou parcial de um serviço. A principal saída é o incidente contornado a partir da aplicação de uma solução de contorno conhecida e a aprovação do usuário com relação ao seu restabelecimento. É importante ressaltar que é o usuário quem fecha o incidente. GERENCIAMENTO DE INCIDENTES Usuário acessa a central de serviço através do SPOC. Detecção do Incidente; Registro de Incidente; Classificação; Priorização; Suporte Inicial (1º, 2º nível, etc); Restauração do Serviço; Fechamento. Incidente Geração de 12 Este processo é normalmente é implantado dentro da própria central de suporte. Vale ressaltar que o gerenciamento de incidentes é um processo REATIVO, ou seja, busca soluções de contorno para incidentes de acordo com as requisições dos usuários. O resultado principal da adoção deste processo é fazer com que pequenos incêndios do dia a dia de TI sejam contornados rapidamente sem o envolvimento da equipe de TI de mais alto nível. O termo formal utilizado pela ITIL é Incidente. Qual seria a diferença entre incidente e problema? Para a ITIL, ambas são ocorrências que causam interrupção total ou parcial do serviço. Porém, o incidente possui uma solução de contorno conhecida e o problema não. O que acontece se há muitos incidentes e recursos limitados para resolver? Vimos que uma das atividades deste processo é a priorização. Ao priorizar os incidentes, a equipe poderá ordenar o agendamento da solução, principalmente nos casos em que o incidente necessitar de alguma atuação de 2º ou 3º nível.
O procedimento relacionado ao cálculo da prioridade está relacionado à combinação de dois fatores: impacto * Urgência. Prioridade = Impacto * Urgência. Impacto = é o efeito do incidente no negócio; Urgência = tempo máximo para que o incidente seja resolvido. 5.3. Indicadores de Desempenho (KPIs) Número de incidentes, por área de negócio, departamento, natureza, etc; Quantidade de incidentes resolvidos por operador; Porcentagem de incidentes resolvidos usando a BDGC. 13
6. GERENCIAMENTO DE PROBLEMAS (Problem Management) 6.1. Objetivos Podemos dizer que há dois objetivos principais neste processo. Na verdade, muitos dizem que o processo de gerenciamento de problemas se divide em dois subprocessos que podem ser definidos de acordo com estes dois objetivos: 1º Encontrar a causa raiz de problemas; 2º Gerenciar o erro conhecido relacionado à causa encontrada. 6.2. Entradas, Atividades e Saídas A principal entrada é o registro de um problema na BDGC gerado por um incidente cuja solução de contorno não é conhecida. A principal saída é uma requisição de mudança na configuração da infra estrutura de TI. Problema reportado. GERENCIAMENTO DE PROBLEMAS Registro de Problema; Classificação; Priorização (urgência versus impacto); Identificação da causa raiz do problema; Gerar requisição de mudança (erradicar); Ação proativa evitando recorrência dos mesmos incidentes; Ação proativa evitando recorrência dos mesmos problemas. Erro aceito. Requisição de 14 Não há como implantar o gerenciamento de problemas, sem que antes o processo de gerenciamento de incidentes tenha sido implantado. A qualidade das informações geradas durante o tratamento inicial do incidente será decisiva para a agilidade do processo de identificação da causa raiz. Investigação da Causa Raiz: A entrada deste sub processo é o registro de um problema vindo do processo de gerenciamento de incidente. A saída deste sub processo é a causa raiz identificada. Controle de Erros: A entrada deste sub processo é um erro identificado, ou seja, a causa raiz descoberta passa a ser vista agora como um erro conhecido na infraestrutura. A saída deste sub processo é uma requisição de mudança (RDM) na infraestrutura. Neste ponto, o processo de gerenciamento de problema ativa o processo de gerenciamento de mudança.
O gerenciamento de problema deve ser tanto REATIVO quanto PROATIVO. No início, este processo tende a ser muito mais reativo, apenas atendendo aos problemas gerados pelos incidentes que deram entrada na central de suporte. Com o amadurecimento dos processos, cada vez menos incidentes e problemas serão gerados. Com isso, a equipe de gerenciamento de problemas começará a ter tempo de agir de forma proativa buscando identificar os fatores que geram a recorrência de problemas e incidentes e os eliminando. Ou seja, pode se dizer que este processo começa na proporção 80% reativo e 20% proativo e, com o tempo, se aproxima cada vez mais da proporção 20% reativo e 80% proativo. Figura 2: Incidente, que gera um problema, que gera um erro conhecido. ATENÇÃO Um incidente não vira um problema. Ele pode gerar um problema. São registros diferentes na BDGC, porém relacionados. 6.3. Indicadores de Desempenho (KPIs) Número de problemas por estado, classificação, priorização, etc; Ralação do esforço reativo versus esforço proativo da equipe; Tempo médio para encontrar causa raiz de problemas; Número de Requisições de Mudança geradas pelo Controle de Erros; Tempo para solução de problemas versus tempo estimado. 15
7. GERENCIAMENTO DE MUDANÇAS (Change Management) 7.1. Objetivos Gerenciar todas as mudanças na configuração da infra estrutura de TI que possam impactar a habilidade do provedor de TI em prestar serviços. 7.2. Entradas, Atividades e Saídas A principal entrada é uma requisição de mudança que pode vir do processo de Gerenciamento de Problemas ou de qualquer outro processo. A principal saída é a aprovação da mudança ou um relatório do Comitê de Mudança. GERENCIAMENTO DE MUDANÇAS Requisição de Mudança. Registro; Classificação (menor, normal, significativa ou urgente); Priorização (urgência versus impacto); Autorização (avaliação pelo Comitê de Mudança); Elaboração do Plano de Desenvolvimento; Elaboração do Plano de Back Out (retroceder); Revisão e Avaliação. Mudança aprovada. Relatório do Comitê de Mudança. 16 Muitas vezes a indisponibilidade está relacionada a alguma mudança realizada de forma inadequada ou não planejada. Isso acontece porque as mudanças nos levam de um estado atual conhecido (operacional) a um estado desconhecido para o qual temos apenas projeções, expectativas, probabilidades, etc, mas nenhuma certeza. O processo de gerenciamento de mudança tenta diminuir ao máximo os riscos associados de se levar a TI para a nova configuração desejada no estado pretendido. Figura 3: Processo de mudança nos faz mudar para um estado desconhecido. Vale ressaltar que o processo de gerenciamento de mudanças é responsável apenas por decidir e coordenar as mudanças. Ele não tem como objetivo executar a mudança propriamente dita. A execução será realizada por uma equipe técnica
responsável pela área da mudança (área de redes, desenvolvimento, etc) dentro do processo de liberação. Mudanças muito simples, tais como alteração de senha, de login, etc, não devem fazer parte do escopo deste processo, pois isso seria altamente ineficiente. Dentro deste processo, alguns termos utilizados são: o RDM Requisição de Mudança (ou RFC Request for Change): É a documentação com os detalhes da mudança solicitada; o PFM Programação de Mudança Futura (ou FSC Foward Schedule of Changes): É a agenda de mudanças aprovadas cuja implementação está programada para uma data futura (dependendo de disponibilidade de orçamento, sincronização de disponibilidade da equipe, etc). Este processo se relaciona diretamente com o processo de gerenciamento da liberação, pois a saída do processo de mudança (caso aprovada) é a entrada para o processo de liberação. Algumas mudanças significativas implicam grandes orçamentos, prazos relativamente longos e escopos muito abrangentes. Nestes casos, a ITIL recomenda que as mudanças sejam tratadas como um projeto na organização. Assim como existem os frameworks de boas práticas em gerenciamento de serviços de TI (como a ITIL), existem frameworks de boas práticas para gerenciamento de projetos. 17 O maior exemplo na atualidade é o livro denominado PMBOK (Project Management Body of Knowledge) do PMI (Project Management Institute). O PMI confere a certificação PMP (Project Management Professional) a profissionais que comprovem pelo menos 4.000 horas em atividades de gerenciamento de projetos e que sejam aprovados na prova de certificação. 7.3. Indicadores de Desempenho (KPIs) Número de requisições de mudanças autorizadas; Número de incidentes relacionados com uma mudança; Número de requisições de mudanças urgentes; Número de requisições de mudanças normais; Número de requisições de mudanças para correção de erro; Número de requisições de mudanças para melhoria na infra estrutura; Etc.
8. GERENCIAMENTO DE LIBERAÇÃO (Release Management) 8.1. Objetivos Executar a liberação (roll out) das mudanças aprovadas pelo Gerenciamento de Mudanças na infra estrutura de TI, principalmente aquelas relacionadas a novas versões de softwares. 8.2. Entradas, Atividades e Saídas A principal entrada é a aprovação de uma mudança relacionada a softwares vinda do processo de Gerenciamento de Mudanças. A principal saída é a mudança implementada na infra estrutura de TI da organização. GERENCIAMENTO DE LIBERAÇÃO Mudança aprovada. Planejamento da Liberação; Desenvolvimento (aquisições, etc); Construção; Teste em ambiente não operacional; Aprovação; Planejamento de Implantação (Roll Out); Comunicação, Preparação e Treinamento; Distribuição e Instalação. Mudança liberada na infra estrutura. 18 Este processo é alimentado pelo processo de gerenciamento de mudanças. O relacionamento entre ambos os processos é tão estreito que muitos dizem que ambos deveriam ser tratados como um só processo. Juntamente com o processo de mudanças, o processo de liberação protege o ambiente de produção. A pressão por realizar mudanças rápidas no ambiente de TI é sempre muito grande. Diariamente surgem promessas de novas soluções, novos produtos, etc, que prometem fazer milagres pela empresa. A maior preocupação do provedor de TI é realizar as mudanças que gerem valor ao negócio sem causar impacto negativo nos serviços. A empresa deve evoluir sem degradar os serviços ou problemas operacionais maiores devido a erros de projeto, excessos de expectativas, promessas infundadas, investimentos desnecessários, etc. As liberações irão alterar a configuração do ambiente de TI. Todas as alterações deverão se refletir na BDGC, que possui uma representação lógica de toda a configuração do ambiente de TI da organização.
No processo de liberação, alguns termos são utilizados: o BSD Biblioteca de Software Definitivo (ou DSL Definitive Software Library). É o local onde são armazenadas as cópias físicas de softwares autorizados; o DHD Depósito de Hardware Definitivo (ou DHS Definitive Hardware Store). É o local onde são armazenados os componentes de hardware em estoque. 8.3. Indicadores de Desempenho (KPIs) Número de liberações implantadas no prazo e orçamento previstos; Número de liberações que resultaram em retrocesso (back out); Número de inconsistências encontradas na BDGC em auditoria; Número de inconsistências encontradas na BDS ou no DHD em auditoria. 19
9. GERENCIAMENTO DA CONFIGURAÇÃO (Configuration Management) 9.1. Objetivos Criar e manter a base de dados de gerenciamento da configuração, a BDGC, que é um modelo lógico da infra estrutura de TI de uma organização. 9.2. Entradas, Atividades e Saídas As principais entradas são a necessidade de se inserir novos registros de Itens de Configuração ou mudanças de estados destes itens (ativo, estoque, etc), gerados principalmente pelo processo de controle de mudanças e liberação. A principal saída é a BDGC atualizada. Projeto Inicial Mudança Liberação GERENCIAMENTO DA CONFIGURAÇÃO Planejamento do Escopo; Definição do Nível de Detalhamento; Identificação de Itens de Configuração; Construção e Alimentação da BDGC; Controle de Estado (ativo, estoque, manutenção, aposentado, etc); Acompanhamento e Auditoria. BDGC B S D D H D 20 Este processo é um processo que suporta todos os outros processos e gera informações utilizadas por eles. É inadmissível se pensar em implantar os processos de gerência de incidentes ou gerência de problema, por exemplo, sem implantar a gerência da configuração. O mesmo vale para todos os outros processos. É extremamente necessário que seja utilizada uma ferramenta com funcionalidades que permitam a interação com um banco de dados e o estabelecimento de relações entre os ICs. Esta ferramenta não é apenas uma ferramenta de inventário de hardware ou de software. ATENÇÃO O principal benefício de ferramentas utilizadas para dar suporte aos processos baseados na ITIL é a capacidade de estabelecer relações entre os diversos ICs.
Os relacionamentos entre ICs existentes na BDGC permitirá encontrar respostas rápidas para questões como: Qual o valor total investido nos PCs em operação na empresa? Quantas vezes um determinado tipo de incidente aconteceu na empresa? Qual o tempo médio para solucionar um incidente de um determinado tipo? Qual dia da semana há mais registro de incidentes? Um determinado serviço depende de quais itens de configuração? Etc. A combinação destas informações irá gerar o conhecimento necessário para que os responsáveis pelo negócio possam tomar decisões estratégicas. O processo de mudança protege a BDGC contra registros redundantes, inconsistência ou falta de informações. Em pequenas ou médias organizações, a função do gerente da configuração, de mudança e de liberação poderá até ser executada pela mesma pessoa. O termo baseline é usado para definir um estado instantâneo da BDGC. Funciona como uma fotografia de um estado da configuração do ambiente de TI em um dado instante que pode servir para reparar uma configuração operacional anterior quando uma mudança implementada for mal sucedida. A BDGC contém a representação lógica de toda a configuração da operação da TI em uma empresa. Esta base de dados é denominada BDGC (Base de Dados de Gerenciamento da Configuração). Os itens armazenados na BDGC são denominados Itens de Configuração (ICs). 21 Exemplos de itens de configuração são: A descrição de um hardware ou software utilizado por um usuário; Um serviço prestado pelo provedor de TI; Informações sobre os usuários, clientes e fornecedores; Informações sobre um incidente ou problema registrado. Etc. ATENÇÃO Não confundir os itens da BSD e da DHD com item de configuração (ICs). Um item de configuração é uma informação lógica armazenada na BDGC. A BSD e o DHD são locais físicos (uma sala ou depósito) que contêm itens físicos (CDs, manuais, componentes de). 9.3. Indicadores de Desempenho (KPIs) Número de incidentes gerados por inconsistência de informações; Número de problemas gerados por inconsistência de informações; # de inconsistências encontradas na BDGC; Etc.
10. Os Processos de Entrega de Serviços Costuma se dizer que estes são processos TÁTICOS. Os processos de entrega procuram manter o melhor equilíbrio entre o esforço e o custo envolvidos na entrega dos serviços com respeito a itens como qualidade, disponibilidade, etc. 22
11. Gerenciamento do Nível de Serviço (Service Level Management) 11.1. Objetivos O principal foco deste processo é assegurar a qualidade dos serviços prestados pela área de TI a um custo aceitável para o negócio. Ele forma o vínculo necessário entre as expectativas dos usuários e clientes e os resultados que o provedor de TI é capaz de entregar. 11.2. Entradas, Atividade e Saídas A principal entrada deste processo é a demanda dos usuários por maior qualidade nos serviços prestados. As principais saídas são o catálogo de serviços, com os indicadores devidos, e o nível de serviço implementado. Requisição de Nível de Serviço GERENCIAMENTO DO NÍVEL DE SERVIÇO Identificação de demanda; Definição do catálogo de serviços; Negociação dos acordos; Monitoração dos níveis de serviço; Revisão. Catálogo de Serviço Nível de Serviço Implementado 23 O processo de gerenciamento de nível de serviço utiliza como ferramentas principais: ANSs Acordos de Nível de Serviço (SLA Service Level Agreement) Os ANS s permitem que o provedor de TI e o cliente decidam sobre que serviços devem ser fornecidos, sobre a disponibilidade necessária e sobre os custos. Estes níveis devem ser mensuráveis para que se possa verificar o cumprimento ou não do acordo. ANO Acordos de Nível Operacional Alguns serviços de TI dependem de outros serviços providos dentro da própria organização por outros departamentos. Acordos internos entre departamentos sobre a disponibilidade destes serviços rede estarão definidos em ANOs. Estes acordos são semelhantes aos ANS s, mas seu foco é voltado para dentro da organização de TI.