Monografia Marden Rolim

5/16/2018 Monografia Marden Rolim - slidepdf.com

http://slidepdf.com/reader/full/monografia-marden-rolim-55ab5175a06f5 1/93

0

UNIÃO EDUCACIONAL MINAS GERAIS S/C LTDAFACULDADE DE CIÊNCIAS APLICADAS DE MINASAutorizada pela Portaria no 577/2000 – MEC, de 03/05/2000BACHARELADO EM SISTEMAS DE INFORMAÇÃO

GERENCIAMENTO DE MUDANÇAS UTILIZANDO OS

PROCESSOS DA ITIL

MARDEN VIANA ROLIM

Uberlândia

2007



1

MARDEN VIANA ROLIM

GERENCIAMENTO DE MUDANÇAS UTILIZANDO OSPROCESSOS DA ITIL

Trabalho de Final de curso submetido à

UNIMINAS como parte dos requisitos para

a obtenção do grau de Bacharel em

Sistemas de Informação.

Orientador: Prof. Dra. Kátia Lopes Silva

Uberlândia

2007



2

MARDEN VIANA ROLIM

GERENCIAMENTO DE MUDANÇAS UTILIZANDO OS

PROCESSOS DA ITIL

Trabalho de Final de curso submetido àUNIMINAS como parte dos requisitos para

a obtenção do grau de Bacharel em

Sistemas de Informação.

Orientadora: Profa. Dr. Kátia Lopes Silva

Banca Examinadora:

Uberlândia, 07 de Julho de 2007.

Prof. Esp. Flamaryon Guerin

Profa. Dra. Kátia Lopes Silva

Prof. Márcio Moreira

Uberlândia

2007



3

Dedicatória

Dedico este trabalho à minha família que me

impulsionou a buscar uma vida nova a cada dia,

meus agradecimentos por terem aceitado privar-

se de minha companhia pelos estudos, concedendo

a oportunidade de me realizar ainda mais.



4

AGRADECIMENTOS

Tenho muito a agradecer a aqueles com quem convivi até hoje e que

me trouxeram até aqui. Mas, neste Trabalho de Final de curso, agradeçoespecialmente a professores, amigos, com quem dividi experiências e idéias.

Em especial à minha namorada Franciele Marques Peres, pela

paciência em tolerar minha ausência.

A orientadora Professora Kátia Lopes Silva pelo incentivo, simpatia e

presteza no auxilio para elaboração e discussões sobre o andamento e

normalização dessa Monografia de Conclusão de Curso.

Especialmente a Professora Ana Maria Árabe, pelo seu espírito

inovador e empreendedor na tarefa de multiplicar seus conhecimentos, pela sua

disciplina nos ensinando a importância do trabalho de pesquisa e pela oportunidade

de participação no projeto de pesquisa desta Monografia.

A todos os professores da UNIMINAS do Curso de Sistemas de

Informação pelo carinho, dedicação e entusiasmo demonstrado ao longo do curso.

E, finalmente, a DEUS pela oportunidade e pelo privilégio que nos

foram dados em compartilhar tamanha experiência e, ao freqüentar este curso,

perceber e atentar para a relevância de temas que não faziam parte, em

profundidade das nossas vidas.



5

RESUMO

Encontrar soluções de Governança de TI acessíveis aos padrões operacionais e

comerciais das organizações brasileiras tem se tornado uma necessidade paravárias organizações. Uma destas soluções é a adoção da metodologia da ITIL que é

utilizada por inúmeras empresas para definirem seus processos internos, criarem

melhores práticas dentro das organizações, ajustarem os departamentos de TI às

necessidades do negócio e reduzirem os custos na gestão da infra-estrutura de TI. É

diante deste cenário que este trabalho faz um estudo sobre todos os processos da

ITIL, detalhando o processo de Gerenciamento de Mudança e através de um estudo

de caso identificando benefícios obtidos após sua implementação. O Processo de

Gerenciamento de Mudança conforme estudo de caso mostrou-se bastante simples

e eficaz, pois sua adoção foi imediata e os resultados obtidos após sua

implementação foram a diminuição da quantidade de incidentes ocorridos dentro da

organização conseqüentemente o aumento do lucro financeiro e a satisfação do

cliente perante estudo de caso apresentado.

Palavras Chave: ITIL, Central de Serviços, Entrega de Serviço, Suporte à Serviço,

Gerenciamento de Mudanças.



6

ABSTRACT

To find accessible solutions of governance of TI to the operational and commercial

standards of the Brazilian organizations if has become a necessity for severalorganizations. One of these solutions is the adoption of the methodology of the ITIL

that is used by innumerable companies to define its internal processes, to create

inside better practical of the organizations, to adjust the departments of TI to the

necessities of the business and to reduce the costs in the management of the TI

infrastructure. It is ahead of this scene that this work makes a study on all the

processes of the ITIL, detailing the process of Change Management and through a

study of case identifying benefits obtained after your implementation. The Process of

Change Management of in agreement case study revealed sufficiently simple and

efficient, because your adoption was immediate and the results obtained after your

implementation had been the reduction of the amount of incidents occurred inside of

the organization consequently the increase of the financial profit and the satisfaction

of the customer before study of presented case.

Keywords: ITIL, Service Desk, Service Delivery, Service Support, Change

Management.



7

LISTA DE FIGURAS

Figura 1. Frameworks e metodologias que contêm boas práticas para o

Gerenciamento de Riscos. (GHERMANe, 2005) ...............................................16

Figura 2. Processos ITIL. (ITSMF, 2001, p33) .......................................................... 22 Figura 3. Exemplo Central de Serviços em uma empresa X. (Empresa X, 2006).....26 Figura 4. Tipo de Central de Serviço Centralizado. (OGCa, p. 39) ...........................27 Figura 5. Tipo de Central de Serviço Virtual. (OGCa, p. 40) ..................................... 28 Figura 6. Tipo de Central de Serviço Local. (OGCa, p. 38).......................................29 Figura 7. Progresso do Incidente. (Empresa X, 2006 ) ..............................................32 Figura 8. Progresso do Controle do Problema. (OGC, 2001. p. 101)........................35 Figura 9. Atividades da fase Controle do Problema. (Empresa X, 2006 ) ..................36 Figura 10. Procedimento Gerenciamento de Liberações. (Empresa X, 2006) ..........39 Figura 11. Procedimento Gerenciamento de Configurações. (Empresa X, 2006).....41 Figura 12. Relação entre Cliente / Serviço com o Gerenciamento de Níveis de

Serviço. (OGCb, p. 28).......................................................................................43 Figura 13. Processo de Gerenciamento de Disponibilidade. (OGCb, p. 219). ..........46 Figura 14. Processo de Gerenciamento de Capacidade. (OGCb, p. 124). ............... 48 Figura 15. Processo de Gerenciamento de Continuidade do Negócio. (OGCb, p.

171)....................................................................................................................49 Figura 16. Interligação entre empresa. (Empresa X, 2006 ).......................................50 Figura 17. Processo de Gerenciamento Financeiro para Serviços em TI. (Empresa X,

2006)..................................................................................................................52 Figura 18. Relação dos Processos ITIL. (CA, 2007) .................................................53 Figura 19. Modelo do Processo de Suporte de Serviços (Service Support). (OGCa,

2001, p. 297)......................................................................................................54 Figura 20. Modelo do Processo de Entrega de Serviços (Service Delivery). (OGCb,

2001, p. 361)......................................................................................................55 Figura 21. Entrada e saídas do processo de Gerenciamento de Mudanças. ............59 Figura 22. Limites entre Administração de Mudança e administração de programa. 60 (OGCa, 2001, p. 166)................................................................................................60 Figura 23. Visão Geral do Processo de Gerenciamento de Mudança da empresa X.

(Empresa X, 2006) .............................................................................................67 Figura 24. Fases do processo de mudança. (Empresa X, 2006) ..............................70 Figura 25. Atividades do Planejamento. (Empresa X, 2006).....................................71 Figura 26. Total de mudanças Planejadas e Realizadas por mês no ano de 2006

durante a implantação da ITIL. (Empresa X, 2007)............................................83 Figura 27. Comparação, tipos de Mudança: Emergencial, Programada e Acelerada

no ano de 2006 por mês, durante a implantação da ITIL. (Empresa X, 2007)...84 Figura 28. Comparação, tipos de mudança: Emergencial, Programada e Acelerada

no ano de 2007 por mês, durante a implantação da ITIL. (Empresa X, 2007)...85 Figura 29. Comparação dos Resultados das mudanças: Sucesso, Falha e Cancelada

no ano de 2006 por mês, durante a implantação da ITIL. (Empresa X, 2007)...86 Figura 30. Comparação dos Resultados das mudanças: Sucesso, Falha e Cancelada

no ano de 2007 por mês, durante a implantação da ITIL. (Empresa X, 2007)...87



8

LISTA DE QUADROS

Quadro 1. Tipos de Categorias de Mudanças............................................................68

Quadro 2. Prazos para abertura e aprovação da mudança.......................................69Quadro 3. Classificação de Riscos............................................................................72



9

LISTA DE ABREVIATURAS E SÍMBOLOS

CAB – Change Advisory Board

CCM – Conselho de Controle de MudançasCCTA – Central Computer and Telecommunications Agency (Centro de

Computadores e Agencia de Telecomunicações)

CEO – Chief Executive Officer (Principal Executivo da Organização)

CMDB – Configuration Management Data Base (Banco de Dados do Gerenciamento

da Configuração)

COBIT – Control Objectives for Information and Related Technology (Objetivos de

Controle para Informações e Tecnologia correspondente)

COSO – Committee of Sponsoring Organizations of the Treadway Commission

(Comitê de Organizações Patrocinadoras da Comissão Treadway)

CPU – Central Process Unit (Unidade Central de Processamento)

ERP – Enterprise Resource Planning (Planejamento de Recursos Empresariais)

EXIN - Examination Institute for Information Science

FSC – Forward Schedule of Changes

IC – Configuration Item (Item de Configuração)

IEC – International Electrotechnical Commission (Comissão Eletrotécnicoa

Internacional)

ISEB - Information Systems Examinations Board

ISO – International Organization for Standardization (Organização Internacional para

Padronização)

IT – Information Technology (Tecnologia da Informação)

ITIL – Information Technology Infrastructure Library (Biblioteca de Infra-estrutura de

Tecnologia da Informação)

ITSCM – IT Service Continuity Management (Gerenciamento da Continuidade dos

Serviços em Tecnologia da Informação)

ITSMF – Information Technology Service Management Forum (Fórum de

Gerenciamento de Serviços de Tecnologia da Informação)

KPI – Key Performance Indicators (Indicadores de Desempenho Fundamentais)

NOC – Network Operation Center (Centro de Operações de Redes)

OGC – Office for Government Commerce (Secretaria de Comércio do Governo)



10

OLA – Operational Level Agreement (Acordo de Nível Operacional)

PABX – Private Automatic Branch Exchange (Troca automática de ramais privados)

PFM – Programação Futura de Mudanças

RDM – Requisições de Mudanças

RFC – Request For Change

SC – Service Catalogue (Catalogo de Serviço)

SLA – Service Level Agreements (Acordo de Nível de Serviço)

SW - Software

UC – Underpining Contract (Contratos de Apoio)



11

SUMÁRIO

1 INTRODUÇÃO...................................................................................................13 1.1 CENÁRIO ATUAL ......................................................................................................................13 1.2 IDENTIFICAÇÃO DO PROBLEMA..................................................................................................17 1.3 OBJETIVOS DO TRABALHO .......................................................................................................18

1.3.1 Objetivo Geral...................................................................................................................18 1.3.2 Objetivos Específicos .......................................................................................................18

1.4 JUSTIFICATIVA PARA PESQUISA ................................................................................................19 1.5 ORGANIZAÇÃO DO TRABALHO ..................................................................................................20

2 FUNDAMENTOS EM GERENCIAMENTO DE SERVIÇOS DE TI.....................21 2.1 CENTRAL DE SERVIÇOS (S ERVICE D ESK )..................................................................................25

2.1.1 Central de Serviço Centralizada.......................................................................................27 2.1.2 Central de Serviço Virtual.................................................................................................28 2.1.3 Central de Serviço On Site (Local)...................................................................................29 2.2 SUPORTE DE SERVIÇO (S ERVICE S UPPORT ).............................................................................31 2.2.1 Gerenciamento de Incidentes (Incident Management) ....................................................31 2.2.2 Gerenciamento de Problemas (Problem Management)...................................................33 2.2.3 Gerenciamento de Mudanças (Change Management) ....................................................37 2.2.4 Gerenciamento de Liberação (Release Management) ....................................................38 2.2.5 Gerenciamento da Configuração (Configuration Management) ......................................40

2.3 ENTREGA DE SERVIÇO (S ERVICE D ELIVERY ).............................................................................42 2.3.1 Gerenciamento do Nível de Serviço (Service Level Management) .................................42 2.3.2 Gerenciamento da Disponibilidade (Availability Management)........................................45 2.3.3 Gerenciamento da Capacidade (Capacity Management) ................................................47 2.3.4 Gerenciamento da Continuidade dos Serviços em TI (Service Continuity Management)

48 2.3.5 Gerenciamento Financeiro para Serviços em TI..............................................................51

2.4 EXEMPLO DA RELAÇÃO DOS PROCESSOS .................................................................................53 3 GERENCIAMENTO DE MUDANÇAS................................................................57

3.1 OBJETIVOS .............................................................................................................................57 3.2 DESCRIÇÃO DO PROCESSO......................................................................................................58

3.2.1 Registro de Requisição de Mudanças – RDM .................................................................61 3.2.2 Registro e Classificação ...................................................................................................61 3.2.3 Aprovação.........................................................................................................................61 3.2.4 Coordenação do Desenvolvimento ..................................................................................61 3.2.5 Autorização e Implementação..........................................................................................62 3.2.6 Implementação .................................................................................................................62 3.2.7 Avaliação ..........................................................................................................................62 3.2.8 Comitê de Controle de Mudanças (CCM) ........................................................................62 3.2.9

CCM/CE (Comitê de Emergência) ...................................................................................63

3.2.10 Programação Futura de Mudança (FPM) ....................................................................63 3.2.11 Relacionamentos..........................................................................................................64 3.2.12 Benefícios.....................................................................................................................64 3.2.13 Problemas Comuns......................................................................................................65 3.2.14 KPI - Key Performance Indicators................................................................................66

4 ESTUDO DE CASO EM UMA EMPRESA X .....................................................67 4.1 DESCRIÇÃO DA EMPRESA.........................................................................................................67 4.2 VISÃO GERAL DO PROCESSO DE GERENCIAMENTO DE MUDANÇA ...............................................67 4.3 CATEGORIAS DE MUDANÇAS ....................................................................................................68



12

4.4 PRAZO PARA SOLICITAÇÃO DE MUDANÇAS................................................................................69 4.5 DETALHAMENTO DAS FASES .....................................................................................................69 4.6 PLANEJAMENTO ......................................................................................................................70

4.6.1 Formalização da necessidade:.........................................................................................71 4.6.2 Alternativas não aplicadas:...............................................................................................71 4.6.3 Análise de Impactos: ........................................................................................................72 4.6.4 Determinação das Contingências:....................................................................................73 4.6.5 Plano de “Roll Back”: ........................................................................................................74 4.6.6 Definição do “Check List” de Execução: ..........................................................................74 4.6.7 Definição da “Scalation List”.............................................................................................74 4.6.8 Estimativa de Custos Operacionais:.................................................................................75 4.6.9 Classificação de Resultados ............................................................................................75 4.6.10 Premissas.....................................................................................................................75 4.6.11 Políticas Gerais ............................................................................................................76 4.6.12 Reunião de Mudanças .................................................................................................77 4.6.13 Aprovação e de Acordo................................................................................................77 4.6.14 Feedback das Mudanças.............................................................................................78 4.6.15 Janela Técnica de Mudanças ......................................................................................78 4.6.16 Mudanças de Emergência............................................................................................78 4.6.17 Cronologia das Solicitações de Mudanças ..................................................................78

4.7 PAPÉIS E RESPONSABILIDADES ................................................................................................78 4.7.1 Responsabilidades da área de Tecnologia ......................................................................78 4.7.2 Responsabilidades da área de Engenharia .....................................................................79

4.8 CRONOGRAMA DE IMPLEMENTAÇÃO DA ITIL..............................................................................80 4.9 CUSTO DE IMPLANTAÇÃO DA ITIL ............................................. ................................................81 4.10 CERTIFICAÇÕES ......................................................................................................................81

5 CONCLUSÕES..................................................................................................88



13

1 INTRODUÇÃO

1.1 Cenário Atual

No início dos anos 90, com as demandas de controle, transparência e

monitoração das organizações, surgiu à necessidade da governança de IT –

Information Technology (Tecnologia da Informação). Porém, o crescimento

exuberante da economia mundial acabou “mascarando” a sua necessidade, e com

isso, atrasou por alguns anos a sua implantação nas empresas (MANSUR, 2006).

Na década de 1990 ocorreram importantes transformações no mundo

que apontavam para um período de economias mais abertas. O ressurgimento do

fluxo de capital, a partir de 1990 foi, em parte, reflexo da maior integração financeira

e de um vasto processo de desregulamentação ocorrido tanto nos paísesdesenvolvidos como nos países em desenvolvimento. A queda dos custos de

comunicação e a rapidez de acesso à informação levaram os países industriais a

buscar rendimentos também nos países em desenvolvimento. (TERRA; SOIHET,

2006).

Com as crises internacionais que envolveram México, Ásia, Rússia,

etc; onde escândalos contábeis de super-organizações consideradas até então livres

destes riscos, na segunda metade dos anos 90, o mercado exigiu por transparência,

redução de risco e maior controle. Iniciou–se a instituição de processos e normasque em conjunto foram denominadas de Governança Corporativa. (DOMINGUES,

2004).

Os investidores mudaram o comportamento passando a exigir dos

CEO – Chief Executive Officer (Principal Executivo da Organização) um maior acerto

nas previsões orçamentárias. Assim a partir de 1998 se alavancou as necessidades

de governança corporativa. (MANSUR, 2006).

Em meados de 2002 a governança corporativa tornou se um tema

dominante nos negócios por ocasião da safra de escândalos que aconteceramtambém no início de 2000.

[...] a gravidade dos impactos financeiros desses escândalos solapou a

confiança de investidores tanto institucionais como individuais e sobrelevou

a preocupação com a habilidade e a determinação das empresas privadas



14

de proteger seus stakeholders 1. A crise de confiança do setor corporativo

contribuiu para a pressão descendente nos preços das ações no mundo

todo e especialmente nos Estados Unidos. Nos primeiros seis meses de

2002, o índice S&P 500 caiu 16%; o NASDAQ, com sua ênfase em

tecnologia caiu 36%. O governo dos EUA interveio, e uma nova legislação passou a exigir que os CEOs atestassem pessoalmente a exatidão das

contas das suas empresas e relatassem resultados mais rapidamente.

Simultaneamente, a América corporativa aumentou o nível de

regulamentação. (WEILL; ROSS, 2006, p. 4).

A ocorrência desses fatos mostrou que os grandes investimentos

realizados eram desnecessários, uma vez que empresas com baixo orçamento

administraram os riscos sem interrupção dos serviços, pois elas conheciam o seu

“parque tecnológico”, além de terem feito a gestão dos riscos em função do

conhecimento e análise de impactos (MANSUR, 2006).

Segundo Computer Associates (CA, 2006) os departamentos de TI

devem alinhar seus recursos tecnológicos aos recursos comerciais da empresa e

não serem vistos como centros de custos. Para serem valorizados como tal, a TI

deve fornecer, de forma consistente, serviços que reflitam necessidades estratégicas

do negócio. Os métodos atuais para entrega de serviços às unidades do negócio

estão simplesmente fora da realidade das empresas, onde a mudança é constante,

os recursos são sobrecarregados e as demandas parecem não parar de crescer.

Para ser capaz de enfrentar esses desafios, a TI deve confrontar as limitações

inerentes às próprias operações do negócio e responder com inovações que sejam

tanto eficientes como estratégicas. As necessidades do negócio devem fazer parte

dos processos e modos de operação de TI - caso contrário os departamentos de TI

tornam-se obsoletos perante as exigências dos serviços das empresas.

Os auditores das corporações passaram a adotar algumas

metodologias de governança de TI (em combinação), tais como COBIT - Control

Objectives for Information and related Technology (Controle de Objetivos para

Tecnologia da Informação), devido às suas métricas claras e objetivas, fazendo com

que a governança de TI conseguisse medir o desempenho da área, e também a

_____________ 1 Stakeholders são pessoas que possuem algum tipo de envolvimento profissional ou pessoal com

uma empresa: administradores, funcionários, acionistas, parceiros, clientes, usuários etc. (WEILL;ROSS. 2006. p. 4).



15

metodologia ITIL – Information Technology Infrastructure Library (Biblioteca de Infra-

estrutura de Tecnologia da Informação), com a finalidade de melhorar o

desempenho da área de TI. (MANSUR, 2006).

Corporações passaram adotar também: a metodologia publicada pelo

COSO – Committee of Sponsoring Organizations of the Treadway Commission

(Comitê de Organizações Patrocinadoras da Comissão Treadway ), que identifica os

objetivos essenciais do negócio (financeiro e operacional) de uma dada organização

e define o controle interno e seus componentes, fornecendo critérios a partir dos

quais os sistemas de controle podem ser avaliados. A metodologia utilizada para a

Gestão da Segurança da Informação, a ISO/IEC 17799 tornou-se uma norma

internacional para a segurança da informação baseada na primeira parte da norma

britânica BS 7799. (GHERMANb, 2005). Esta combinação fez com que as empresas de TI estivessem aptas a

atender a gestão de riscos, demanda pelo mercado, e também fez com que fossem

criados ciclos de melhoria de TI, baseando em metodologias consagradas no

mercado (MANSUR, 2006).

Segundo GHERMANb (2005) a seleção de um Framework 2 depende

fundamentalmente, de quais tipos de objetivos a instituição visa alcançar de uma

forma gerenciada, se for voltado para o objetivo do negócio usam COSO, voltado

para objetivos de negócio focando em TI usam COBIT - Control Objectives for

Information and Related Technology (Objetivos de Controle para Informações e

Tecnologia correspondente), voltados para objetivos de Segurança da Informação

usam BS7799 ou ISO 17799, se voltado para Gestão de Serviços em TI usam ITIL.

O papel do Framework independente dos objetivos específicos que

mobilizam a escolha da instituição, o primeiro e mais tangível benefício em

se adotar qualquer dessas estruturas é garantir que haja uma linguagem

comum entre as diversas áreas envolvidas mais diretamente com a gestão

de riscos, geralmente as áreas de Auditoria Interna, Compliance 3 , Risco e a

própria Administração. Como conseqüência, os resultados obtidos para a

definição, avaliação e implementação dos controles internos - elementos

_____________ 2 Sistemas de controle estruturado com elementos de gestão, contendo boas práticas para o

gerenciamento de riscos.3 Compliance, estar em conformidade com as leis, os regulamentos internos e externos e os

princípios corporativos que garantem as melhores práticas de mercado.



16

centrais de todo o processo - podem ser comunicados adequadamente a

partir das camadas estratégicas para as operacionais e vice-versa,

configurando-se essa estrutura (framework) como uma referência global

para o processo de gestão de riscos corporativos. O resultado desse

entendimento contribui positivamente para que todas essas funções desempenhem o seu papel efetivo nesse processo, tornando a gestão de

riscos um verdadeiro pilar para a Governança Corporativa. (GHERMANb,

2005).

Figura 1. Frameworks e metodologias que contêm boas práticas para o

Gerenciamento de Riscos. (GHERMANe, 2005)

A figura 1 mostra todos os Frameworks juntos como um pilar, cada um

desses possuem metodologias próprias, desenvolvidas pelo instituto responsável,

que possibilita introduzir o sistema nas fases de definição avaliação e monitoramento

dos controles internos. Juntos, consistem de boas práticas específicas segundo sua

área e foco permitindo alinhar os objetivos dessas áreas de conhecimento às

estratégias e aos princípios de governança corporativa, garantindo, assim, que os

processos e atividades desempenhadas pelas respectivas áreas e funções

corporativas concorram de forma sistemática para o alcance dos objetivos donegócio e redução dos riscos operacionais. (GHERMANe, 2005).

Este trabalho trata da metodologia ITIL, com ênfase o processo de

Gerenciamento de Mudanças (Change Management ), as melhores práticas

elaboradas, suas características, disciplinas (processos) e certificações.

Atualmente, o processo de Gerenciamento de Mudanças da ITIL,

assegura aos participantes métodos e procedimentos, padronizados que sejam



17

utilizados para a realização eficiente e rápida de todas as alterações. Isto minimiza o

impacto de incidentes relacionados às alterações na qualidade dos serviços.

O que levam as empresas a adotarem tais metodologias são

praticamente em dois aspectos: o cliente ou usuário final, e a organização.

Para o cliente, muitos serviços oferecidos não são atendidos conforme

suas necessidades; não são documentados; e a qualidade e custos, não são bem

gerenciados; outro fator importante, é que a comunicação não é adequada,

causando falta de informação, re-trabalho e perda na satisfação ao negócio.

Para a organização, ineficiência no foco dos objetivos; as mudanças

efetuadas produzem grande impacto no negócio, reduzindo assim a qualidade do

serviço prestado; comunicação interna sem padronização e procedimental.

1.2 Identificação do problema

O Conceito de Governança de TI existe nos negócios quase há tanto

tempo quanto os computadores, mas o interesse e a preocupação generalizados a

seu respeito são bastante recentes, resultando de tendências atuais de negócios

como o comércio eletrônico, a globalização, o Bug do Milênio, a reengenharia dos

processos de negócios, a continuidade de negócio e a transparência dos relatórios

corporativos. (WEILL; ROSS, 2006, p. 23).

A dependência crescente das empresas em relação à informação, a

rápida introdução de novas tecnologias, incluindo os serviços da Web , as

tecnologias móveis e os sistemas empresariais, vem gerando ameaças e

oportunidades estratégicas.

Muitas empresas ou departamentos de TI não adotam nenhuma

metodologia para manter ou melhorar a qualidade do serviço prestado (interna e

externamente), gerando insatisfação e até mesmo a perda de clientes. Portanto, é

muito importante que estas empresas façam investimentos não só em qualidadestécnicas, mas também em habilidades de comunicação, trabalho em equipe,

negociação e foco do cliente, fazendo com que seus profissionais estejam altamente

qualificados para manter alta qualidade nos serviços prestados, satisfazendo, ou até

mesmo superando as necessidades e expectativas dos clientes, acompanhando

assim as melhores práticas do mercado.

A TI deve ser compreendida como uma poderosa ferramenta



18

habilitadora para mudanças na organização; as empresas precisam continuamente

melhorar, navegando em um ambiente de constantes mudanças. Devem ser

flexíveis, adaptativas e fluídas o suficiente para reagirem, ou melhor, se anteciparem

a estas freqüentes mudanças. (TAURION, 2005).

A importância de gerenciar mudanças nas empresas é justamente

permitir que as empresas se adaptem às transformações, controlem os processos e,

assim, obtenham efetivamente os ganhos que esperam assim evitar que os

processos sofram modificações sem controle. A adoção de metodologias para

gerenciar mudanças tem como missão garantir a menor quantidade possível de

impactos de TI, permitindo minimizar possíveis riscos de um projeto ao antecipar os

fatores negativos. (COMPANY WEB, 2004).

1.3 Objetivos do Trabalho

1.3.1 Objetivo Geral

O objetivo deste trabalho é realizar uma pesquisa sobre a metodologia

ITIL, descrevendo a importância da qualidade de serviços e suporte de TI, tendo

como ênfase o Gerenciamento de Mudanças. Isto será mostrado através de um

estudo de caso.

1.3.2 Objetivos Específicos

Para que o Objetivo Geral possa ser realizado tem-se os seguintes

objetivos específicos:

• Descrever a importância da Governança de TI;

• Descrever melhores práticas dos processos da metodologia ITIL

• Descrever os processos de Gerenciamento de Mudanças dentro

da ITIL;

• Identificar o escopo de atuação do Gerenciamento de Mudança;

• Entender a relação entre os outros processos da ITIL;

• Analisar os benefícios após a implantação do Gerenciamento de

Mudanças na organização;

• Analisar os benefícios após a Implantação da metodologia ITIL



19

dentro da organização;

• Apresentar um estudo de caso com foco no Gerenciamento de

Mudança.

1.4 Justificativa para Pesquisa

Um bom planejamento do projeto quantifica o tempo e o orçamento

que um projeto custará. A finalidade do planejamento é criar um plano do projeto

que um gestor de projeto possa usar para acompanhar o progresso de sua equipe.

O que levou o interesse da pesquisa, é que a ITIL hoje, é muito mais

que uma série de livros para auxiliar a empresa no gerenciamento de serviços de TI,

pois conta com aplicações para gerenciamento dos processos, treinamentos,

consultoria, compartilhamento das melhores práticas, entre os “seguidores” dametodologia, certificações e publicações.

Empresas como: os CORREIOS adotaram a metodologia da ITIL e

passaram a usar a Governança de TI como forma de aumentar a qualidade nas

operações de coleta das cartas, triagem e entrega de encomendas; A empresa

Philips Latam, que após uma reestruturação global que determinou a adoção do

modelo de governança e gestão baseada na ITIL, foram implementados os

processos de Incident, Problem, Change, Configuration e SLM Management, que

além de estabelecer os relacionamentos entre todos os macro-processos da ITIL eas interfaces com a Atos-Origin, prestadora de serviços de infraestrutura de TI e

Managed Operations, que utiliza um modelo proprietário fortemente baseado em

ITIL, o Continuous Service Delivery Model (Modelo de Entrega de Serviço Contínuo);

A construtora Norberto Odebrecht é a principal multinacional brasileira no ramo

exportação de serviços. Foi redefinido os processos de relacionamento da área de

infraestrutura de TI com os seus fornecedores e clientes internos, através do uso do

CobiT, como ferramenta de avaliação da maturidade dos processos, e da ITIL como

metodologia a ser adotada na implementação dos processos de TI. Foi estabelecidoo desenho inicial dos macro-processos de Service e Delirery Management da ITIL,

com especial atenção no detalhamento das atividades de Service Desk e Incident

Management, na definição dos principais indicadores de desempenho, e na

construção do Catálogo de Serviços de Infraestrutura de TI.

O Framework ITIL é considerado um padrão a nível mundial,



20

reconhecido e aplicado com sucesso por inúmeras empresas para definição de seus

processos internos, criação de boas práticas dentro das organizações e ajustamento

dos departamentos de TI às necessidades do negócio. Portanto, com a clara visão

de que as organizações estão cada vez mais dependentes de tecnologia da

informação para atingirem seus objetivos de negócios, é necessário também

gerenciar a tecnologia da informação e o relacionamento com os clientes, a ITIL

fornece todas as condições necessárias para que a empresa de TI faça este

gerenciamento com alta qualidade e eficiência.

A importância de estudar a ITIL justifica se pela rapidez em que as

organizações devem responder a qualquer necessidade de mudança dos negócios,

além de possuir altíssima capacidade para se adaptar a essas mudanças sem

causar interrupções nos negócios existentes. (ESPILDORA, 2004).O Gerenciamento de Mudanças tem a finalidade de assegurar que os

processos sofram modificações conforme o planejado e autorizado, garantindo a

menor quantidade possível de impactos, garantindo a identificação dos itens de

configuração envolvidos, procedimentos de mudança testados e garantia de um

plano de recuperação de serviço, caso algum imprevisto venha ocorrer.

(MAGALHAES; PINHEIRO, 2007, p. 70).

1.5 Organização do Trabalho

Este trabalho esta organizado da seguinte forma:

O capítulo 2 descreve os processos da ITIL: A função da Central de

Serviços, Gerenciamento de Incidentes, Gerenciamento de Problemas,

Gerenciamento de Configuração, Gerenciamento de Mudanças, Gerenciamento de

Liberação, Gerenciamento de Níveis de Serviço, Gerenciamento Financeiro,

Gerenciamento de Capacidade, Gerenciamento de Continuidade de Serviço e o

Gerenciamento de Disponibilidade, seguido de exemplos de uma empresa X.

O capítulo 3 descreve especificamente do processo de Gerenciamento

de Mudança, problemas e benefícios de sua implantação.

O capítulo 4 mostra um estudo de caso de uma empresa X,

descrevendo o Gerenciamento de Mudanças, através dos documentos utilizados no

Gerenciamento de Mudanças.



21

2 FUNDAMENTOS EM GERENCIAMENTO DE SERVIÇOS DE TI

ITIL – Information Technology Infrastructure Library (Biblioteca de Infra-

Estrutura de Tecnologia da Informação) é a metodologia para gerenciamento de

serviços em TI mais utilizada e mais conhecida mundialmente, e que um dosprincipais motivos para o surgimento desta metodologia e de seu sucesso é que as

empresas do mundo todo estão cada vez mais dependentes de TI para atingir seus

objetivos e obter resultados. (OGC, 2006).

PNAGE (2005) afirma que no ano 2000, com o intuito de regulamentar

a utilização da ITIL mundialmente foi criada o OGC – Office for Government

Commerce (Secretaria de Comércio do Governo), onde a CCTA – Central Computer

and Telecommunications Agency (Centro de Computadores e Agencia de

Telecomunicações) deixou de existir, passando a se integrar ao OGC, que se tornouproprietário da ITIL.

Segundo ITSMF (2001, p. 5) o ITSMF – Information Technology

Service Management Fórum (Fórum de Gerenciamento de Serviços de Tecnologia

da Informação) é uma organização não governamental (não lucrativa) reconhecida

internacionalmente, dedicada ao gerenciamento de serviços de TI. Ou seja, é a

organização oficial dos utilizadores da ITIL, a qual objetiva compartilhar as melhores

práticas atuais de Gerenciamento de Serviços em TI. O ITSMF implementa isto

organizando conferências, publicando revistas e livros, realizando congressos,

questionando as publicações da ITIL, entre outros, além de ter um importantíssimo

papel no desenvolvimento e gerenciamento de treinamentos e certificações ITIL.

Segundo ITSMF (2001, p. 31) desde a criação da ITIL, foram

publicados aproximadamente quarenta livros relacionados a Gerenciamento de

Serviços em TI. No período do ano 2000 a 2002 o OGC revisou e resumiu estas

publicações em oito livros, sendo eles:

• Service Support (Suporte a Serviços)

• Service Delivery (Entrega de Serviços)

• Planning to Implement Service Management (Planejamento e

Implementação de Gerenciamento de Serviços)

• Application Management (Gerenciamento de Aplicativos)

• Security Management (Gerenciamento de Segurança)

• ICT Infrastructure Management (Gerenciamento de Infra-



22

estruturas de TI e de Comunicações)

• Business Perpective (Perspectiva do Negócio)

• Software Asset Management (Gerenciamento dos Ativos de

Software )Segundo (CAMURUGY, 2005) a ITIL traz algumas mudanças de

paradigma, tais como: faz com que o negócio foque no valor e não no custo; faz

pensar em toda a cadeia que envolve a prestação de serviços (end-to-end service ) e

não uma visão fragmentada; e internamente transfere o olhar para processos e

pessoas e não apenas na tecnologia.

Figura 2. Processos ITIL. (ITSMF, 2001, p33)

A figura 2 mostra os processos do Gerenciamento de Serviços; estão

separados de acordo com a necessidade de suporte ou entrega de serviço, tendo o

Service Desk (Central de Serviço), o ponto único de entrada de chamados e uma

função que permeia todos os processos, ou seja é a única função da ITIL.

A ITIL envolve tantos os aspectos táticos e operacionais, onde no nível

SERVICEDESK

SERVICESUPPORT

SERVICEDELIVERY



23

tático (Entrega de Serviços) os gerentes devem compreender o modelo de gestão

para saberem indicar o caminho a suas equipes. E o lado operacional (Suporte à

Serviços) não fica de fora. Entre os profissionais mais experientes, é comum que

muitas das melhores práticas ditadas pela ITIL já sejam executadas mesmo antes da

sua implantação. Para quem está em início de carreira, o entendimento da ITIL gera

uma visão integrada dos processos de TI e seu alinhamento com o negócio. (TI

MASTER. 2007).

O Gerenciamento de Serviços de TI é um conjunto formado por

pessoas, processos e ferramentas que cooperam para assegurar a qualidade dos

serviços de TI, com suporte a níveis de serviços acordados previamente com o

cliente.

Agrupando as atividades de TI em processos se torna mais fácil ocontrole das atividades, possibilitando a criação de métricas para acompanhamento

da performance. Os processos devem ser bem definidos para buscar a eficiência e

eficácia. Os processos que não são possíveis de monitorar através de indicadores

não são viáveis, de nada vale se você não puder medir o processo.

É necessário levar em conta que a maioria dos benefícios de um

programa de Gerenciamento de Serviços pode levar um tempo para serem obtidos.

Entretanto, há também benefícios em curto prazo. Segundo ESPILDORA (2004) e

CA (2007) os principais benefícios para a empresa de implementar uma metodologiapara o Gerenciamento de Serviços são:

• Melhor qualidade no serviço, com um suporte mais confiável;

• Segurança e confiança da continuidade dos serviços de TI,

dando habilidade para restaurar os serviços quando houver

necessidade;

• Visão mais clara da capacidade atual de TI;

• Fornecimento de informações gerenciais para acompanhamento

de performance, possibilitando traçar melhorias;

• Equipe de TI mais motivada: entendo a carga de trabalho de TI

é possível fazer a gestão de expectativas;

• Gestão mais eficiente da infra-estrutura e dos serviços

prestados;

• Maior satisfação para os Clientes, entregando o serviço com



24

mais qualidade e rapidez;

• Em alguns casos redução de custos: a partir do controle maior e

um melhor planejamento dos custos e processos internos é

possível otimizar os custos operacionais;

• Maior agilidade e segurança para realizar as mudanças

propostas pelo negócio;

• A comunicação se torna mais rápida e dirigida;

• Os processos são otimizados, consistentes e interligados.

• Com processos definidos e controlados é fácil implementar

várias mudanças simultaneamente.

A ITIL é um conjunto de documentos que são utilizados para ajudar a

implementação de um framework para a Gestão de Serviços de TI (ITSM – ITService Management ). Este framework define como é que a Gestão de Serviços é

aplicada dentro da organização. Sendo um framework , é completamente adaptável

para a aplicação em qualquer tipo de negócio ou organização que dependa de TI.

A ITIL não define os processos a serem implantados na área de TI, não

é uma metodologia para implementar processos de Gestão de Serviços de TI – é um

framework flexível que permite adaptar-se para ir ao encontro das necessidades

específicas, demonstra as melhores práticas que podem ser utilizadas para esta

definição. Tais práticas, por sua vez, podem ser adotadas do modo que melhorpuder atender às necessidades de cada organização. Por isto, a ITIL pode ser

empregada por áreas de TI que já possuam processos orientados ao Gerenciamento

de Serviços de TI, orientando os às melhores práticas.

A ITIL não contém mapas detalhados dos processos, a ITIL fornece a

fundação e informação para construir e melhorar os processos;

A ITIL não fornece instruções de trabalho, só a organização sabe como

se trabalha seguindo as melhores práticas fornecidas pela ITIL.



25

2.1 Central de Serviços (Service Desk )

“A Central de Serviços, também conhecida em inglês como Service-

Desk , é uma função dentro da TI que tem como objetivo ser o ponto único de

contato entre os usuários / clientes e o departamento de TI.” (OGCb, 2001, p. 14).

A proposta sugerida é separar dentro das operações de TI quem faz

parte do suporte aos usuários de quem vai realizar atividades de resolução de

problemas e desenvolvimento. Ter uma área específica para o suporte traz

vantagens para os usuários, propiciando um suporte com maior agilidade e

qualidade, e para a equipe de TI mais eficiência, pois o técnico especialista acaba

não sendo mais interrompido pelas chamadas diretas dos usuários.

“Não há nada mais aborrecedor do que você ligar para um número desuporte e passar por várias pessoas e departamentos para poder resolver o seu

problema” (OGCa, 2001, p. 27). Com a Central de Serviços haverá pessoas focadas

em resolver as solicitações dos usuários, evitando colocar os usuários diretos com a

equipe de desenvolvimento.

A Central de Serviços é uma evolução do conceito do Help Desk . Um

Help Desk tradicionalmente atende problemas de hardware e ajuda a softwares

básicos, já a Central de Serviços assume todas as solicitações dos usuários

relacionadas a qualquer serviço prestado pela a área de TI.A Central de Serviços não é um processo dentro da ITIL é uma função.

O Gerenciamento de Serviços de TI está criado em torno da entrega de níveis de

serviços estabelecidos aos usuários finais.

Segundo (OGCa, 2001, p. 48) os objetivos da Central de Serviço são:

fornecer um único ponto de contato com o cliente; facilitar a restauração operacional

do serviço no mínimo impacto para o negócio do cliente dentro dos níveis de

serviços acordados e prioridades ao negócio.

Por exemplo, em uma empresa X (figura 3) do estado de Minas Gerais,que possue clientes da região, clientes do Brasil e internacionais, uma Central de

Serviços funciona como ponto único de contato.



26

Figura 3. Exemplo Central de Serviços em uma empresa X. (Empresa X, 2006)

A figura 3 mostra uma Central de Serviços com várias posições de

atendimento. A empresa X situada no estado de Minas Gerais funciona 24 horas e 7

dias por semana. A infra-estrutura da Central de Serviços possui três camadas

diferentes:

• Nível 1: Suporte por telefone e monitoração de sistemas.

O nível 1 responde todas as chamadas relatadas para o suporte de

TI e Telecom. A ligação deverá ser respondida por um técnico que

tentará monitorar o incidente com o usuário, e se o cliente daempresa X permitir, a solução do incidente através do acesso

remoto no computador do usuário. Se o incidente não for resolvido

durante a ligação, o técnico deverá encaminhar o incidente para o

nível 2 de suporte.

O nível 1 também monitora a infra-estrutura e equipamentos de TI,

tais como: fornecimento de água, energia, ar condicionado, luz e os

sistemas de TI, que deverão ser baseados em procedimentos para

responder aos eventos do nível 1 podendo então a Central deserviços chamar o responsável pelo sistema alarmante. A solução

pode ser encontrada internamente, por parte da equipe de TI do

cliente que contrata os serviços, ou até mesmo por um fornecedor

contratado pela Empresa ou pelo cliente.

• Nível 2: Suporte OnSite (Suporte Local)



27

O nível 2 é solicitado pelo nível 1 para solução de incidentes no

local de trabalho do cliente. O técnico deverá então verificar o

computador do usuário e tentar resolver seu incidente, se a solução

é relatado por algum incidente ou defeito de hardware , o

computador deverá ser substituído e deverá ser restaurada a

operação normal de todos os sistemas.

• Nível 3: Suporte especializado em solução de incidente. O nível

3 é composto por vários técnicos especializados nas áreas de

servidores, telecomunicações, intra-estrutura, cabeamento,

manutenção de aplicações, banco de dados, rede e controle de

acesso.

2.1.1 Central de Serviço Centralizada

Figura 4. Tipo de Central de Serviço Centralizado. (OGCa, p. 39)

A figura 4 mostra o processo de contato entre o cliente e a Central de

Serviços, por exemplo, vários clientes podem ligar na Central de Serviço e informar



28

sobre seus problemas, exemplificando, um erro de acesso a uma determinada

aplicação, a Central de Serviço por sua vez, através de um software de conexão

remota, conecta na máquina do usuário, identifica o incidente, em seguida é

registrado e resolvido, ou repassado para um outro nível de solução de incidentes,

que poderia ser o grupo de suporte a aplicações, ou um grupo de especialistas.

2.1.2 Central de Serviço Virtual

Figura 5. Tipo de Central de Serviço Virtual. (OGCa, p. 40)

A figura 5 mostra um exemplo de Central de Serviço Virtual, que pode

ser situada e acessada em qualquer lugar do mundo. Se uma empresa possua

várias localizações, os seus principais benefícios são: redução de custosoperacionais, um escopo para uma avaliação de administração consolidada e uma

melhor utilização dos recursos disponíveis. Porém, a primeira restrição para a

Central de Serviço Virtual é a necessidade da presença de um especialista local.

(OGCa, p. 39).



29

Na empresa X, tem-se como exemplo, a centralização da Central de

Serviço no estado de Minas Gerais, assim qualquer problema relacionado a

software, através um software de conexão remota, a Central de Serviço começa a

atuar sobre o incidente.

2.1.3 Central de Serviço On Site (Local)

Figura 6. Tipo de Central de Serviço Local. (OGCa, p. 38)

Na empresa X, a figura 6 exemplifica o processo de contato do cliente

com a Central de Serviço. Por exemplo, vários clientes podem ligar na Central de

Serviço informando sobre um incidente de hardware , no entanto o cliente identifica o

incidente, registra e encaminha para um outro grupo solucionador que fica

responsável de localizar o usuário e resolver seu incidente trocando ou concertando

o hardware .

A Central de Serviços é responsável por registrar todos os incidentes econtrolá-los. A Central de serviços pode usar diferentes origens para registrar os

incidentes, como por exemplo: Telefone, E-mail, Internet, Fax ou Visita Pessoal.

Sendo um ponto único de contato para o Serviço em TI, a Central de

Serviço deve ter um vínculo com todos os processos dentro da ITIL. Com alguns

processos este vínculo é mais claro que com outros.

“A Central de Serviços é, de fato, um aspecto operacional importante



30

do processo do Gerenciamento de Incidentes. A Central de Serviços registra e

controla os incidentes (OGCa , 2001, p. 13).

Os incidentes podem ser relacionados aos Itens de Configuração. Se

este vínculo for suportado por um software , há condições de futuramente fazer todo

o rastreamento de incidentes ocasionado com determinado equipamento na infra-

estrutura (OGCa , 2001. p. 122).

Isto também permitirá a equipe da Central de Serviços resolver

rapidamente os incidentes buscando soluções relacionada ao Item de Configuração

ou ao problema relacionado.

A implementação de uma Central de Serviços poderá trazer vários

benefícios para a TI e o negócio:

• Aumento de acessibilidade: ponto único de contato, suporte

sempre disponível;

• Produtividade: a equipe de 2º. nível não é interrompido por

chamadas de usuários;

• Redução de impacto: rapidez na restauração dos serviços;

• Disponibilidade do atendimento;

• Percepção de qualidade e satisfação dos clientes;

• Melhor trabalho em equipe;

• Melhor comunicação: a equipe da Central de Serviços terá

habilidades para o relacionamento com o usuário, e será focada

em dar o feedback de suas solicitações;

• Indicadores para gestão e suporte à decisão.

Às vezes Central de Serviços faz algumas mudanças pequenas e tem

um vínculo com o Gerenciamento de Mudanças e o Gerenciamento de Liberações.



31

2.2 Suporte de Serviço (Service Support )

2.2.1 Gerenciamento de Incidentes (Incident Management )

Um Gerenciamento de Serviços de TI está orientado a entrega de

níveis de serviços com qualidade e com a rapidez que o negócio exige, para isto é

necessário ter um processo de tratamento de incidentes eficaz e eficiente, capaz de

monitorar os níveis de serviços, escalando os incidentes quando necessário.

Este é um dos processos mais reativos, pois entrará em atuação a

partir de incidente levantado por usuários ou ferramentas de monitoramento.

Entretanto, este processo é vital para manter a agilidade dos serviços de TI. É

importante considerar também que as informações dos incidentes levantadas nesteprocesso serão de grande importância para o processo de Gerenciamento de

Problemas.

“O processo de Gerenciamento de Incidentes tem como missão

restaurar o serviço normal o mais rápido possível com o mínimo de interrupção,

minimizando os impactos negativos nas áreas de Negócio” (OGCa, 2001. p. 71).

Como por exemplo, na empresa X, onde possuem vários servidores de

Internet, e seus clientes ficam o tempo todo buscando informações e repassando

para seus clientes. Se estes servidores pararem a Central de Serviço é responsávelpara solucionar o incidente. O Nível 1 identifica e registra o incidente, logo em

seguida encaminha a solicitação para o Nível 3 (descrito no exemplo da figura 3),

grupo de especialistas, que por sua vez, detecta e grava o incidente, classifica e

inicia o suporte, durante o suporte é investigado e diagnosticado, depois de

identificado é resolvido e recuperado, em seguida o incidente é fechado e

monitorado.



32

Figura 7. Progresso do Incidente. (Empresa X, 2006 )

A figura 7 mostra um evento que conduz a um contato com o NOC

(Network Operation Center, nome dado a Central de Serviço da Empresa X), se

torna parte do processo de gestão de incidente. Os contatos originam-se de

múltiplas fontes. Os clientes afetados são os contatos mais comuns, mas

fornecedores, alarmes ou outros processos geridos por TI ou Telecom também

podem reportar incidentes. Os contatos podem ser reportados via e-mail, telefone,alarmes ou constatação física através de visitas da equipe técnica à operação.

Todos os incidentes relativos ao processo de gestão de incidente

originam-se de contatos, mas nem todos os contatos resultam em novos incidentes.

Quando o NOC recebe um contato, ele cria um novo incidente para documentar este

evento ou atualiza um incidente existente. O NOC é responsável, inicialmente, por

executar com sucesso a gestão de incidente. Por isso, o NOC herda os objetivos da



33

gestão de incidente: resolução de incidentes rápida e eficientemente.

Entretanto, estes objetivos nem sempre podem ser atendidos. Às

vezes, o NOC confia nos seus parceiros de escalação para a resolução, mas ainda é

o responsável pela execução do processo. Para garantir que isto aconteça, o NOC

controla a performance do parceiro e empreende a ação apropriada para assegurar

que os incidentes sejam resolvidos dentro do período adequado.

O resultado desejado do processo de gestão de incidente é a

resolução definitiva do incidente. Em alguns casos, o incidente é causado por erros

dentro da infra-estrutura de TI e / ou Telecom. Nesses casos, uma solução

temporária é desenvolvida para restaurar o ambiente à produtividade. Nenhum

ambiente pode tolerar soluções temporárias e ter níveis de serviço satisfatórios. Uma

resolução definitiva, através da identificação da causa raiz do incidente, deve serencontrada e implementada para prevenir a repetição do incidente. Esta resolução

definitiva muitas vezes necessita de modificação na infra-estrutura de TI e/ou

Telecom.

A modificação de determinado IC (Item de Configuração) ou grupo de

itens de configuração, quando identificado, deve ser implementada. Desta forma, a

repetição do incidente é eliminada definitivamente. Quando o incidente não é

resolvido e uma solução temporária é desenvolvida, o incidente é classificado como

erro conhecido. Os erros conhecidos não devem ser tolerados indefinidamente. Aresolução de erros conhecidos normalmente necessita de uma modificação na infra-

estrutura de TI e/ou Telecom. Esta modificação na infra-estrutura de TI e/ou Telecom

é feita através dos processos de gestão de mudança e gestão de versões, geridos

pelo processo de gestão de problema.

2.2.2 Gerenciamento de Problemas (Problem Management )

A maioria dos departamentos de TI tem como tarefa diária apagarincêndios. O grande volume de chamados com erros em sistemas, mau

funcionamento dos componentes de hardware acaba criando um gargalo para a

equipe de suporte. O dia-a-dia corrido da equipe acaba fazendo com que os

problemas não sejam resolvidos definitivamente, utilizando apenas soluções não

permanentes para contornar a pressão dos usuários, é como se colocasse a poeira



34

em baixo do tapete.

O problema da qualidade da solução faz com que o incidente volte

acontecer, novamente ocupando o tempo da equipe de suporte para resolver o

incidente. O que acaba acontecendo é que a equipe de suporte quase nunca resolve

o incidente de forma definitiva devido à falta de tempo.

Uma forma de reduzir a quantidade de incidentes é evitando a sua

recorrência. Através do processo de Gerenciamento de Incidentes os problemas

com causas não identificadas serão analisados e corrigidas para que não voltem a

repetir.

Este processo terá outra preocupação: registrar todos os Erros

Conhecidos e Soluções de Contorno, pois com isto será possível fazer uma melhor

gestão do conhecimento, fazendo com que a maioria dos incidentes sejamconcluídos no 1º. Nível de suporte. Dependendo do ramo de negócio, algumas

empresas conseguem fazer com que 80% dos incidentes sejam resolvidos

diretamente no 1º. Nível através do uso de uma Base de Conhecimento.

É importante o Processo de Gerenciamento de Problemas vir

acompanhado do Gerenciamento de Mudanças, fazendo com que a correção dos

erros sejam previamente analisadas em relação aos riscos, pois muitas vezes a

correção de um incidente acaba gerando mais incidentes e criando impacto para os

usuários.Este processo tem como missão minimizar a interrupção nos serviços

de TI através da organização dos recursos para solucionar problemas de acordo

com as necessidades de negócio, prevenindo a recorrência dos mesmos e

registrando informações que melhore a maneira pela qual a organização de TI trata

os problemas, resultando em níveis mais altos de disponibilidade e produtividade.

(OGCa, 2001, p. 95).

O processo é focado em encontrar relacionamentos entre os

incidentes, problemas e erros conhecidos. A atividade chave para estas 3 áreas écompreender a "análise da causa raiz". O princípio básico está em começar com

muitas possibilidades e ir estreitando até encontrar a causa raiz final.



35

Figura 8. Progresso do Controle do Problema. (OGC, 2001. p. 101)

A ocorrência de alguns incidentes são inevitáveis, muitos outros

incidentes são causados por erros de alguém da organização, isso aumenta

conforme a complexidade dos serviços de TI.

A figura 8 mostra as atividades do processo de controle de problemas,

sendo um controle de problema reativo o processo é voltado em identificar a causa

raiz do problema e prevenir futuras ocorrências, sendo definido em três fases:

identificação e registro do problema, classificação do problema em termos de

impacto para o negócio, investigação e diagnose do problema, gerando assim um

pedido de mudança e possível resolução e fechamento do problema. Assim quando

a causa raiz é identificada é iniciado um novo processo de controle do erro, onde o

controle do erro cobre os processos envolvidos na correção bem sucedida de erros

conhecidos.

Na empresa X, o Gerenciamento de Problemas é tratado por uma

equipe especializada em TI e Telecom, na qual é responsável pela administração do

ambiente. Quando um incidente acontece várias vezes, como, por exemplo, um

PABX (Private Automatic Branch Exchange - Troca automática de ramais privados)

que durante o dia fica indisponível várias vezes de efetuar ligações, é considerado



36

um problema. No entanto o problema é identificado e monitorado, após sua

classificação o problema é investigado e diagnosticado para encontrar a sua causa

raiz. Depois de identificado a causa raiz, um pedido de mudança é solicitado e em

seguida a solução e fechamento do problema junto com o cliente.

Figura 9. Atividades da fase Controle do Problema. (Empresa X, 2006 )



37

A figura 9 exemplifica as atividades da fase de Controle do Problema:

Primeiro é identificar o problema, onde problemas não são apenas os incidentes,

eles podem ser identificados por qualquer pessoa na empresa. As principais causas

do problema podem ser relacionadas a problemas operacionais, ao hardware ou

software , a rede ou alguma mudança realizada, sem analisar os impactos no

ambiente de TI. Segundo é a verificação das informações onde são avaliadas as

informações disponibilizadas pelos clientes, todas as informações são coletadas

nesta atividade devem ser registradas, pois elas poderão ser utilizadas na

investigação da solução definitiva. O objetivo é evitar que os mesmos

questionamentos sejam realizados mais de uma vez. Terceiro é o Registro do

Problema, onde o problema é registrado, sua importância permite a reconstituição do

problema, o treinamento da equipe e a análise de tendência de ocorrência deproblemas. Quarto a classificação do problema é fundamental para a metodologia de

Gerenciamento de Problemas, pois permitem definir, de forma precisa, a velocidade

e a eficiência na qual o problema será tratado. Quinto, onde é determinada a causa

raiz do problema identificado.

2.2.3 Gerenciamento de Mudanças (Change Management )

Como já visto anteriormente a área de TI tem se tornado crítica para asoperações do negócio em virtude das dependências que o negócio tem sobre a TI

para continuar funcionando. Cada vez mais os usuários exigem níveis de serviços

mais altos para alcançar os objetivos do negócio. E percebemos ainda que a área de

TI está em constante mudança para atender a demanda da evolução do cenário de

negócios, realizando implementações nos sistemas, implementando mais

capacidade para os serviços, criando novas políticas de segurança, entre outras.

É sabido também que a maioria dos problemas relacionados com a

qualidade dos serviços normalmente está relacionada a alguma mudança járealizada anteriormente. Mudanças mal feitas, sem planejamento e testes

adequados podem resultar em mais problemas, muitas vezes desastrosos, trazendo

prejuízos ao negócio. Vários problemas de indisponibilidade dos serviços está

relacionado a uma falha de configuração do operador. Como estamos tão

dependentes dos serviços de TI, não podemos mais aceitar falhas brutais nas



38

mudanças implementadas.

“Através do processo de Gerenciamento de Mudanças todas as

implementações e alterações na infra-estrutura de TI serão analisadas e planejadas

para que se tenha o menor risco e impacto” (OGCa, 2001, p. 165).

Segundo OGCa (2001, p. 170) o conceito básico do processo de

Gerenciamento de Mudança está mais relacionado a processos gerenciais do que

técnico. O processo de Gerenciamento de Mudanças será descrito com mais

detalhes no Capítulo 3.

Na empresa X, o Gerenciamento de Mudança, acontece da seguinte

forma: O pedido de mudança é solicitado através do preenchimento de um

documento padronizado na empresa, o documento deve ser encaminhado até o

terceiro dia útil da semana para que o Gerente das Mudanças conhecido comoChange Manager , filtrem os pedidos conforme sua prioridade, o pedido de mudança

é levado para um Comitê, onde participam especialistas de suporte e a gerência de

TI, que por sua vez discutem, se aprovam ou rejeitam o pedido de mudança. Se o

pedido for aprovado, o Change Manager coordena a implementação da mudança, e

após a sua implantação a mudança é revisada e fechada. Se o pedido for reprovado

um novo estudo será analisado, em seguida o pedido é novamente encaminhado

para o comitê.

Nem toda solicitação de mudança é encaminhada para o Comitê, porexemplo, mudanças rotineiras que são consideradas alterações diárias do ambiente

são executadas, porém documentadas. Maiores informações serão detalhadas no

capítulo 3, “Gerenciamento de Mudanças”.

2.2.4 Gerenciamento de Liberação (Release Management )

Com o aumento da complexidade dos sistemas e a maior necessidade

das organizações de TI em fornecer um ambiente estável, a liberação de um novosoftware ou hardware dentro do negócio precisa ser controlada com mais atenção.

Este processo dentro da ITIL se preocupa em fornecer um meio

estruturado para o Gerenciamento de Liberação na infra-estrutura a partir do

planejamento da liberação (release ) até a instalação de fato. Os relacionamentos

com o Gerenciamento de Mudanças e Configuração são chaves para este processo,



39

os três juntos estão intimamente ligados.

O Gerenciamento de Liberação fornece um gerenciamento físico de

softwares e hardwares . Informações sobre os componentes de hardware e software

da TI e seus relacionamentos com outros são armazenados no CMDB –

Configuration Management Data Base (Banco de Dados do Gerenciamento da

Configuração). O Gerenciamento de Liberação gerencia mudanças planejadas e

aplicadas a software e hardware na infra-estrutura de TI (OGCa, 2001, p. 203).

O Gerenciamento de Liberação é o processo que “protege” o ambiente

de produção. A proteção vem em forma de procedimentos formais ou testes

extensivos relacionados a mudanças de software ou hardware que estão sendo

propostas dentro do ambiente de produção. (OGCa, 2001, p. 203).

Figura 10. Procedimento Gerenciamento de Liberações. (Empresa X, 2006)

A figura 10 mostra algumas das situações básicas antes e depois que

envolvem o processo de Gerenciamento de Liberação. O processo começa com o

planejamento de uma nova liberação, seja ela um software ou hardware e termina

com uma liberação documentada, armazenada com segurança, com o menor

impacto possível nas atividades do dia-a-dia da organização.Na empresa X toda a implantação ou alteração de um novo software é

homologada e testada antes em um ambiente de teste, após o aceite da

homologação é realizado o pedido de mudança, para que seja executado pela

equipe especialista.

Antes doGerenciamento deLiberação

Implementação doGerenciamento deLiberação

Após oGerenciamento deLiberação

• Alto risco a vírus

• Incidentes/Problemasdevido a plano deliberação de softwarefraco

• Aumento na carga detrabalho com múltiplasversões em produção

• Perda dos softwaresoriginais que foram

• Redução do risco a vírus

• Redução de Incidentes /Problemas devido aliberações de softwaresfracas

• Melhor aproveitamentodos recursos (Equipe de TI

e software e hardware)



40

2.2.5 Gerenciamento da Configuração (Configuration Management )

Através do armazenamento e gerenciamento de dados relacionados à

infra-estrutura de TI, o processo de Gerenciamento da Configuração dá a

organização de TI um controle maior sobre todos os ativos de TI. Quanto mais

dependentes dos sistemas de TI as organizações são, mais importante se torna o

Gerenciamento da Configuração. (OGCa, 2001, p. 121).

E, entretanto, necessário manter um registro de todos IC’s (Ativos de

TI) dentro da infra-estrutura de TI. O Gerenciamento da Configuração tem como

objetivo fornecer um “modelo lógico” da infra-estrutura de TI, identificando,

controlando, mantendo e verificando versões de todos os IC’s.

O processo de Gerenciamento da Configuração quase poderia ser

considerado um processo pivô para todos os outros (especialmente para os de

Suporte a Serviços). O Gerenciamento da Configuração é considerado o processo

central e que fornece suporte a outros processos da ITIL fornecendo informação

sobre a infra-estrutura de TI.

Segundo OGCa (2001, p. 124) nos dias de hoje as grandes e

complexas infra-estruturas de TI, requerem Gerenciamento de Configuração para as

ferramentas de suporte pelo qual incluem o CMDB, onde a gestão de configurações

deve ter os seguintes objetivos:

• Contabilizar todos os recursos de TI e configurações na

empresa e seus serviços.

• Fornecer informações precisas sobre configurações e sua

documentação para suportar todos os outros processos de

Service Management.

• Verificar os registros de configuração contra a infra-estrutura e

corrigir quaisquer exceções.

Ao alcançarem estes objetivos, as empresas poderão beneficiar de

forma significativa em termos de controle, integração e apoio de decisões:

Controlar significa verificar e corrigir os registros de configuração

mostrando um maior nível de controle sobre a sua infra-estrutura. Por exemplo, ao

controlar as versões dos itens de configuração, reduz a complexidade do seu



41

ambiente, reduzindo os custos de suporte. Os itens que desaparecem ou aparecem

sem terem sido pagos serão notados, ajudando-o a controlar o ativo e evitar

questões jurídicas, exercendo assim um maior controle sobre o ambiente.

Integração significa quando processos como Gestão de Incidentes,

Gestão de Problemas, Gestão de Mudanças e Gestão de Liberações são baseados

num registro atual da sua configuração, podem ser integrados, reduzindo erros e

custos administrativos. Por exemplo, pode – se integrar os processos de Gestão de

Incidentes e Gestão de Mudanças de duas formas: quando a resolução de um

incidente requer uma alteração, a aplicação de gestão de incidentes pode criar

automaticamente esse pedido de alteração. Uma aplicação de Gestão de Incidentes

ou Problemas pode utilizar um modelo de serviços para identificar alterações

anteriores que possam ter causado uma falha. A integração de todos os processosTI relacionados com a configuração pode reduzir o número de pessoal necessário

para administrar o seu ambiente, permitindo poupar dinheiro.

Apoio de decisões significa que, os gestores de TI beneficiam de fato

de terem estas informações precisas de configuração planejadas para os seus

processos de gestão de serviços. A tomada de decisão é, ou, torna –se mais fácil se

posuir dados completos e precisos, o que resulta em melhores estimativas de

desempenho e recursos. Poderá comprometer-se com níveis de serviço com maior

confiança e a sua gestão de risco irão melhorar, reduzindo tempos deindisponibilidades não planejados.

Figura 11. Procedimento Gerenciamento de Configurações. (Empresa X, 2006).



42

A figura 11 mostra que o processo de Gerenciamento da Configuração,

quase poderia ser considerado um processo pivô para todos os outros

(especialmente para o Suporte a Serviços). O Gerenciamento da Configuração é

considerado o processo central e que fornece suporte a outros processos da ITIL

fornecendo informação sobre a infra-estrutura de TI.

A maior entrada no processo vem do Gerenciamento de Mudanças,

requisitando informações sobre itens que serão afetados ou reportando o status dos

itens mudados.

O processo inicia com o projeto, população e implementação do CMDB

– Configuration Management Database (Banco de Dados do Gerenciamento da

Configuração).É responsabilidade do Gerenciamento da Configuração manter o

CMDB. A população do CMDB pode ser cara e um exercício prolongado

dependendo do escopo da infra-estrutura de TI que está sendo gerenciado e do

nível de detalhes sobre cada item requisitado (ferramentas de auditoria automática

podem ajudar em grande parte aqui).

As saídas do processo são relatórios para o gerenciamento de TI e

também a constante disponibilidade de informação que podem ser fornecidas a partir

do CMDB a outros processos.Na empresa X, toda a documentação é registrada e gravada em um

sistema através de um banco de dados, contendo todas as características de

software e hardware dos equipamentos.

O CMDB se relaciona entre todos os componentes do sistema,

incluindo Incidentes, Problemas, Erros Conhecidos, Mudanças e Liberações. O

CMDB também é usado para armazenar e controlar os detalhes dos usuários de TI.

2.3 Entrega de Serviço (Service Delivery )

2.3.1 Gerenciamento do Nível de Serviço (Service Level Management )

O Processo de Gerenciamento de Níveis de Serviço gerencia o nível

dos serviços prestados pela equipe de TI, ou seja, é o acordo feito entre o

departamento de TI e os clientes, com o objetivo de definir o tempo de resolução



43

para cada solicitação realizada pelos clientes e tempo para restabelecimento de

cada indisponibilidade ocorrida na operação. Este acordo é chamado de Acordo de

Nível de Serviço – Service Level Agreements (SLA). (FRY 2003, p. 21) diz que não

se podem gerenciar expectativas, mas podem-se gerenciar realidades. Ou seja, é

importante que os acordos sejam formalizados para eliminar qualquer confusão

entre as partes.

A ITIL recomenda que se formalize tais acordos, registrando-os em um

SC – Service Catalogue (Catalogo de Serviços). Caso a empresa não possua SLAs

e SC, não existirá nenhum acordo de nível de serviço, causando um constante

conflito entre a empresa contratada e seus clientes.

Figura 12. Relação entre Cliente / Serviço com o Gerenciamento de Níveis de

Serviço. (OGCb, p. 28)

A figura 12 exemplifica a relação entre cliente / serviço e o

Gerenciamento de Nível de Serviço da empresa X, ambos definem as características

dos serviços e as responsabilidades de ambas as partes. Após a definição o

processo é planejado, implementado, executado e controlado pelo Gerenciamento

de Nível de Serviço.



44

Quando uma aplicação fica indisponível, ou um hardware fica

danificado, a característica do SLA é garantir para o cliente o tempo que o problema

será resolvido, no entanto a Central de Serviço terá um determinado tempo até a

solução.

Um dos elementos mais conhecidos no Gerenciamento do Nível de

Serviço são os SLA’s. Segundo OGCb (2001, p. 28) os SLA’s permitem o

departamento de TI e o cliente acordarem sobre quais serviços devem ser

fornecidos, a disponibilidade necessária e seus custos. Estes níveis devem ser

mensuráveis para ambos os lados poderem verificar se os níveis estão sendo

atendidos.

Outros elementos conhecidos no Gerenciamento de Nível de Serviço

são: OLA - Operational Level Agreement (Acordo de Nível Operacional) e UC –Underpining Contract (Contratos de Apoio).

Segundo MAGALHÃES (2006) as diferenças entre SLA, OLA e UC

são:

O SLA é um acordo entre a área prestadora de serviços de T.I. e seus

clientes, por exemplo, o departamento de TI da empresa X cria um SLA para atender

as necessidades de correio eletrônico do departamento comercial da empresa X.

Este acordo deve deixar claro quais serviços que estão sendo oferecidos, Serviços

do SC, e o nível de cada serviço (horas de funcionamento, downtime , horário dosuporte, etc...).

Para prestar este serviço, o departamento de TI talvez precise

contratar serviços de terceiros para prestar o serviço de correio eletrônico para seus

clientes, o link , por exemplo, mesmo que isto seja transparente para o Departamento

Comercial da empresa X. Neste caso um contrato formal deve ser estabelecido entre

o provedor de serviços externos e o departamento de TI, no exemplo, o provedor do

link e o departamento de TI da empresa X. A este contrato a ITIL dá o nome

genérico de UC.No entanto, em algumas ocasiões para prover serviços para seus

clientes o departamento de TI precisa de serviços prestados por outras áreas da

empresa, mas que não são terceiros. Por exemplo, pode ser que o departamento de

engenharia da empresa X seja o responsável pela manutenção elétrica de todos

circuitos da companhia, incluindo os serviços de geração de energia em caso de



45

emergências (geradores a diesel). Neste caso, o departamento de TI para atender

aos seus clientes vai depender do serviço que outra área da empresa presta a ele, e

sem o qual o atendimento a seus clientes pode ser prejudicado. Como não faz o

menor sentido um contrato formal entre dois departamentos da mesma empresa, já

que são a mesma entidade jurídica, é firmado um acordo operacional entre as eles.

Este acordo é o Acordo de Nível Operacional ou OLA. Para isto o SLA é um acordo

entre o provedor interno de serviços de TI e as áreas clientes. O UC é o contrato

entre o provedor interno de TI e fornecedores externos. O OLA é um acordo entre o

provedor interno de serviços de TI e outra área interna fornecedora de serviços

necessários à TI. Na criação de um SLA os níveis de serviço devem levar em conta

o acordado nos SLAs e UCs.

O Gerenciamento de Nível de Serviço é o processo que forma ovínculo entre o departamento de TI e os clientes. Para implementar este processo

com sucesso é necessário que os outros processos da ITIL já tenham sido

implementados.

Segundo OGCb (2001, p.27) “O foco principal deste processo é

assegurar a qualidade dos Serviços em TI que são fornecidos, ao um custo aceitável

ao negócio”.

O processo de Gerenciamento do Nível de Serviço gerencia a

qualidade dos Serviços em TI entregue conforme os acordos firmados entre osusuários e o departamento de TI.

O objetivo do Gerenciamento do Nível de Serviço é manter e melhorar

a qualidade dos serviços através de um ciclo constante de acordos, monitoração,

relatórios e melhoria dos níveis atuais de serviços. Ele é estrategicamente focado no

negócio, mantendo o alinhamento entre o negócio e a TI.

2.3.2 Gerenciamento da Disponibilidade (Availability Management )

As organizações estão se tornando cada vez mais dependentes sobre

os serviços em TI, quando eles ficam indisponíveis, na maioria dos casos o negócio

também para. Existe também um crescente aumento para 7 dias por semana, 24

horas por dia de disponibilidade dos serviços em TI. (OGCb, 2001, p. 211).

Desta forma é vital para a organização de TI gerenciar e controlar a



46

disponibilidade dos serviços em TI. Isto é feito definindo - se os requisitos a partir

dos negócios relacionados com a disponibilidade dos serviços de TI e depois os

combinando com as possibilidades da organização de TI.

O objetivo do Gerenciamento da Disponibilidade é conseguir um

mapeamento claro dos requisitos do negócio relacionados com a disponibilidade dos

Serviços em TI e otimizar a capacidade da infra-estrutura para alinhar a estas

necessidades. (OGCb, 2001, p. 211)

Uma entrada para isto é: “Assegurar a mais alta disponibilidade

possível dos serviços em TI para que o negócio consiga alcançar seus objetivos”.

(OGCb, 2001, p. 211).

Figura 13. Processo de Gerenciamento de Disponibilidade. (OGCb, p. 219).

A figura 13 exemplifica o escopo do Gerenciamento de disponibilidade

cobrindo o desenho, implementação, medindo e gerenciando a disponibilidade dos

Serviços de TI. Mostra também as entradas e saídas do processo, tendo como

contribuição fundamental para o processo de administração de disponibilidade, são

elas: para entrada: exigências de disponibilidade do negócio, uma avaliação deimpacto no negócio, a disponibilidade ou confiança da infra-estrutura de TI,

informações sobre as falhas dos serviços de TI, configuração e monitoramento dos

dados que pertencem a cada Serviço de TI e acordos de níveis de serviços definidos

para o serviço prestado, para saída: disponibilidade e recuperação dos Serviços de

TI, prevenção para minimizar impactos, acordos e objetivos de disponibilidade,



47

relatórios de disponibilidade e plano para melhoria da disponibilidade.

Na empresa X, através de um software de gerenciamento é

responsável por gerenciar e controlar a disponibilidade dos Serviços prestados em TI

para seus clientes, os equipamentos são monitorados e gerenciados 24 horas por

dia, dependendo do negócio que foi vendido para o cliente, por exemplo, existem

servidores de arquivos que são monitorados, e quando seu espaço em disco chega

a um determinado limite, é gerado um alarme informando que há algo de errado e

uma solução é necessária.

2.3.3 Gerenciamento da Capacidade (Capacity Management )

“Segundo OGCb (2001, p. 119) o processo de Gerenciamento da

Capacidade foi desenhado para assegurar que a capacidade da infra-estrutura de TI

esteja alinhada com as necessidades do negócio”.

“Segundo OGCb (2001, p. 121) o propósito principal do Gerenciamento

da Capacidade é entender e manter os níveis de entrega de serviços requisitados a

um custo aceitável”.

Através de investigação sobre as necessidades de capacidade

técnicas e do negócio, este processo irá gerenciar a capacidade necessária na infra-

estrutura de TI para cumprir os requisitos do negócio. O plano de capacidade é o

documento principal que descreve as necessidades previstas para o próximo

período.

O objetivo principal do Gerenciamento da Capacidade segundo OGCb

(2001, p. 121) é entender os requisitos de capacidade do negócio e controlar

entrega desta capacidade no presente e no futuro. O Gerenciamento da Capacidade

é também responsável por entender a vantagens potenciais que as novas

tecnologias podem trazer para a organização.



48

Figura 14. Processo de Gerenciamento de Capacidade. (OGCb, p. 124).

A figura 14 mostra as entradas que são várias fontes de informações

pertinentes ao processo que consiste em vários sub processos pelo qual há várias

atividades, as saídas são usadas dentro de outras partes do processo, por outros

processos do Gerenciamento de Serviço e por outras partes da organização.

Na empresa X, o gerenciamento de capacidade é feito através de um

software de monitoramento, por exemplo, um servidor gera alarmes informando

memória muito alta, no entanto é identificado que é necessário adicionar mais

memória no servidor, no entanto o Gerenciamento de Capacidade é responsávelpela necessidade do recurso na empresa.

2.3.4 Gerenciamento da Continuidade dos Serviços em TI (Service Continuity

Management )

Ainda existem poucos gerentes que o vêem o ITSCM – IT Service

Continuity Management (Gerenciamento da Continuidade dos Serviços em TI) como

uma luxúria para a qual se não se direciona nenhum recurso. Porém, cada vez maisdesastres ocorrem freqüentemente. As causas de tais desastres são eventos como

o incêndio, queda de raio, enchente, roubo, vandalismo, falta de energia ou ainda

ataques terroristas. Um Plano de Continuidade para o Negócio poderia salvar

muitas empresas que foram afetadas por uma série de problemas ou ainda seus

próprios negócios.

Os negócios estão tornando-se cada vez mais dependentes da TI, os



49

impactos da indisponibilidade dos Serviços em TI tem aumentado drasticamente.

Cada vez que a disponibilidade ou desempenho de um serviço é reduzido, os

usuários não podem continuar a trabalhar normalmente. Esta tendência continuará

fazendo com que a dependência da TI continue aumentando as exigências dos

usuários, gerentes e executivos. É por isto que é importante estimar o impacto sobre

a perda dos serviços em TI e se faça um Plano de Continuidade que assegure que o

negócio sempre poderá continuar suas operações.

O objetivo do processo de ITSCM segundo OGCb (2001, p. 163) é

suportar de forma geral o Gerenciamento da Continuidade de Negócio, assegurando

que os requisitos técnicos da TI e facilidades de determinados serviços (incluindo

sistemas computacionais, redes, aplicações, telecomunicações, suporte técnico e

Central de Serviços) possam ser recuperados dentro de escalas de temporequeridas e acordadas.

Figura 15. Processo de Gerenciamento de Continuidade do Negócio. (OGCb, p.

171).



50

A figura 15 mostra o Processo de Gerenciamento de Continuidade do

Negócio, que é dividido em quatro etapas: a primeira que é a fase de iniciação

depende em até que ponto as instalações de contingência foram aplicadas dentro da

organização, a segunda onde é feita análise de impacto, avaliação de riscos e a

estratégia da continuidade do negócio, determinam como a organização sobreviverá

a uma interrupção ou desastre na organização e seus custos envolvidos, a terceira

etapa que é o processo de implementação, uma vez que a estratégia estiver de

acordo com o ciclo de vida da Continuidade do Negócio, envolvendo se a TI a um

nível detalhado, esta etapa implementa as medidas de redução de riscos,

desenvolve os planos de recuperação, desenvolve procedimentos e empreende os

testes iniciais, já na etapa quatro depois de implementado e planejados há uma

necessidade de assegurar que o processo é mantido como sempre como parte donegócio, isto somente é alcançado com o gerenciamento operacional em educar e

conscientizar os envolvidos treiná-los, rever regularmente os processos, estabelecer

um programa de testes regularmente para assegurar os componentes críticos e

obter a garantia da qualidade do Gerenciamento de Continuidade dos Serviços de

TI.

PSTN

0800

Figura 16. Interligação entre empresa. (Empresa X, 2006 )

A figura 16 exemplifica o processo de Continuidade do Negócio da

Empresa X, onde tem - se a interligação das empresas através de um link dedicado,

um em Minas Gerais e outro no estado de São Paulo, que também estão interligadas



51

por uma rede pública da empresa prestadora do serviço. A empresa fornece

Serviços que opera 24 horas por dia e 7 dias por semana, inclusive pessoas

treinadas trabalhando diariamente, caso venha acontecer algum desastre, o fluxo de

ligações encaminhadas para a empresa X em Minas Gerais redirecionará todas as

chamadas para o estado de São Paulo. Porém, com menos pessoas para o

atendimento, mas garantindo a disponibilidade do serviço, assim acontece também

em caso de algum problema na empresa situada no estado de São Paulo, que

também possuem toda contingência pronta para o atendimento na região de Minas

Gerais.

2.3.5 Gerenciamento Financeiro para Serviços em TI

Segundo OGCb (2001, p. 59) os Serviços de TI são normalmente

vistos como críticos no negócio ou organização. Nos últimos anos os negócios se

tornaram mais dependentes da TI para realizar suas operações, conseqüentemente

o número de usuários aumentou e também aumentou a quantidade de gastos em TI

(orçamento de TI).

Desta forma também os clientes das organizações de TI e os diretores

perceberam que está se gastando muito dinheiro na área de TI. Ainda, leva-se em

conta que estes investimentos precisam trazer um aumento da qualidade dos

serviços prestados e ter um custo-efetivo maior. Por outro lado, organização de TI

acha que está fazendo um bom trabalho, mas acha muito difícil explicar na

linguagem do negócio os custos reais e benefícios dos serviços em TI fornecidos.

Organizações (clientes e diretores) são relutantes a gastar dinheiro

para melhorar os serviços de TI se eles não tiverem um número claro dos custos

envolvidos e os benefícios que isto pode trazer para o negócio. O Gerenciamento

Financeiro para Serviços em TI pode tornar os custos mais claros, criando um

método de cobrança e dando aos clientes uma idéia sobre a relação qualidade / preço. Em outras palavras, o Gerenciamento Financeiro promove a execução dos

Serviços em TI como se fosse uma operação do negócio.

Segundo OGCb (2001, p. 61) o objetivo do processo de

Gerenciamento Financeiro para os Serviços em TI para um departamento de TI

interno deve ser: fornecer um custo-efetivo para os gastos aplicados nos ativos de TI

e recursos usados para fornecer os Serviços em TI. Em um ambiente comercial,



52

podem haver premissas que irão refletir no lucro e ações de marketing da

organização, mas para qualquer serviço em TI os objetivos deverão incluir:

contabilização completa dos gastos em serviços de TI e atribuição destes custos aos

serviços entregue aos clientes. Assistência às decisões da gerência sobre os

investimentos, fornecendo cases de negócios para Mudanças nos Serviços de TI.

O foco principal deste processo é o entendimento dos custos

envolvidos na entrega de Serviços em TI (atribuindo os custos para cada Serviço em

TI especifico e Clientes). Esta consciência dos custos melhora a qualidade de todas

as decisões feitas em relação aos gastos de TI. A cobrança dos custos do cliente é

opcional. (OGCb, 2001, p. 61).

Figura 17. Processo de Gerenciamento Financeiro para Serviços em TI. (Empresa X,

2006).

A figura 17 exemplifica o Processo Financeiro para Serviços em TI, que

consiste de três sub-processos:

Elaboração do Orçamento (obrigatório). A Elaboração do Orçamento éo processo de predizer e controlar os gastos em dinheiro dentro da organização e

consiste de um ciclo de negociação periódico para criar orçamentos (normalmente

anual) e monitoração diária dos orçamentos. A Elaboração do Orçamento assegura

que os recursos em dinheiro necessários estão disponíveis para o fornecimento de

serviços em TI e que durante o período do orçamento eles não serão extrapolados.



53

Todas as organizações têm uma rodada de negociações periódicas (ex. anual) entre

os departamentos de negócio e a Organização de TI cobrindo os planos de

despesas e programas de investimentos acordados, o qual no final das contas

acaba criando o orçamento para a TI.

Contabilidade de TI (obrigatório). A Contabilidade de TI é um conjunto

de processos que possibilita a organização contabilizar de que forma o dinheiro é

gasto (particularmente identificando os custos por cliente, serviço e atividade).

Cobrança (opcional). A Cobrança é um conjunto de processos

necessários para emitir as contas aos Clientes dos serviços fornecidos a eles. É

necessário ter o apoio da Contabilidade de TI para que isto possa ser feito de uma

forma simples, clara e correta.

Dentro das organizações existem dois tipos de ciclos associados com aelaboração de orçamento, contabilidade de TI e cobrança. Um ciclo de planejamento

(anual) onde as projeções de custos e previsão de carga de trabalho formam a base

para o cálculo de custos e formação de preços, e um ciclo operacional (mensal ou

trimestral) onde os custos são monitorados e comparados com os orçamentos,

faturas são emitidas e as receitas geradas.

2.4 Exemplo da Relação dos Processos

Figura 18. Relação dos Processos ITIL. (CA, 2007)



54

Segundo CA (2007) a figura 18 ilustra as principais interações dos

Processos da ITIL. Por exemplo, o Gerenciamento de Mudanças está relacionado

com todas as disciplinas de entrega de serviços. Ele pode querer entradas do

Gerenciamento Financeiro para entender os custos da mudança ou entradas

vindas do Gerenciamento da Capacidade para entender as implicações da mudança

na infra-estrutura. De forma similar, Gerenciamento da Configuração fornece

informações a todas disciplinas de Entrega de Serviços sobre a estrutura da

organização. Todas as disciplinas trabalham juntas para fornecer Gerenciamento de

Serviços ao negócio e aos usuários de sistemas de TI. Os usuários podem ser

funcionários dessa organização ou seus parceiros e clientes que cada vez mais

usam serviços de TI diretamente, que faz aumentar a importância de um efetivo

Gerenciamento dos Serviços.

Figura 19. Modelo do Processo de Suporte de Serviços (Service Support). (OGCa,

2001, p. 297)

A figura 19 exemplifica o resumo dos processos que compõem a ITIL

para Suporte de Serviços na empresa X. A Central de Serviço identifica o incidente,

o incidente pode ser resolvido como incidente ou se tornar um problema. O

ConfigurationManagement

ReleaseManagement

ChangeManagement

ProblemManagement

IncidentManagement

Business, Customers or Users

Releases

Chan es

ManagementTools

Incidents Incidents Service Desk

ProblemsKnown Errors ReleasesChan esIncidents

DifficultiesQueries

Enquiries

CommunicationsUpdates

Workarounds

C M D BCI’s

Relationships



55

Problema torna-se um erro conhecido, e ambos para serem solucionados devem ser

elaborados o documento de alteração no ambiente, gerenciado pelo gerenciamento

de mudanças, para a mudança ser executada, deve haver um planejamento que

envolverá o Gerenciamento de Liberação, até sua execução, e todos os processos

consultam informações na base de configuração. Sendo assim tudo que acontece

em cada processo deve ser registrado no CMDB, gerando resultados criados em

cada processo.

Figura 20. Modelo do Processo de Entrega de Serviços (Service Delivery). (OGCb,

2001, p. 361)

A figura 20 exemplifica como gerir as entregas de serviço (Service

Delivery ) pelos processos da ITIL, o Gerenciamento de Nível de Serviço, onde sãogerados os acordos de níveis de serviços é definido o que o cliente quer, após ter a

expectativa do cliente já definido a partir do Gerenciamento de Nível de Serviço, são

verificadas se as necessidades do cliente serão alcançadas, ou o que devo fazer

para alcançar. Na Disponibilidade (Availability ), é verificada a disponibilidade

suficiente do serviço oferecido. No Gerenciamento de Capacidade é verificado se há

capacidade para prover o serviço, caso não tenha é feito um plano para se preparar

CommunicationsUpdates Reports

Capacity PlanCDB

Targets/ThresholdsCapacity Reports

Schedules

Business, Customers and Users

QueriesEn uiries

SLA’s, SLR’s, OLA’sService Reports

Service CatalogueSIP

Exception Reports

Service LevelManagement

IT Continuity PlansBIA & Risk Analysis

Control Centres

DR ContactsReportsAudit Reports

IT Service ContinuityManagement

RequirementsTargets

Achievements

Financial PlanTypes & ModelsCosts & Charges

ReportsBudgets & Forecasts

Availability PlanDesign Criteria

Targets/ThresholdsReportsAudit Re orts

Financial Managementfor IT Services

CapacityMana ement

AvailabilityManagement

Alerts &ExceptionsChanges

ManagementTools



56

para atender, então é verificado o quanto vai custar, para avaliar o quanto vai cobrar,

através de um plano financeiro. No Plano de Continuidade, verifica se tem os

requerimentos suficientes para prover a continuidade do negócio ou serviço

oferecido.



57

3 GERENCIAMENTO DE MUDANÇAS

Este é um processo considerado pela equipe um tanto quanto

burocrático, pois é aconselhável que a maioria dos erros identificados antes de ser

corrigidos sejam filtrados, analisados e testados para depois serem implementadasas correções no ambiente de produção. É necessário que haja uma mudança de

cultura e um comprometimento de todos para que o processo funcione, evitando que

haja formas de burlar o processo.

Normalmente o Gerenciamento de Mudanças aplicado em

departamentos de TI que já tenham uma certa maturidade no Gerenciamento de

Serviços de TI. Este processo pode ser implementado isoladamente, mas é

importante o apoio do Gerenciamento de Configuração para dar suporte à avaliação

de impacto, indicando os itens de configuração envolvidos na mudança.O processo de Gerenciamento de Mudança é profundamente

dependente de um processo de Gerenciamento de Configuração bem executado, o

que garante uma CMDB atualizada, uma vez que o registro de quais IC´s compõe

qual serviço de TI é de responsabilidades daquele processo.

Na operação diária ambiente de TI, tem se: Hardware , Software ,

documentação, que necessitam ser atualizadas e alteradas diariamente para ter em

mente o conhecimento do negócio do cliente e dos serviços oferecidos, são

cadastrados também no CMDB os CI´s (Itens de Configuração) e o relacionamento

entre eles, junto com o registro dos Ativos da empresa e os relacionamentos entre

eles até o Nível de Serviço.

3.1 Objetivos

Este processo tem como missão gerenciar todas as mudanças que

possam causar impacto na habilidade da área de TI em entregar serviços, através

de um processo único e centralizado de aprovação, programação e controle damudança, para assegurar que a infra-estrutura e TI permaneça alinhada aos

requisitos do negócio, com o menor risco possível. (OGCa, 2001, p. 165).

Segundo OGCa (2001, p. 165) os principais objetivos deste processo

são:



58

• Assegurar que os métodos padronizados estejam sendo usados

para o tratamento eficiente de todas as Mudanças, reduzindo

seus riscos e impactos;

•

Minimizar incidentes relacionados com mudanças;• Balanço entre necessidade e impacto.

Segundo OGCa (2001, p. 166) este processo tem foco nas mudanças

que afetam:

• Hardware , Software , Equipamentos e Software de

Comunicação;

• Aplicações em produção;

• Toda a documentação e procedimentos associados com aoperação, suporte e manutenção da Infra-estrutura de TI.

Ficam fora do escopo, mas relacionados:

• Mudanças em projetos, por exemplo, um projeto de implantação

de um ERP pode exigir mudanças na capacidade dos

servidores;

• Identificação de componentes afetados na mudança ou

atualização de registro (domínio da Gestão de Configuração);

• Liberação de novos componentes (foco do Gerenciamento de

Liberações).

3.2 Descrição do Processo

O Processo de Gerenciamento de Mudanças é responsável por decidir

e coordenar as mudanças, e não tem como objetivo executar a implementação das

mudanças. A Implementação será realizada por uma equipe técnica responsável

pela área de mudança, como a área de redes, sistemas, hardware . O processo de

Gerenciamento de Mudança controlará as mudanças para que elas sejam

implementadas de forma eficientes e eficazes, no que se refere ao custo com um

mínimo de riscos para os serviços mantidos. Para que se possa fazer uma análise

de riscos adequada é importante o uso CMDB, que forneça todos os serviços e



59

recursos relacionados ao item de configuração que sofrerá a mudança.

É necessário que nem todas as mudanças sejam controladas pelo

processo de Gerenciamento de Mudanças. Por exemplo, mudanças sem

importância, tais como resetar uma senha, etc, podem ser feitas pela Central de

Serviços (seguindo procedimentos definidos), não sendo necessário ser

encaminhadas para o Comitê de Mudanças. Fazendo desta forma, poderão evitar a

carga de trabalho, frustração e circunvenção (passar por cima) ao processo.

Figura 21. Entrada e saídas do processo de Gerenciamento de Mudanças.

A figura 21 exemplifica que, segundo OGCa (2001, p. 167) diz que as

principais entradas e saídas do processo são:

Principais entradas para este processo:

• RFCs – Request For Change (Requisições de Mudanças -

RDM);

• FSC – Forward Schedule of Changes (Programação Futura de

Mudanças - PFM), é o agendamento das próximas mudanças;

• Informações do processo de Gerenciamento de Capacidade,

• Avaliação e Registro dasMudanças

• Análise do impacto, custo,benefícios e riscos associados

• Justificativa e aprovação dasMudanças

• Controle das Mudanças e doProcesso de Mudança

• Instauração do comitê de Controlede Mudanças (CCM) e do Comitê deEmergência (CCM/CE)

Requisições deMudanças(RDMs)

Programaçãofutura deMudanças(PFM)

Requisições deMudança(RDMs)

Atas de reuniãodo CCM eAções

Relatórios doGerenciamentode Mudanças

Gerenciamentoda Capacidade

Gerenciamentoda

Configuração

Gerenciamentode Liberações

ProgramaçãoFutura deMudanças (PFM)

BCO de DADOS doGerenciamento daConfiguração (CMDB)



60

Configuração e Liberações para realizar a análise de riscos,

planejamento, custos. (CMDB).

Principais saídas:

• Programação Futura de Mudanças (FPM);

• Requisições de Mudanças Aprovadas (RDM);

• Atas da Reunião do CAB Change Advisory Board (Conselho de

Controle de Mudanças CCM);

• Informações Gerenciais do Processo.

O processo do Gerenciamento de Mudanças inclui as seguintes

atividades:

•

Registro e Classificação;• Aprovação;

• Coordenação do Desenvolvimento;

• Autorização e Implementação;

• Avaliação.

Figura 22. Limites entre Administração de Mudança e administração de programa.

(OGCa, 2001, p. 166).

Projeto Gerenciamento de Mudanças

Monitoração ePlanejamento

Desenvolvimento

Teste

Implementação

Registro e Classificação

Aprovação

Autorização eImplementação

Avaliação

RDM

Backout

Recusa

Recusa



61

O processo de Gerenciamento de Mudanças tem ligação muito

próxima com o Gerenciamento de Projetos, que é tratado pela ITIL. Dependendo da

complexidade da mudança o desenvolvimento da mudança será tratado como um

projeto dentro da organização. A figura 22 ilustra as atividades que fazem parte do

Gerenciamento de Mudanças e as atividades que fazem parte do Gerenciamento de

Projetos. (OGCa, 2001, p. 165). Os itens a seguir descrevem as atividades

exemplificadas na figura 65.

3.2.1 Registro de Requisição de Mudanças – RDM

Uma RDM pode ser levantada a partir de uma necessidade do cliente

ou surgir a partir de um Erro identificado no processo de Gerenciamento de

Problemas. A RDM poderá ser em papel ou eletrônica, através de um software de

Gerenciamento de Serviços. (OGCa, 2001, p. 174).

3.2.2 Registro e Classificação

Uma RDM deve ter várias informações para a tomada de decisão, tais

como categoria, impacto, custo. Estas informações serão utilizadas para extrair o

relatório gerencial. Também é importante alocar a prioridade para cada mudança

para definir a agenda de mudanças programadas.

3.2.3 Aprovação

As RDMs são filtradas e aprovadas. Alguns fatores podem determinar

que uma mudança seja recusada, por exemplo o custo da mudança é muito alto pelo

benefício que ela vai trazer para o negócio.

3.2.4 Coordenação do Desenvolvimento

Aprovada a Mudança, a Requisição de Mudança deve ser passada

para o grupo técnico que será responsável pelo desenvolvimento da mudança. O

Gerenciamento de Mudanças deve coordenar este processo assegurando que exista

os recursos necessários, monitorando os riscos e acompanhando os testes.



62

3.2.5 Autorização e Implementação

Após passar pela fase de desenvolvimento as mudanças devem ser

testadas antes de ir para o ambiente de produção. É aconselhável que exista um

grupo de testes independente neste processo que tenha condições técnicas que

elaborar o plano de testes avaliando todos requisitos para o funcionamento da

mudança no ambiente de produção. Após o resultado dos testes a mudança será

autorizada para ser implementada. Dependendo da urgência e do impacto da

mudança a fase de testes poderá ser ignorada.

3.2.6 Implementação

O Gerenciamento de Mudanças devem garantir que as mudanças

sejam implementadas seguindo um programa definido. A execução da

implementação não é de responsabilidade deste processo, ele apenas irá coordenar.

O processo de Gerenciamento de Liberações poderá ser coordenado pelo processo

de Gerenciamento de Mudanças, pois as mudanças acabam gerando novas

liberações de software ou de hardware .

3.2.7 Avaliação

O Gerenciamento de Mudanças de avaliar todas as mudanças

implementadas depois de determinado período. Esta revisão se chama Revisão Pós

Implementação. O processo de Gerenciamento de Problemas também poderá

acompanhar este processo, visto que o Controle de Erros tem esta atividade no seu

escopo. Esta revisão serve para verificar se a mudança trouxe os resultados

esperados, ou se houver algum problema ou ineficiência ações devem ser tomadas

para a correção.

3.2.8 Comitê de Controle de Mudanças (CCM)

Segundo OGCa (2001, p. 175) é um grupo responsável pela avaliação

do impacto das mudanças. Este grupo será composto de várias pessoas técnicas e

até mesmo clientes, que fornecerão assessoria ao Gerente de Mudanças sobre



63

quais mudanças devem ser aprovadas e auxiliarão na programação das mudanças.

Normalmente o CCM se reuni como uma determina freqüência para discutir todas as

mudanças novas e andamento. Os possíveis membros do CCM são:

• Gerente de Mudanças;

• Cliente(s);

• Gerente(s) Usuário(s);

• Representante(s) de Grupo de Usuários;

• Pessoal de desenvolvimento / manutenção de aplicações

(quando apropriado);

• Consultores especialistas / técnicos;

• Equipe de serviços (se necessário);• Equipe de serviços administrativos (quando as mudanças

afetam as instalações);

• Representantes dos contratantes ou de terceiros (se necessário

- por exemplo, em situações de outsourcing );

3.2.9 CCM/CE (Comitê de Emergência)

Quando surgem problemas mais graves, pode não haver tempo parase criar um CCM completo e é, portanto, necessário identificar uma configuração

menor com autoridade para tomar decisões emergenciais. Neste comitê sempre

estão presidindo o Gerente de Mudanças os técnicos responsáveis pela

implementação da Mudança. (OGCa, 2001, p. 176).

Assim essas mudanças se tornam prioritárias e críticas para o

ambiente, sendo assim uma rápida alteração no ambiente para que a solução seja

de imediata, e livre de aprovação para ser executada.

3.2.10 Programação Futura de Mudança (FPM)

Segundo OGC (2001, p. 187) a FPM, deverá incluir detalhes de todas

as mudanças que tem sido autorizada para implementação em cima de um período

acordado previamente.

Normalmente o cronograma para alteração no ambiente, equivale ao



64

grau de risco que a mudança pode acontecer. Se a mudança for de uma criticidade

alta o tempo para planejamento é maior, então o tempo de execução dela deverá

levar alguns dias para ser executada. Por exemplo, uma empresa que por problemas

técnicos há necessidade de trocar o retificador de energia, e no momento da troca

serão desligados todos os computadores e todos os telefones, neste caso, serão

envolvidos várias áreas da empresa, tais como: infra-estrutura, TI e Telecom, haverá

um tempo para cada área planejar sua execução, no entanto um tempo maior é

exigido para execução da Mudança.

3.2.11 Relacionamentos

O processo de Gerenciamento de Mudanças depende da precisão dos

dados de configuração para assegurar o conhecimento sobre o impacto completo de

se aplicar a mudança. Existe um relacionamento muito próximo com o

Gerenciamento da Configuração, Gerenciamento de Liberações e o Gerenciamento

de Mudanças.

Também o processo de Gerenciamento de Problemas pode submeter

uma RDM para resolver Erros Conhecidos e algumas vezes podem causar um efeito

bola de neve, se o processo de Gerenciamento da Configuração não tiver habilidade

para informar quais componentes irão ser afetados (incluindo hardware , software ,

SLA).

Outros processos podem estar vinculados com Gerenciamento de

Mudanças no sentido de que eles podem também requisitar mudanças

(Gerenciamento da Disponibilidade) ou eles serão consultados para determinar o

impacto da mudança (Gerenciamento da Continuidade dos Serviços em TI,

Gerenciamento do Nível de Serviço e Gerenciamento da Capacidade).

3.2.12 Benefícios

Segundo OGCa (2001, p. 179) os principais benefícios deste processo

são:

• Melhor alinhamento dos serviços de TI com os negócios. As

mudanças serão filtras e priorizadas conforme a sua



65

necessidade para o negócio.

• Aumento de visibilidade dentro das Mudanças. Há um controle

maior sobre a execução da mudança.

•

Redução de Impacto negativo da Mudança. A análise de riscospermite evitar que o serviço fique indisponível devido às falhas.

• Melhor avaliação do custo da Mudança. Antes de a mudança ser

implementada deve ser analisado o seu custo x benefício.

• Habilidade de absorver um grande volume de Mudanças. Como

a implementação do processo haverá um Gerente de Mudanças

que deverá coordenar todas a mudanças. Além disto, para cada

área de mudança haverá uma equipe que será convocada para

a reunião. Com um processo definido ficará mais fácil ter ocontrole de várias mudanças ao mesmo tempo.

3.2.13 Problemas Comuns

Assim como todo processo que tem benefícios, tem - se que

reconhecer que existem problemas também. O Gerenciamento de Mudanças é um

processo importante, tanto para o Departamento de TI como para os usuários e

clientes.Segundo OGCa (2001, p. 180) os principais problemas relacionados a

este processo são:

• Falta de informação para análise de riscos. Se não houver uma

Base de configuração atualizada com as informações

necessárias para fazer a análise de impacto, poderá haver

falhas na implementação devido ao surgimento de riscos que

não foram previstos.

• Falta de ferramenta integrada aos demais processos. O auxílio

de uma ferramenta adequada ajudará no controle das

mudanças. A integração aos demais processos ajudará no

planejamento da mudança.

• Falta de comprometimento da equipe. A equipe de TI pode ser



66

relutante em aderir aos procedimentos devido ao

Gerenciamento de Mudanças estar envolvido com muitos

aspectos. É importante fazer com que a equipe esteja

conscientizada dos efeitos positivos do processo como um todo.

A cultura da empresa influenciará na adesão a este processo.

Uma empresa que não é organizada, não tem controle sobre as

decisões tomadas dentro dos seus departamentos, provocará na

equipe da TI a mesma desorganização.

• Urgentização de todas as mudanças. É importante que sejam

definidas as prioridades das mudanças conforme as

necessidades do negócio. As mudanças devem ser planejadas e

agendadas no seu tempo correto. Devem ser tratadas apenascomo mudanças urgentes àquelas que implicam na

indisponibilidade atual ou imediata de um serviço.

3.2.14 KPI - Key Performance Indicators

As Principais KPIs deste processo são:

• Número de Mudanças autorizadas

• Número de Incidentes relacionados com uma Mudança• Relação de Mudanças Urgentes x normais

• Distribuição de Mudanças por motivo (tratamento de incidente,

correção de erro, melhoria, etc).



67

4 ESTUDO DE CASO EM UMA EMPRESA X

Para melhor entendimento do Gerenciamento de Mudança será

mostrado um documento contendo uma visão das principais etapas do processo e

indicar quando seu envolvimento é necessário, desta forma, implementando umametodologia unificada para o processo de mudanças no ambiente de TI e Telecom

de uma empresa X. O Estudo de caso abrange desde a fase de planejamento das

mudanças até a sua conclusão e divulgação dos resultados, tornando possível

aplicar um conjunto uniforme de ações que deverão ser utilizadas tanto em

melhorias do ambiente tecnológico, como para minimizar os impactos em casos de

eventos que comprometam os negócios da empresa.

4.1 Descrição da empresaA empresa X é integrante de um dos mais competitivos grupos

empresariais brasileiros. O grupo é um conglomerado de empresas que atuam em

vários setores, a empresa X, é uma das mais avançadas empresas de contact center

da América Latina e oferece uma variedade de serviços.

4.2 Visão geral do processo de Gerenciamento de Mudança

Figura 23. Visão Geral do Processo de Gerenciamento de Mudança da empresa X.

(Empresa X, 2006)



68

A figura 23 mostra a Visão Geral do Processo de Gerenciamento de

Mudança da empresa X, as mudanças são controladas conforme cada fase dos

processos, os processos estão descritos nos tópicos abaixo.

4.3 Categorias de Mudanças

As Mudanças podem ser categorizadas de acordo com sua

complexidade e risco, recebendo tratamentos diferenciados:

Categoria Descrição Tratamento

1(Crític

a)

Uma mudança de alta complexidade:Envolve um longo período deimplementação, um longo tempo para

"'backout'', cujo backout envolve uma perdado serviço e , ainda um dos seguintes itens:Mais que um projeto está envolvido ouimpactado pela mudança;Mais que um Serviço da Organização deDelivery está envolvido ou impactado pelamudança;Mais que um ambiente é impactado pelamudança;As organizações envolvidas têm pouca ounenhuma experiência na implementaçãoda mudança.

Aceitação de risconecessária para riscos de

negócio e técnico.Revisão, programação e

aceitação de risco atravésde aprovação formal.

2(Maior

)

Mudança de grande complexidade, masque não atende aos critérios de criticidadeda categoria 1.

Vai ocasionar indisponibilidade para ocliente, no entanto esta já foi negociadapreviamente.

Programação é requeridapara assegurar:

- Coordenação entre grupos- Comprometimento

Gerencial na alocação dosrecursos envolvidos

- Revisão e aprovaçãoformais

3(Médio

)

Tempo curto de indisponibilidade,previamente acordado com o cliente.Usuários familiarizados com a mudança

Revisão para assegurar:- Conhecimento geral

- Especificação de detalhestécnicos

4(Meno

r)Mudança de mínima complexidade

Planejamento e Revisãopara assegurar

conhecimento geral efallback simples e rápido.

5Informativa

Mudança sem nenhum riscoRegistro para propósito de

gerenciamento

Quadro 1. Tipos de Categorias de Mudanças. (Empresa X, 2006)



69

O Quadro 1 descreve a categoria e o grau de complexidade de cada

mudança, conforme sua complexidade, um planejamento mais detalhado é

requerido para melhor análise de impacto que a mudança possa ocasionar.

4.4 Prazo para Solicitação de Mudanças

Alguns prazos para abertura e aprovação da mudança devem ser

seguidos, segundo seu risco, conforme apresentado no quadro 2:

Crítica Maior Média Menor Informativa20 diascorridos

14 Diascorridos

8 Dias úteis 7 Dias úteis 7 Dias úteis

Quadro 2. Prazos para abertura e aprovação da mudança. (Empresa X, 2006)

O Quadro 2 descreve a categoria e as quantidades de dias adequadas

para o planejamento da mudança.

4.5 Detalhamento das fases

As mudanças podem ocorrer de forma Programada, Acelerada ou

Emergencial. A programada, existe conhecimento prévio da necessidade e esta nãodemanda urgência para sua execução. Portanto, seguem o processo normal de

Gerência de Mudanças, Aceleradas, as mudanças que necessitam ser executada

após 48:00 horas da solicitação, por necessidade técnica ou de Negócios da

Empresa X, na Emergencial, a mudança vital para atender uma necessidade de

negócio, normalmente para correção de um problema, e que não podem aguardar o

processo normal de mudanças, particularmente a revisão e fase de aprovação, onde

existe risco iminente para os negócios, ativos ou processos da empresa X.

Para efeito de definição, mudanças “Programadas”, “Aceleradas” ou

“Emergenciais” seguem o mesmo procedimento, sendo que, os parâmetros de

tempo devem atender as necessidades específicas de cada tipo.

Qualquer evento que ocorra no ambiente de tecnologia e que não

possua uma “Mudança” registrada, deve ser enquadrado como “Incidente Técnico”

não controlado e o processo de comunicação devem abranger as áreas de negócio



70

e técnica de todas as empresas envolvidas.

A visão implementada adota 4 fases distintas e dependentes para

executar uma mudança no ambiente de tecnologia da empresa X, cada fase

representa um estágio atômico com os seus respectivos processos internos bem

definidos e coesos.

Figura 24. Fases do processo de mudança. (Empresa X, 2006)

“O método PDCA que se baseia no controle de processos, foi

desenvolvido na década de 30 pelo americano Shewhart , mas foi Deming seu maior

divulgador, ficando mundialmente conhecido ao aplicar nos conceitos de qualidade

no Japão” (WIKIPÉDIA, 2007). P(Plan = Planejar) D(Do = Executar) C(Check =

Verificar) A (Action = Agir).

4.6 Planejamento

A fase de planejamento destina-se a mapear com antecedência todas

as variáveis que possuem relevância, sob a perspectiva da necessidade de

realização da mudança em função do custo e riscos operacionais e táticos

envolvidos.

Os processos mapeados na fase de planejamento garantem que as

melhores práticas serão aplicadas no processo de mudança, garantindo assim

ganhos de produtividade, uniformidade, tempo e custos.



71

Figura 25. Atividades do Planejamento. (Empresa X, 2006)

A figura 25 mostra as atividades internas e seus respectivos

documentos, definidos para a fase de planejamento, são eles:

4.6.1 Formalização da necessidade:

Na formalização é necessário especificar todas as informações que

caracterizam a mudança de forma ampla e conceitual. Nesta etapa do processo se

define todos os envolvidos, a forma como a mudança será executada, quais

equipamentos e negócios serão afetados e quais fornecedores/ parceiros devemcolaborar.

4.6.2 Alternativas não aplicadas:

Quando existirem, todas as alternativas que foram consideradas e as

razões pelas quais não foram adotadas devem constar na documentação do



72

processo de mudança. Esta prática garante em caso de falhas, uma análise crítica

mais detalhada do processo e das alternativas que poderiam ser adotadas.

4.6.3 Análise de Impactos:

Esta atividade deve abordar todos os impactos relacionados a

mudança proposta. Para melhorar a compreensão desta atividade será divido em

impactos se a mudança não for aplicada e impactos após a mudança implementada

(estimativa).

Para se analisar os “impactos se a mudança não for aplicada” deve-se

considerar qual será o cenário se a mudança não for implementada, entendo-se aí,

risco de diminuição da disponibilidade para o negócio, perda de performance,diminuição da eficiência operacional ou aumento do custo com infra estrutura e

pessoas. Em contrapartida para se analisar os “impactos após a mudança

implementada”, deverá ser mostrado, se for o caso, o ganho obtido com a mudança.

Outra análise de fundamental importância é o risco envolvido no

processo de forma geral, ou seja, deve existir um mapeamento onde todas as

possibilidades de insucesso sejam abordadas, pois este documento será utilizado

como referência para determinação das contingências necessárias, quanto mais

detalhes (sob a perspectiva do negócio) forem catalogados, mais fácil serádeterminar os riscos envolvidos na operação.

O Quadro 3 mostra classificação de Risco das Mudanças, que serve

apenas como referência para a classificação de risco das mudanças, podendo existir

casos onde a percepção da criticidade seja diferente daquela pontuada após a

análise indicada abaixo.

Número de Sistemas/Aplicativos Impactados:

4 ou mais sistemas/aplicativos online 12 a 3 sistemas/aplicativos online 21 sistema/aplicativo online 3Recursos Requeridos para Preparar/Implementar:3 ou mais grupos de suporte 12 ou mais pessoas em dois grupos de suporte 22 ou mais pessoas do mesmo grupo de suporte 31 pessoa 4Esforço de Preparação:



73

30 dias ou mais 12 a 29 dias 21 dia 3< 1 dia 4Exposição a Falhas:

Sem possibilidade de fallback 1Fallback difícil / demorado ou não desejável 2Fallback nível moderado 3Fallback fácil 4Quantidade de Usuários AfetadosMais do que 50% dos usuários do serviço 1Até 10% dos usuários do serviço 21 ou nenhum usuário do serviço 3Se Total = Risco da

Mudança:5 a 8 Crítico

9 a 12 Alto13 a 16 Médio17 a 20 Baixo

Quadro 3. Classificação de Riscos. (Empresa X, 2007)

Além dos itens deste quadro, deverão também ser avaliados para a

categorização do risco de uma mudança os seguintes pontos:

• Impactos de segurança

•

Volume de documentação produzido para a mudança• Educação / treinamentos requeridos para a mudança

• Recursos de TI envolvidos (volume de espaço em disco e

demanda de CPU – Central Process Unit (Unidade Central de

Processamento) requeridos, volume de banda requerido, tempo

de janela, experiência da equipe de implementação, etc.)

4.6.4 Determinação das Contingências:

Entende-se como contingência uma estrutura que suporte o negócio

como um todo e que esta seja independente ou não afetável pela ação da mudança

que está sendo proposta. Em qualquer situação onde a mudança implique em risco,

por menor que seja, a contingência deve ser adotada como condição “sine qua non”

para execução das atividades. A quantidade e a forma como a contingência deve ser



74

implementada, deve necessariamente ser aprovada pelas áreas de negócio da

empresa X, sendo que o processo de aprovação deve ser formalizado na forma de

registros históricos (computacionais ou não).

Outro fator que deve ser adotado como procedimento operacional é o

“Teste operacional da contingência” que deve necessariamente ser realizado pelas

áreas de negócio da empresa X e a aprovação deve constar como registro histórico

da mudança. Durante a utilização da contingência deve existir o “Diário de Bordo –

Contingência”, onde a área de negócio deve registrar todas as ocorrências

pertinentes a utilização da contingência.

4.6.5 Plano de “Roll Back ”:

Esta atividade deve prever quais passos, se possível, devem ser

aplicados para que mudança retorne ao seu estado de origem, ou seja, em uma

situação limite onde o procedimento deve ser abortado, o que se deve fazer para

minimizar os impactos e “voltar” na situação pré-mudança.

4.6.6 Definição do “Check List ” de Execução:

O “Check list ” de Execução deve conter todos os passos essenciaispara execução da mudança, desde referências técnicas de fabricantes e parceiros

até dicas adquiridas tacitamente ao longo do tempo, este documento deve ser bem

detalhado pois servirá como referência para execução de mudanças futuras.

O “Check list ” aliado ao “Diário de Bordo de execução” fornece uma

visão sobre a aderência do planejamento em função dos eventos que efetivamente

ocorrem durante o processo. Esta correlação permite que o processo como um todo

evolua sempre no sentido de aperfeiçoar a planejamento a ponto dos desvios de

execução serem mínimos ou não existirem.

4.6.7 Definição da “Scalation List ”

A lista de escalação é um artifício que deve ser utilizado em casos

onde as decisões não estão mais no âmbito dos executantes da mudança. Como



75

“decisão” deve ser entendida que qualquer evento que afete a mudança ou o

negócio de forma significativa e que não esteja contemplado na fase de

planejamento, deve ser submetido a uma aprovação imediata dos gestores técnicos,

do negócio e dos parceiros envolvidos no processo. A lista de escalação deve conter

também todas as referências de agentes importantes, principalmente de parceiros

que indiretamente influenciam os resultados.

4.6.8 Estimativa de Custos Operacionais:

A estimativa de custo tem como objetivo mensurar quais custos diretos

(parceiros, transporte, hospedagem, etc.) estão envolvidos na mudança e os ganhos

financeiros, se existirem.

4.6.9 Classificação de Resultados

Os resultados das mudanças podem ser classificados conforme

abaixo:

Sucesso: Quando a mudança foi bem sucedida, ou seja, o objetivo

proposto foi alcançado dentro do tempo planejado (janela acordada com o cliente).

Impacto: Quando a mudança foi realizada, no entanto, ultrapassou otempo planejado, causando impacto para o mesmo.

Falha (Insucesso): Quando a mudança não pôde ser concluída devido

a algum problema durante sua execução e que, ou a mudança foi abortada ou um

Fallback ocorreu, porém dentro da janela acordada com o cliente.

4.6.10 Premissas

As premissas que seguem são fundamentais para a definição doescopo do Processo Gerência de Mudanças:

• Cabe ao Solicitante da mudança fazer seu planejamento

técnico.

• Quando um pedido de mudança é feito, todas as informações

técnicas e de planejamento devem ser acompanhadas desde o



76

início do pedido.

• O processo de Gerência de Mudanças não possui envolvimento

direto com a fase de implementação da mudança, porém deverá

monitorá-la e registrar sua implementação.

4.6.11 Políticas Gerais

Abrangência: Esse processo se aplica à área da Engenharia envolvida

no atendimento da empresa X. As mudanças podem envolver os seguintes recursos:

• Hardware principal (CPU, Controladoras, Discos, Fitas,

Impressoras)

• Software produto (SW básico, SW de apoio, utilitários)

• Software Aplicativo (SW de Clientes, SW de terceiros)• Instalações Físicas (inclusive infra-estrutura predial)

• Hardware e Software de rede

• Rede (Telecomunicações Voz e Dados)

• Manutenção e desenvolvimento de aplicativos

• Sistemas distribuídos

Elegibilidade: Quem pode Solicitar:

• Os analistas de TI/Telecom da Engenharia.

• Os gerentes de projetos.

Quem Aprova. Existem diversos níveis de aprovação:

• Os analistas de TI/Telecom da Engenharia, avaliando o impacto

das mudanças em sua área de serviço.

• O Coordenador de Mudanças da empresa X, como aprovador

final somente em mudanças requisitadas pelos analistas e/ou

gerentes de projetos.

• Os Coordenadores de Tecnologia e da Engenharia, sinalizando

que a mudança foi negociada, aprovada e autorizada pelas

duas áreas.



77

4.6.12 Reunião de Mudanças

Reunião interna, realizada semanalmente às quartas-feiras, para

discutir as mudanças planejadas para serem executadas posteriormente.

O objetivo da reunião é:

• Discutir e analisar a viabilidade de cada mudança solicitada.

• Analisar os impactos no ambiente.

• Verificar o inter-relacionamento de cada mudança em relação à

outras mudanças solicitadas.

• Confirmar os executores da mudança, data da mudança,

período de tempo, data alternativa, etc.

• Discutir as atividades realizadas durante a mudança e verificarse foi incluído no planejamento o tempo para fallback.

Nessa reunião o grupo esclarecerá possíveis dúvidas e as áreas

envolvidas darão seu de acordo. A mudança só será considerada aprovada após o

de acordo dos coordenadores de Tecnologia e Engenharia.

4.6.13 Aprovação e de Acordo

Durante a Reunião de mudanças, todas as mudanças apresentadas

serão acordadas ou não pelo grupo técnico participante da reunião. Se não houver o

consenso do grupo para sua aprovação essa mudança será levada para outra

reunião mais técnica e específica (mudança crítica), onde serão discutidos com mais

detalhes. No caso de mudanças menos críticas, os facilitadores da engenharia

tomarão a decisão da aprovação ou não.

Estando a mudança acordada na reunião, serão buscados o de acordo

formal dos coordenadores de Tecnologia e Engenharia. Essa aprovação significaque a mudança foi negociada com o cliente, e autorizada pelo mesmo. Toda

mudança precisa da aprovação prévia do cliente para ser executada.

Quando existe necessidade da realização de uma mudança

emergencial fora do horário normal de expediente, cabe ao facilitador da Engenharia

conduzir o processo de aprovação.



78

4.6.14 Feedback das Mudanças

Após as mudanças serem realizadas, os solicitantes de mudanças

deverão coletar informações a respeito do resultado com os executores ou

participantes da mudança, com o intuito de verificar se a mudança foi realizada

conforme planejada.

4.6.15 Janela Técnica de Mudanças

A Janela Técnica de Mudanças é normalmente definida para minimizar

as negociações e os impactos de uma parada de sistema para o cliente e seus

usuários. Ou seja, dentro de uma janela, pode-se realizar uma mudança semnecessidade de concordância prévia do cliente, dado que já está negociada e

documentada em contrato essa parada.

4.6.16 Mudanças de Emergência

Mudanças de emergência poderão ocorrer a qualquer momento, desde

que sejam registradas adequadamente e negociadas com a Gerência de Mudanças.

Todas mudanças de emergência deverão sofrer primeiras uma triagem pelaEngenharia onde deverá ser comunicado e esclarecido o motivo da emergência,

cabendo ao coordenador da Engenharia avaliar sua real necessidade.

4.6.17 Cronologia das Solicitações de Mudanças

As mudanças são solicitadas até o 3º dia da semana corrente para que

possam ser executadas a partir do fim da semana seguinte.

4.7 Papéis e Responsabilidades

4.7.1 Responsabilidades da área de Tecnologia

• Informar ao coordenador da Engenharia qualquer mudança no

ambiente dos clientes que venha a afetar o ambiente de TI e



79

Telecom da empresa X, através do preenchimento do formulário

de Requisição de Mudanças do Cliente;

• Informar a Engenharia sobre qualquer alteração no

planejamento ou implementação das mudanças executadas pela

Tecnologia e/ou seus fornecedores que venham a afetar o

ambiente de TI e Telecom da empresa X;

• Analisar as mudanças apresentadas pela Engenharia;

• Colaborar na comunicação interna dos clientes da empresa X

sobre as mudanças;

• Negociar a aprovação dos clientes para a execução das

mudanças;

4.7.2 Responsabilidades da área de Engenharia

• Coordenar todas as mudanças solicitadas;

• Garantir a existência de planos de retorno para as mudanças;

• Em caso de falhas, garantir a implementação do plano de

retorno para as mudanças executadas pela empresa X;

• Aprovar ou rejeitar as mudanças apresentadas pela Tecnologia

que tenham impacto no negócio, custo ou afetem o ambiente deTI e Telecom da empresa X;

• Identificar e informar as mudanças e apresentar as informações

necessárias para o seu perfeito entendimento;

• Detalhar o cronograma e o planejamento das mudanças;

• Produzir toda a documentação necessária para a mudança;

• Alinhar previamente as mudanças com todas as áreas

envolvidas (mesmo nos casos emergenciais);

• Cancelar ou re-programar as mudanças quando necessário,

justificando motivo da ação;

• Avaliar os impactos das mudanças planejadas junto aos

solicitantes e representantes técnicos das várias áreas

envolvidas, garantindo que todos estejam cientes e em

concordância com a mudança;



80

• Coordenar as mudanças com as diversas áreas envolvidas na

sua execução, quando se aplicar;

• Comunicar todas as áreas afetadas sobre a mudança;

•

Executar as mudanças conforme o cronograma e atividadesdefinidas pelo solicitante das mudanças;

• Fornecer informações sobre qualquer problema ocorrido durante

a execução das mudanças;

• Interagir com o "Solicitante" para garantir que o requerimento de

mudança foi atendido, informando-lhe o status final e os

detalhes da execução;

Fornecer o relatório mensal de mudanças.

4.8 Cronograma de Implementação da ITIL

Na empresa X, o primeiro passo para implantação da ITIL, se iniciou no

processo de Gerenciamento de Mudanças, pois haviam vários problemas de TI e

Telecom no ambiente. Inicialmente foi escrito o documento da metodologia, a partir

da metodologia, foram criados formulários, nos quais são formalizadas: Solicitações

de Mudanças, Planejamento das Atividades, Avaliação de Riscos, Avaliação de

Impacto, Registro de Envolvidos, do Fluxo de Comunicação, Definição eHomologação das Contingências, Definição e Homologação de Planos de Retorno

entre outros.

Assim, após deixar o ambiente estável começou-se pensar nas

melhorias dando um segundo passo que foi a implantação do processo de Gestão

de Incidente.

Em situações onde, para prover a restauração do ambiente é

necessária a alteração de itens controlados. Depois veio outros processos:

Gerenciamento de Problemas, Releases, Gestão de Nível de Serviço, Gestão de

Configuração, Gestão de Capacidade, Gestão de Disponibilidade, Gerenciamento

Financeiro e Gestão de Continuidade dos Serviços de TI. Durante a implementação

desses processos houve a necessidade de comprar livros sobre o assunto e a

preparação da equipe em obter a certificação da ITIL Foundation.



81

4.9 Custo de implantação da ITIL

Conforme estudo de caso efetuado na empresa X, a implantação na

empresa foi baseada apenas nas certificações dos funcionários e compras de livros.

É certamente importante ler os livros da ITIL como ponto de começo

para determinar que categorias de processos são necessárias para uma

aproximação bem sucedida da gestão de serviços e, talvez até mais importante,

como essas categorias se inter-relacionam.

Depois de implementado e documentado, os processos da ITIL na

empresa, o custo gasto é com o software de gestão, que ainda está sendo analisado

pela empresa X em definir um software que seja adequado às necessidades da

empresa.

4.10 Certificações

O “Examination Institute for Information Science ” (EXIN) e o

“Information Systems Examinations Board ” (ISEB), juntos desenvolveram uma

certificação profissional para a ITIL. Isto foi feito em cooperação com o OCG e

ITSMF. O EXIN e ISEB são organização sem fins lucrativos que cooperam para

oferecer uma escala de qualificação da ITIL em três níveis:Certificado Foundation em Gerenciamento de Serviços em TI

Certificado Practioner em Gerenciamento de Serviços em TI

Certificado Manager em Gerenciamento de Serviços em TI

O sistema de certificação é baseado nas exigências para cumprir o

papel relevante dentro de uma organização de TI. Para registrar, os certificados

foram concedidos para mais 170.000 profissionais de TI em mais 30 países.

O certificado Foundation é direcionado para todo o pessoal que tem

que estar ciente das tarefas principais de uma organização de TI, e as conexõesentre elas. Destinado às pessoas que atuam na área de Gerenciamento de Serviços

de TI, esta é a primeira das certificações da ITIL e é pré-requisito para as demais.

Não há nenhum pré-requisito necessário para se prestar este exame,

apenas é necessário que se tenham os devidos conhecimentos da ITIL sob a

seguinte perspectiva:

A importância do Gerenciamento de Serviços;



82

Os processos do Gerenciamento de Serviços e as interfaces entre

eles;

Os processos da ITIL e seus relacionamentos;

Familiaridade com os conceitos básicos de ITIL.

Além disto, é recomendável estar familiarizado com a terminologia da

ITIL e seus conceitos.

Após ter obtido o certificado Foundation , o candidato poderá realizar os

exames do Practioner e do Manager . Para se certificar, o candidato deve se

especializar em pelo menos uma disciplina de Service Support ou Service Delivery

(em alguns casos são grupos de disciplinas), com foco na sua experiência na área

escolhida.

Cada exame busca aferir a habilidade do candidato para planejar umprocesso da ITIL e conduzir as atividades pertinentes e ele. Os exames disponíveis

são:

Practitioner Certificate in Incident Management/Service Desk;

Practitioner Certificate in Problem Management;

Practitioner Certificate in Change Management;

Practitioner Certificate in Configuration Management;

Practitioner Certificate in Service Level Management;

Practitioner Certificate in Availability Management;

Practitioner Certificate in Release Management;

Practitioner Certificate in Capacity Management;

Practitioner Certificate in Financial Management;

Practitioner Certificate in Security Management.

Já no nível Manager são treinados para poder controlar estes

processos, dar recomendações sobre a estrutura e a otimização dos processos, e

implementá-los. Este é o nível mais avançado dos programas de certificação em

ITIL. Com esta qualificação, o profissional deve ser capaz de analisar umaorganização existente e definir estratégias para o gerenciamento da intra-estrutura

de TI. Deve também conseguir avaliar os processos existentes e organizá-los de

maneira sistemática. Para atingir esta certificação, o candidato deve ter o

conhecimento e experiência na utilização dos processos operacionais e dos

processos táticos da ITIL. São dois os exames para a especialização:



83

Manager Certificate in Service Delivery

Manager Certificate in Service Support

Os resultados obtidos após a implantação da ITIL na empresa X,

foram: um melhor controle a infra-estrutura de TI assegurando o uso somente do

hardware e software homologados, continuidade do nível de serviço suportado pelo

Service Desk, redução da quantidade de problemas recorrentes, garantia que

apenas os softwares com licenças estejam instalados nas máquinas dos usuários,

garantia do uso dos recursos de TI, garantia de uma rápida recuperação após um

desastre e um gerenciamento eficiente e eficaz das mudanças.

Antes da ITIL a empresa X gerava alto índice de indisponibilidade com

mudanças mal planejadas ou sem planejamento. Um dos grandes resultados obtidos

foi manter o ambiente estável, garantindo a disponibilidade dos serviços prestados.

0

20

40

60

80

100

120

140

160

180

Planejadas 73 76 63 34 46 37 40 42 39 55 66 159

Realizadas 54 78 64 36 38 45 39 44 38 53 59 159

Jan Fev Mar Abr Mai Jun Jul Ago Set Out Nov Dez

Figura 26. Total de mudanças Planejadas e Realizadas por mês no ano de 2006

durante a implantação da ITIL. (Empresa X, 2007)

A figura 26 mostra que durante a implantação da ITIL no ano de 2006

quase todas as mudanças planejadas eram Realizadas.



84

0

10

20

30

40

50

60

Emergencial 37 54 43 22 15 25 23 30 17 13 16 20

Programada 8 4 9 10 10 13 20 23 21 32 38 40

Acelerada 9 10 12 4 12 7 11 6 10 8 5 3


Figura 27. Comparação, tipos de Mudança: Emergencial, Programada e Acelerada

no ano de 2006 por mês, durante a implantação da ITIL. (Empresa X, 2007)

A figura 27 mostra que no início da implantação da ITIL os números de

mudanças Emergenciais foram maiores do que as mudanças Programadas. Porém,durante o ano o número de mudanças Emergenciais diminuíram e o número de

mudanças Programadas ultrapassou o número de mudanças Emergenciais.

Mudanças Emergenciais são mudanças que precisam ser executadas

no exato momento, antes da realização do próximo Comitê de Mudanças, por

exemplo, um servidor que esta causando uma falha em um serviço, podendo gerar

indisponibilidade por todos acessados por ele, Programadas, são mudanças que

passaram pelo Comitê e possuem uma data e hora para serem executadas, já as

mudanças Aceleradas são mudanças que não precisam ser executadas agora, mas

também não podem esperar o próximo Comitê para sua aprovação.



85

0

5

10

15

20

25

30

35

40

45

Emergencial 19 19 10 5 3

Programada 42 39 20 22 16

Acelerada 8 10 2 4 1

Jan Fev Mar Abr Mai

Figura 28. Comparação, tipos de mudança: Emergencial, Programada e Acelerada


A figura 28 mostra que no início do ano de 2007 o número de

mudanças Programadas é maior que a quantidade de Mudanças Emergenciais e

Aceleradas, obtendo assim um maior planejamento nas mudanças a serem

executadas no ambiente mostrando assim que após a implantação da ITIL a

organização atinge um nível de repentibilidade.



86

30

44 46

28 2939

4755

4652

59 60

14 15 146 4 2 4 2 2 0 0 2

10 94 2 4 4 3 2 0 1 0 1

0

10

20

30

40

50

60


Cancelada

Falha

Sucesso

Figura 29. Comparação dos Resultados das mudanças: Sucesso, Falha e Cancelada


A figura 29 mostra que durante o início da implantação da ITIL o

número de mudanças executadas com falha, mal planejadas ou canceladas era

grande. Durante o ano, as mudanças passaram a ser mais planejadas e

programadas, assim o índice de mudanças executadas com falha ou canceladasdiminuíram.



87

68 68

30

20

0 0 2 0

1 0 0 00

10

20

30

40

50

60

Jan Fev Mar Abr

Cancelada

Falha

Sucesso

Figura 30. Comparação dos Resultados das mudanças: Sucesso, Falha e Cancelada


A figura 30 mostra que o trabalho executado durante o ano de 2007,após a implantação da ITIL, especificamente o processo de Gerenciamento de

Mudanças obteve – se resultados positivos. A quantidade de Mudanças com

Sucesso foram bem maiores do que no início do ano de 2006, e a quantidade de

alterações no ambiente foram bem menores, mantendo o ambiente disponível em

relação ao ano anterior, quando as mudanças eram executas, porém falhavam por

não terem sido bem planejadas.



88

5 CONCLUSÕES

O trabalho descreve a importância da governaça de TI, as melhores

práticas e os processos da metodologia ITIL focando o estudo no processo de

Gerenciamento de Mudanças, identificando seu escopo de atuação, analisando seusbenefícios e a relação deste com outros processos da ITIL.

Os principais objetivos obtidos através deste trabalho foram: analisar a

importância da Governança de TI, a importância da ITIL na organização bem como a

importância do processo de Gerenciamento de Mudanças baseado nos resultados

apresentados no estudo de caso.

A implementação dos processos baseados na ITIL está relacionada

diretamente a um profundo e extenso programa de mudança, fazendo com que a

equipe da área de TI adotem um novo comportamento, para isto serve a governançade TI, para controlar os objetivos da área de tecnologia, alinhar as estratégias, definir

expectativas e medidas de desempenho, viabilizando e gerenciando recursos,

definindo prioridades, direcionando as atividades de TI e gerenciando riscos.

Algumas empresas têm mais sucessos do que outras na

implementação da ITIL, para uma implementação eficaz de ITIL, não basta conhecer

as melhores práticas, especialmente no que se refere aos benefícios em longo prazo

para o negócio e ao alcance de uma situação de excelência dentro da organização

de TI. Idealmente, uma implementação de ITIL com sucesso significa que as

pessoas da organização assimilaram na sua cultura, os processos e procedimentos

da ITIL. O fundamental é que a adoção da ITIL permitirá a adoção de uma cultura de

melhoria contínua de qualidade dos serviços prestados pela área de TI, que, no

mínimo, garantirá a manutenção dos ganhos já obtidos.

Mudanças descontroladas ou resoluções de problemas podem estar

causando um impacto significativo relacionado aos componentes e aos sistemas, e

pode conduzir a uma quantia significante de tempo desperdiçado, dentro do

diagnóstico de um problema e a restauração de serviço interrompido, assim as

organizações estão cautelosas, assegurando um controle total sobre o pessoal da

organização, administrando as mudanças sem que haja problemas nos processos

de Gerenciamento de Mudanças.

No estudo de caso apresentado teve-se como principais benefícios no

Gerenciamento de Mudanças um maior índice de assertividade, otimização dos



89

custos relacionadas às alterações no ambiente, melhoria no fluxo de comunicação,

geração e utilização da base de conhecimento e alinhamento com o negócio.

Sugestões para trabalhos futuros são: descrição de ferramentas

utilizadas após a implementação da ITIL na gestão de TI, descrição de como são

executados todos os processos, após alguns anos implementados a ITIL na

empresa e como trabalhar com a ITIL junto com outras metodologias.



90

REFERÊNCIAS BIBLIOGRÁFICAS

CA, Service Management Solution. ITIL® e Gerenciamento de Serviços. 2007.

Disponível em <http://www.ca.com/br/itil.htm>. Acesso em 26 Mar. de 2007.

CA, Service Management Solution. Provando o Valor de TI para o Negócio. 2006.

Disponível em <http://www.calatam.com/cante/ca/eitm/brochure%20-%20service%

20management.pdf>. Acesso em 10 Mar. de 2007.

CAMURUGY, Patrícia. ITIL na Governança de TI. 2005. Disponível em

<http://www.timaster.com.br/revista/artigos/main_artigo.asp?codigo=984>. Acesso em

12 Mar de 2007.

COMPANY WEB, TI & Negócios. Os perigos de Mudar. 2004. Disponível em

<http://www.companyweb.com.br/lista_artigos.cfm?id_artigo=28>. Acesso em 21 de

Abr de 2007.

DOMINGUES, Heron. Em TI, o que não se mede não se gerencia. 2004. Disponível

em <http://webinsider.uol.com.br/vernoticia.php/id/2286>. Acesso em 10 de Mar. de

2007.

ESPILDORA, Francisco Gentil. Excelência na Gerência de Serviço. 2004. Disponível

em <http://www.serpro.gov.br/publicacao/tematec/tematec/2004/ttec72>. Acesso em 23

Mar de 2007.

FRY, Malcolm. Selling ITIL: Building a Case for Pursuing ITIL Best Pratices in your

Organization. Sunnyvale, USA: Remedy, 2003.

GHERMANa, Marcelo. Controles Internos - Buscando a solução adequada – Parte

I. 2005. Disponível em <http://www.checkuptool.com.br/artigo_04.htm>. Acesso em 22

Mar de 2007.



91

GHERMANb, Marcelo. Controles Internos - Buscando a solução adequada – Parte

II. 2005. Disponível em <http://www.checkuptool.com.br/artigo_06.htm>. Acesso em 22

Mar de 2007.

GHERMANc, Marcelo. Controles Internos - Buscando a solução adequada – Parte

III. 2005. Disponível em <http://www.checkuptool.com.br/artigo_07.htm>. Acesso em

22 Mar de 2007.

GHERMANd, Marcelo. Controles Internos - Buscando a solução adequada – Parte

IV. 2005. Disponível em <http://www.checkuptool.com.br/artigo_08.htm>. Acesso em

22 Mar de 2007.

GHERMANe, Marcelo. Controles Internos - Buscando a solução adequada – Parte

V. 2005. Disponível em <http://www.checkuptool.com.br/artigo_10.htm>. Acesso em 22

Mar de 2007.

ITISMF - IT Service Management Forum. IT Service Management, an Introduction.

Sd. Reino Unido: ITSMF.2001.

MAGALHAES, Ivan Luizio. ; PINHEIRO, Walfrido Brito. Gerenciamento de Serviçosde TI na Prática: Uma abordagem com base na ITIL® . São Paulo. Novatec, 2007.

MAGALHÃES, Eduardo. Há uma nova T.I. com a ITIL e Cobit?. 2006. Disponível em

<http://tecnologia-da-informacao.blogspot.com/2006_09_01_tecnologia-da-

informacao_archive.html>. Acesso em 25 de Abr de 2007.

MANSUR, Ricardo. Governança de TI. 2006. Disponível em

<http://www.profissionaisdetecnologia.com.br/modules.php?name=News&file=article&sid=63>. Acesso em 10 de Mar. de 2007.

OGCa, Office of Government Commerce. Service Delivery. Londres – Inglaterra:The Stationary Office, 2001.

OGCb, Office of Government Commerce. Service Support. Londres – Inglaterra:The Stationary Office, 2001.



92

OGC, Office of Government Commerce. IT Infrastructure Library ITIL: the key to

managing IT services. 2006. Disponível em < http://www.itil.co.uk/>. Acesso em 26

Mar de 2007.

PNAGE, Programa Nacional de Apoio à Modernização da Gestão e do Planejamento

dos Estados Brasileiros e do Distrito Federal. Proposta: Cooperação e

Compartilhamento. 2005. Disponível em < http://www.planejamento.gov.br/

arquivos_down/pnage/PINAG1.pdf>. Acesso em 26 Mar de 2007.

TAURION, César. A importância da TI: ferramenta para mudanças

organizacionais. 2005. Disponível em <http://www.tracesistemas.com/extranet/

novosite.nsf/materia_detalhe?OpenForm&id=taurion_01>. Acesso em 21 de Abr de2007.

TERRA, Maria Cristina; SOIHET, Elena. Índice de controle de capitais: uma análise

da legislação e seu impacto sobre o fluxo de capital no Brasil no período 1990-

2000. 2006. Disponível em <http://www.scielo.br/scielo.php?script=sci_arttext&pid=

S0101-41612006000400003&lng=en&nrm=iso> ou < http://www.scielo.br/pdf/ee/v36n4/

a03v36n4.pdf>. Acesso em 10 de Mar. de 2007.

TI MASTER. A ITIL é pra todos. 2007. Disponível em <http://www.timaster.com.br/

revista/materias/main_materia.asp?codigo=1233&pag=2>. Acesso em 4 Jun. de

2007.

WEILL, Peter. ; ROSS, Jeanne W. Governança de TI: Tecnologia da Informação.

Revisão técnica de Tereza Cristina M. B. Carvalho. São Paulo. M. Books do Brasil,

2006.

WIKIPÉDIA. A enciclopédia livre. 2007. Disponível em: <http://pt.wikipedia.org/wiki/

PDCA>. Acesso em 7 de Abr. de 2007.

Documents

Monografia Marden Rolim