0
UNIÃO EDUCACIONAL MINAS GERAIS S/C LTDA
FACULDADE DE CIÊNCIAS APLICADAS DE MINAS
Autorizada pela Portaria no 577/2000 – MEC, de 03/05/2000
BACHARELADO 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 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.
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 privarse 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ço
especialmente 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 para
vá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 several
organizations. 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.......................................69
Quadro 3. Classificação de Riscos............................................................................72
9
LISTA DE ABREVIATURAS E SÍMBOLOS
CAB – Change Advisory Board
CCM – Conselho de Controle de Mudanças
CCTA
–
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 (SERVICE DESK)..................................................................................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 (SERVICE SUPPORT) .............................................................................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 (SERVICE DELIVERY).............................................................................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
4.2
4.3
DESCRIÇÃO DA EMPRESA .........................................................................................................67
VISÃO GERAL DO PROCESSO DE GERENCIAMENTO DE MUDANÇA ...............................................67
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íses
desenvolvidos 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 normas
que 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 aconteceram
també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
1
de proteger seus stakeholders . 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 Infraestrutura 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 Framework2 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, Compliance3, 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 do
negó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 qualidades
té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” da
metodologia, 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 e
as 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 estabelecido
o 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 InfraEstrutura de Tecnologia da Informação) é a metodologia para gerenciamento de
serviços em TI mais utilizada e mais conhecida mundialmente, e que um dos
principais 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 tornou
proprietá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.
SERVICE
DESK
SERVICE
SUPPORT
SERVICE
DELIVERY
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
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 o
controle 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 metodologia
para 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 – IT
Service 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 melhor
puder 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 ServiceDesk, é 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 de
suporte 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 da
empresa 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 de
serviç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 custos
operacionais, 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 e
controlá-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 infraestrutura (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 neste
processo 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ável
para 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 ser
encontrada 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. A
resolução de erros conhecidos normalmente necessita de uma modificação na infraestrutura 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 apagar
incê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 sejam
concluí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 de
problemas. 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 as
operaçõ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 como
Change 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ê, por
exemplo, 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 novo
software 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).
Antes do
Gerenciamento de
Liberação
•
Alto risco a vírus
•
Incidentes/Problemas
devido a plano de
liberação de software
fraco
•
•
Aumento na carga de
trabalho com múltiplas
versões em produção
Implementação do
Gerenciamento de
Liberação
Após o
Gerenciamento de
Liberação
•
Redução do risco a vírus
•
Redução de Incidentes /
Problemas devido a
liberações de softwares
fracas
•
Melhor aproveitamento
dos recursos (Equipe de TI
e software e hardware)
Perda dos softwares
originais que foram
comprados
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.
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 processos
TI 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 de
indisponibilidades 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 do
suporte, 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 o
ví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 os
usuá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 de
impacto 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 infraestrutura 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ável
pela 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 mais
desastres 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 tempo
requeridas 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 do
negó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 a
elaboraçã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.
Business, Customers or Users
Difficulties
Queries
Enquiries
Management
Tools
Incidents
Incidents
Incident
Management
Communications
Updates
Workarounds
Service Desk
Changes
Releases
Problem
Management
Change
Management
Release
Management
Configuration
Management
CMDB
Incidents
Problems
Known Errors
Changes
Releases
CI’s
Relationships
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
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.
Business, Customers and Users
Availability
Management
Queries
Enquiries
Availability Plan
Design Criteria
Targets/Thresholds
Reports
Audit Reports
Service Level
Management
Requirements
Targets
Achievements
Capacity
Management
Alerts &
Exceptions
Changes
Management
Tools
Capacity Plan
CDB
Targets/Thresholds
Capacity Reports
Schedules
Financial Management
for IT Services
Financial Plan
Types & Models
Costs & Charges
Reports
Budgets & Forecasts
Audit Report
Communications
Updates Reports
SLA’s, SLR’s, OLA’s
Service Reports
Service Catalogue
SIP
Exception Reports
Audit Reports
IT Service Continuity
Management
IT Continuity Plans
BIA & Risk Analysis
Control Centres
DR Contacts
Reports
Audit Reports
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ão
gerados 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
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 implementadas
as 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 da
mudanç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 a
operaçã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.
BCO de DADOS do
Gerenciamento da
Configuração (CMDB)
Requisições de
Mudanças
(RDMs)
•
•
•
•
Programação
Futura de
Mudanças (PFM)
•
Gerenciamento
da Capacidade
Avaliação e Registro das
Mudanças
Análise do impacto, custo,
benefícios e riscos associados
Justificativa e aprovação das
Mudanças
Controle das Mudanças e do
Processo de Mudança
Instauração do comitê de Controle
de Mudanças (CCM) e do Comitê de
Emergência (CCM/CE)
Gerenciamento
da
Configuração
Programação
futura de
Mudanças(PFM)
Requisições de
Mudança
(RDMs)
Atas de reunião
do CCM e
Ações
Relatórios do
Gerenciamento
de Mudanças
Gerenciamento
de Liberações
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,
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.
Projeto
Gerenciamento de Mudanças
Monitoração e
Planejamento
Registro e Classificação
Desenvolvimento
Aprovação
Recusa
Teste
Autorização e
Implementação
Recusa
RDM
Implementação
Backout
Avaliação
Figura 22. Limites entre Administração de Mudança e administração de programa.
(OGCa, 2001, p. 166).
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 para
se 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 riscos
permite 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 o
controle 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 apenas
como
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 uma
metodologia 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 empresa
A 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:
Categ
oria
1
(Crític
a)
Descrição
Uma mudança de alta complexidade:
Envolve
um
longo
período
de
implementação, um longo
tempo para
"'backout'', cujo backout envolve uma perda
do serviço e , ainda um dos seguintes itens:
Mais que um projeto está envolvido ou
impactado pela mudança;
Mais que um Serviço da Organização de
Delivery está envolvido ou impactado pela
mudança;
Mais que um ambiente é impactado pela
mudança;
As organizações envolvidas têm pouca ou
nenhuma experiência na implementação
da mudança.
Tratamento
Aceitação de risco
necessária para riscos de
negócio e técnico.
Revisão, programação e
aceitação de risco através
de aprovação formal.
Programação é requerida
Mudança de grande complexidade, mas
para assegurar:
que não atende aos critérios de criticidade - Coordenação entre grupos
2
(Maior da categoria 1.
- Comprometimento
Vai ocasionar indisponibilidade para o
Gerencial na alocação dos
)
cliente, no entanto esta já foi negociada
recursos envolvidos
previamente.
- Revisão e aprovação
formais
3
Revisão
para assegurar:
Tempo
curto
de
indisponibilidade,
(Médio previamente acordado com o cliente.
- Conhecimento geral
)
- Especificação de detalhes
Usuários familiarizados com a mudança
técnicos
Planejamento
e Revisão
4
para assegurar
(Meno Mudança de mínima complexidade
conhecimento geral e
r)
fallback simples e rápido.
5
Registro para propósito de
Inform Mudança sem nenhum risco
gerenciamento
ativa
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
20 dias
corridos
Maior
14 Dias
corridos
Média
8 Dias úteis
Menor
7 Dias úteis
Informativa
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ão
demanda 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 devem
colaborar.
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
2 a 3 sistemas/aplicativos online
1 sistema/aplicativo online
Recursos Requeridos para Preparar/Implementar:
3 ou mais grupos de suporte
2 ou mais pessoas em dois grupos de suporte
2 ou mais pessoas do mesmo grupo de suporte
1 pessoa
Esforço de Preparação:
1
2
3
1
2
3
4
73
30 dias ou mais
2 a 29 dias
1 dia
< 1 dia
Exposição a Falhas:
Sem possibilidade de fallback
Fallback difícil / demorado ou não desejável
Fallback nível moderado
Fallback fácil
Quantidade de Usuários Afetados
Mais do que 50% dos usuários do serviço
Até 10% dos usuários do serviço
1 ou nenhum usuário do serviço
Se Total =
5a8
9 a 12
13 a 16
17 a 20
1
2
3
4
1
2
3
4
1
2
3
Risco da
Mudança:
Crítico
Alto
Médio
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 essenciais
para 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 o
tempo 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 do
escopo 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
duas áreas.
autorizada pelas
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 verificar
se 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 significa
que 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 sem
necessidade 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 pela
Engenharia 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 de
TI 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
envolvidas, garantindo que todos estejam
concordância com a mudança;
várias
cientes
áreas
e em
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 atividades
definidas 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 e
Homologaçã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ões
entre 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 um
processo 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 uma
organizaçã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.
180
160
140
120
100
80
60
40
20
0
Jan
Fev
Mar
Abr
Mai
Jun
Jul
Ago
Set
Out
Nov
Dez
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
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
60
50
40
30
20
10
0
Jan
Fev
Mar
Abr
Mai
Jun
Jul
Ago
Set
Out
Nov
Dez
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
45
40
35
30
25
20
15
10
5
0
Jan
Fev
Mar
Abr
Mai
Emergencial
19
19
10
5
3
Programada
42
39
20
22
16
Acelerada
8
10
2
4
1
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)
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
60
50
40
44
30
30
20
10
46
15
14
10
0
9
60
59
52
46
Sucesso
14
4
39
29
28
55
47
6
2
4
4
4
2
4
Jan Fev Mar Abr Mai Jun
3
2
2
2
0
0
1
2
0
0
1
Falha
Cancelada
Jul Ago Set Out Nov Dez
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)
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 canceladas
diminuíram.
87
60
50
68
68
40
30
30
20
20
Sucesso
10
0
0
2
0
0
1
0
0
0
Jan
Fev
Mar
Abr
Falha
Cancelada
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)
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 seus
benefí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ça
de 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ços
de 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-dainformacao_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&s
id=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
Compartilhamento.
e
2005.
do Distrito
Disponível
Federal.
em
<
Proposta:
Cooperação
e
http://www.planejamento.gov.br/
arquivos_down/pnage/PINAG1.pdf>. Acesso em 26 Mar de 2007.
TAURION,
César.
organizacionais.
A
2005.
importância
Disponível
da
em
TI:
ferramenta
para
mudanças
<http://www.tracesistemas.com/extranet/
novosite.nsf/materia_detalhe?OpenForm&id=taurion_01>. Acesso em 21 de Abr de
2007.
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 19902000. 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.