Gestão da TI. É proibida a cópia deste conteúdo, no todo ou em parte, sem autorização prévia do autor.

(1)

Gestão da TI

Curso: Sistemas de Informação

Prof.: Luis Claudio dos Santos, M.Sc. claudio@primmoris.com 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. 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

(2)

2

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.

(3)

3

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

(4)

4

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

(5)

5

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.

(6)

6

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

(7)

7

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

(8)

8

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.

(9)

9

3. CENTRAL DE SUPORTE

3.1. Objetivos

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

(10)

10

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.

(11)

11

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.

(12)

12

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.

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. GERENCIAMENTO DE INCIDENTES • Detecção do Incidente; • Registro de Incidente; • Classificação; • Priorização;

• Suporte Inicial (1º, 2º nível, etc); • Restauração do Serviço; • Fechamento. Usuário acessa a central de serviço através do SPOC. Incidente Geração de

(13)

13

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.

(14)

14

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 sub‐ processos 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.

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 infra‐ estrutura. A saída deste sub‐processo é uma requisição de mudança (RDM) na infra‐ estrutura. Neste ponto, o processo de gerenciamento de problema ativa o processo de gerenciamento de mudança. 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. Problema reportado. Erro aceito. Requisição de

(15)

15

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.

(16)

16

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.

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 GERENCIAMENTO DE MUDANÇAS • 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. Requisição de Mudança. Mudança aprovada. Relatório do Comitê de Mudança.

(17)

17

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

(18)

18

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.

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. GERENCIAMENTO DE LIBERAÇÃO • 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 aprovada. Mudança liberada na infra‐estrutura.

(19)

19

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.

(20)

20

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. 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. 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 Projeto Inicial Mudança Liberação B S D D H D

(21)

21

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

(22)

22

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.

(23)

23

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. 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. 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 Requisição de Nível de Serviço Nível de Serviço Implementado

(24)

24

• CAs – Contratos de Apoio

Com um fornecedor externo ou terceiro que está sendo envolvido na entrega de serviços deverá haver um contrato que garanta que ele fornecerá o serviço dentro de um prazo, custo, nível, de acordo com os ANSs acordados na organização.

• Catálogo de Serviço

Este documento contém os serviços que estão sendo fornecidos, assim como sua descrição, níveis, custo, cliente e a pessoa/departamento responsável pela manutenção do serviço. O que não estiver no catálogo, em princípio, não poderá ser cobrado do provedor de TI.

11.3. Indicadores de Desempenho (KPIs)

• Há serviços prestados que não estão no catálogo de serviços? • Todos os serviços do catálogo possuem um ANS? • Os indicadores de desempenho dos serviços estão sendo medidos?

(25)

25

12. Gerenciamento da Disponibilidade (Avaiability Management)

12.1. Objetivos

O objetivo deste processo é planejar e gerenciar a disponibilidade dos serviços de TI. Para tanto é necessário que o catálogo de serviço esteja pronto e, para cada serviço, os itens de configuração que podem afetar a disponibilidade devem ser conhecidos.

12.2. Entradas, Atividades e Saídas

A partir de informações da Central de Serviços, este processo pode conhecer os itens que mais têm afetado a disponibilidade de um serviço. A atividade de planejamento da disponibilidade busca equacionar questões como decidir entre esperar 90% de disponibilidade em vez de 99.9%, se isso for adequado para o negócio. A partir desta necessidade, este processo precisa identificar os principais itens de configuração responsáveis pela indisponibilidade dos serviços a fim de decidir sobre as mudanças que terão impacto positivo na disponibilidade.

12.3. Indicadores de Desempenho

• Tempo médio entre falhas de um serviço (TMEF); • Tempo médio para reparar um serviço (TMPR); • Tempo médio entre incidentes de um serviço (TMIS); • Relatório de incidentes que afetam um serviço por item de configuração. GERENCIAMENTO DA DISPONIBILIDADE • Determinar os requisitos; • Planejar a disponibilidade; • Implementar a disponibilidade; • Monitorar. Plano de Disponibilidade Requisitos dos ANSs Requisição de Mudança

(26)

26

13. Gerenciamento da Capacidade (Capacity Management)

13.1. Objetivos

O objetivo principal do Gerenciamento da Capacidade é entender os requisitos de capacidade do negócio e controlar a entrega desta capacidade no presente e no futuro. Este processo deve conhecer a capacidade que o provedor de TI tem de entregar serviços. A falta do processo de gerenciamento da capacidade pode gerar incidentes ou problemas de disponibilidade. Para que a TI possa ser impulsionadora do crescimento do negócio ‐ e nunca um gargalo ‐ o processo de gerenciamento da capacidade precisa se antecipar às demandas futuras e implementar processos que permitam uma utilização eficiente dos meios que a empresa possui.

13.2. Entradas, Atividades e Saídas

Este processo pode, por exemplo, executar ações com o objetivo de utilizar melhor a capacidade atual ao invés de aumentá‐la. O comportamento do usuário pode ser influenciado, por exemplo, para que ele use determinados recursos da TI em horários distintos. Através de simulação ou com auxílio de modelos matemáticos é possível a predição dos requisitos futuros da capacidade. Os resultados desta atividade podem ser usados como uma entrada no Plano de Capacidade.

13.3. Indicadores de Desempenho

• Tempo de downtime por serviço; • Tempo de recuperação após incidente; • Disponibilidade dos serviços. GERENCIAMENTO DA CAPACIDADE • Gerenciar a capacidade do negócio; • Gerenciar a capacidade dos serviços; • Gerenciar a capacidade dos recursos. Necessidades de Negócio Requisição de Mudança Relatórios e Planos de Capacidade

(27)

27

14. Gerenciamento da Continuidade (Continuity Management)

14.1. Objetivos

Este processo não tem como o objetivo cuidar de questões de disponibilidade. O processo de Gerenciamento da Continuidade lida com questões que possam afetar a continuidade do negócio, ou dos serviços chave dos quais o negócio depende, devido a questões de força maior ou eventos graves, tais como incêndios, roubos ou furtos, terremotos, furacões, epidemias, etc. Normalmente o investimento e a preocupação com este processo vêm depois de todos os outros processos.

14.2. Entradas, Atividades e Saídas

A principal entrada é a necessidade de continuidade do negócio e a principal saída é o Plano de Continuidade.

(28)

28

15. Gerenciamento Financeiro da TI

15.1. Objetivos

O Gerenciamento Financeiro é implementado para que a TI possa recuperar os custos do fornecimento de serviços. É preciso ficar claro para o usuário e para o cliente os custos do trabalho da TI. Através deste processo é possível influenciar a demanda por serviços elevando os custos dos serviços de acordo com critérios como horário, qualificação do profissional envolvido, custos dos equipamentos, etc.

15.2. Indicadores de Desempenho

• Os clientes consideram os métodos de cobranças adequados? • A organização de TI consegue atingir os objetivos financeiros? • O uso dos serviços pelos clientes sofre modificações?

(29)

29

16. ANEXOS

16.1. Matriz Impacto versus Prioridade

A prioridade que damos a alguma questão depende basicamente de dois parâmetros: do impacto (importância) e à urgência. Um exemplo clássico de impacto versus urgência é o caso de um gerente que está sentado à sua mesa no momento em que o telefone toca e – simultaneamente – a secretaria lhe avisa que o diretor o está aguardando na sala de espera. Óbvio, não atender o Diretor é algo que tem impacto muito mais alto do que não atender o telefone. Porém, o telefone muito provavelmente será atendido primeiro, pois normalmente acaba sendo visto como algo mais urgente. A filosofia relacionada a impacto e urgência é algo muito estudado em cursos de administração do tempo: O que devemos fazer primeiro? Enfim, a ITIL indica a matriz Impacto versus Urgência abaixo: Impacto ALTO MÉDIO BAIXO

Urgênci a ALTA

1

2

3

MÉDIA

2

3

4

BAIXA

3

4

5

Figura 4: Tabela para cálculo de prioridade com base no impacto e na urgência. Como resultado, a prioridade irá variar entre 01 (alto impacto e alta urgência) a 05 (baixo impacto e baixa urgência). Esta matriz é usada principalmente pelos processos de Gerenciamento de Mudanças, assim como pelos processos de Gerenciamento de Incidentes e Gerenciamento de Problemas a fim de definir o que fazer primeiro.

16.2. Indicadores de Desempenho (KPI)

KPI é uma sigla em inglês para indicadores chave de desempenho (Key Performance Indicator). Todo processo visa à melhoria contínua. Não há como melhorar algo se não tivermos um meio de medir o que se quer melhorar. Os indicadores de desempenho são aquilo que se quer medir. Exemplos de indicadores são: • Número de incidentes registrados (por dia, semana, mês, etc); • Quantidade de incidentes relacionados a um determinado serviço; • Número de problemas registrados (por dia, semana, mês, etc); • Quantidade de problemas relacionados a um determinado serviço; • Tempo médio para resolução de incidentes; • Tempo médio para diagnóstico de causa‐raiz de problemas;

(30)

30

• Número de mudanças solicitadas no ano; • Número de mudanças autorizadas no ano; • Quantidade de itens de configuração registrados na BDGC; • Quantidade de serviços em operação na empresa; • Quantidade de serviços para os quais se tem plano de contingência; • Etc. Uma empresa pode tomar como ponto de partida o desafio de diminuir o número de incidentes registrados. Todos os processos possuem seus indicadores de desempenho e é com base nestes indicadores que um processo será melhorado.

16.3. Ciclo PDCA

A finalidade de se implementar um processo na empresa é iniciar o ciclo de melhoria contínua. Implementa‐se a primeira versão do processo, define‐se os indicadores de desempenho, toma‐se as primeiras medidas e, de acordo com a necessidade do negócio, decide‐se o que se quer melhorar. Com base nesta resposta, o processo poderá ser modificado. Deming propôs o ciclo PDCA, também conhecido por ciclo de Deming, como principal método de melhoria contínua baseada em processos. Os quatro estágios chaves do ciclo são: • Planejar (PLAN); • Fazer (DO); • Verificar (CHECK); • Agir (ACT). Na medida em que o ciclo é executado, a empresa vai se tornando mais madura ao longo do tempo. Figura 5: Representação do ciclo de Demming. O ciclo PDCA pode ser usado como ferramenta para melhorar qualquer um dos processos da ITIL, seja ele relacionado ao suporte a serviços ou à entrega de serviços. Na

(31)

31

verdade, este ciclo pode ser usado para melhorar qualquer processo em qualquer área (desde que haja um processo definido, obviamente).

16.4. TNEF, TMPR e TMIS

Estes parâmetros são usados para definir a disponibilidade de serviços. O Tempo Médio Entre Falhas (MTBF – Medium Time Between Failure) é um parâmetro para medir a disponibilidade do serviço. O Tempo Médio Para Reparar (MTTR – Medium Time To Repair) é uma medida da sustentabilidade. Tempo Médio entre Incidentes do Sistema (TMIS) é uma medida de confiabilidade do sistema. TMEF – Tempo Médio Entre Falhas Æ Disponibilidade (Oficiosidade) TMPR – Tempo Médio Para Reparar Æ Sustentabilidade TMIS – Tempo Médio Entre Incidentes Æ Confiabilidade

(32)

32

16.5. Qualidade de Serviço

O que é qualidade? Como se pode medir qualidade? Muitos podem dizer que a resposta a essa pergunta é um tanto quanto abstrata. Ela depende do tipo de serviço prestado, do tipo de empresa provedora do serviço, do tipo de cliente e do tipo de usuário. Existe uma fórmula simples para se chegar a uma resposta com menor probabilidade de erro: Desta fórmula simples, podemos tirar várias conclusões. Um mesmo serviço poderá gerar uma qualidade boa ou ruim, dependendo da expectativa associada. Se você negociar com cliente um valor para os serviços onde esteja previsto alguns dias de indisponibilidade ao longo do ano, o serviço será percebido como muito bom se ele acabar ficando indisponível por apenas algumas horas. Porém, este mesmo serviço será visto como muito ruim se for negociado com algum cliente um valor para um serviço que nunca deverá estar indisponível (aliás, algo que nunca se deve dizer, pois o custo para tal serviço é infinito). Não há como se tirar absolutamente nenhuma conclusão a respeito da qualidade de um serviço, se o nível de serviço que o provedor é capaz de oferecer não for previamente alinhado à expectativa do cliente. Qualidade = Nível do Serviço – Expectativa do Cliente e do Usuário

(33)

33

Luis Claudio dos Santos atua há mais de 10 anos na área de TI, em órgãos do governo e em empresas privadas. Foi oficial da Aeronáutica onde trabalhou no Departamento de Controle do Espaço Aéreo (DECEA) e foi responsável pelo desenvolvimento de normas de TI para o Comando. É Mestre em Telecomunicações (PUC-Rio) e pós-graduado em Redes de Computadores (UFRJ). Graduou-se em Engenharia de Computação (ITA). Possui certificações em gerenciamento de projetos (PMP) e gerenciamento de serviços de TI (ITIL). Professor em cursos de graduação e pós-graduação em instituições de ensino superior do Rio de Janeiro e de São Paulo. Também possui certificação em

Coaching conferida pela International Coaching Community (ICC).