CENTRO PAULA SOUZA

FACULDADE DE TECNOLOGIA DE TAQUARITINGA

CURSO SUPERIOR DE TECNOLOGIA EM
PROCESSAMENTO DE DADOS

DESENVOLVIMENTO DE SISTEMA WEB PARA ATENDER

AS NECESSIDADES DA EMPRESA BRAND COSMÉTICOS

AUTOR: GUILHERME MAZZO PELUZZO

ORIENTADOR: PROF.º JOÃO DE LUCCA FILHO

Taquaritinga
2011
 GUILHERME MAZZO PELUZZO

DESENVOLVIMENTO DE SISTEMA WEB PARA ATENDER

AS NECESSIDADES DA EMPRESA BRAND COSMÉTICOS

Relatório técnico de estágio apresentado à Faculdade de

Tecnologia de Taquaritinga, como parte dos requisitos para a
obtenção do título de Tecnólogo em Processamento de Dados.

Orientador: Prof.º João de Lucca Filho

Taquaritinga
2011
 FOLHA DE APROVAÇÃO
Guilherme Mazzo Peluzzo
Desenvolvimento de sistema web para atender as necessidades da empresa Brand Cosméticos.

Relatório Técnico de estágio apresentado à

Faculdade de Tecnologia de Taquaritinga, como
parte dos requisitos para a obtenção do título de
Tecnólogo em Processamento de Dados.

Data da aprovação: ___/___/___.

Banca Examinadora

___________________________________________________________________________
Nome
___________________________________________________________________________
Instituição
___________________________________________________________________________
Assinatura

___________________________________________________________________________
Nome
___________________________________________________________________________
Instituição
___________________________________________________________________________
Assinatura

___________________________________________________________________________
Nome
___________________________________________________________________________
Instituição
___________________________________________________________________________
Assinatura
 Dedico,

Aos meus pais, pela fé que tiveram na minha vida

desde o monento da minha concepção
 AGRADECIMENTOS

Primeiramente a Deus, por ter me dado o sopro da vida e por estar presente em todos os
momentos dela.

Aos meus pais, pelo amor incondicional que deram à mim, mesmo quando todas as
circunstâncias levavam a crer que não haveria saída.

À minha avó Neusa, pelo amor imenso e carinho que teve comigo e com meus irmãos durante
a nossa infância.

Aos meus irmãos, por serem meus melhores amigos e companheiros. Por estarem por perto
nas melhores e nas piores horas.

Aos professores que, desde quando ingressei na vida acadêmica, estimularam o meu
desenvolvimento e, assim, moldaram boa parte do que sou hoje.

Cabe aqui também um agradecimento especial a algumas pessoas que me proporcionaram

lições impressionantes, tanto pessoal quanto profissionalmente: Alan Teodoro, Thaysa Bello,
Angelo Satelite, Esdras Barreto, Cleber Ramos, Oswaldo Mauricio Neto, João Amanti, Ivan
Fabbri, Eduardo Ferreira, Tiago Pichonelli, Addo Grossi, Rodrigo Malara, Marcos Selli, Paulo
Paschoalino, Hebron Corso, Ricardo Camargo, Diony Rodrigues, Vitor Santos, Ildebrando
Cortonezi, Odazil Junior, Gustavo Silva entre outros.
“Será necessária a dura luz do desastre para mostrar a
verdadeira natureza de uma pessoa?.”

Jean-Dominique Bauby
PELUZZO, G. M. . Desenvolvimento de sistema web para atender as necessidades da
empresa Brand Cosméticos. Trabalho de Conclusão de Curso (Relatório Técnico de
Estagio). Centro Estadual de Educação Tecnológica "Paula Souza". Faculdade de Tecnologia
de Taquaritinga, 2011. 66p.

RESUMO

O objetivo deste trabalho é demonstrar o processo de desenvolvimento de um sistema web,

utilizando-se para isto a plataforma Enterprise da linguagem Java (J2EE). Este sistema foi
desenvolvido para uma empresa real, a qual será denominada Brand Cosméticos neste
trabalho.
O sistema foi implementado com base nas melhores práticas disponibilizadas pela
comunidade desenvolvedora e utilizando-se de ferramentas como PMD e Checkstyle para
garantir a aplicação das melhores práticas de qualidade de software. A idéia do
desenvolvimento do sistema, que chamaremos de SPECTRA Redesign, surgiu na necessidade
de substituir substituir o sistema anterior, SPECTRA Plus, construído na linguagem
Powerbuilder, por motivos que serão detalhados neste trabalho.
No decorrer dos capítulos, mostraremos a situação inicial, os motivos pelo qual foi realizado o
redesign do sistema em questão. Os resultados obtidos serão demonstrados no ultimo capítulo
deste trabalho, de forma comparativa.

Palavras Chaves: Java. J2EE. Sistemas Web. Java Enterprise Edition

 ABSTRACT

The objective of this Student Intern Report it’s to demonstrate the development process of an
web-based system using the Java Enterprise Edition platform (J2EE). This system was
developed for a real cosmetics company here called by the fictious name of Brand Cosmetics.
The system was built based on the best programming practices provided by the software
community and using for this purpose some tools such as PMD and Checkstyle to assure the
application of the best quality practices. The idea of the development of this system, here
known by the name of SPECTRA Redesign, appeared with the need of replacement of his
predecessor, SPECTRA Plus, built with the Powerbuilder programming language. The
reasons of the need cited above will be explained during this paper.
In the following chapters we’ll show the initial situation, the reasons why SPECTA Plus was
redesigned. The results will be shown in the last chapter of this paper in a comparative way.

Keywords: Java. J2EE. Web-based System .Java Enterprise Edition.

 SUMÁRIO

INTRODUÇÃO.......................................................................................................................15

1 EMPRESA.........................................................................................................................17

1.1 Introdução........................................................................................................................17
1.2 Histórico Cronológico......................................................................................................18
1.3 Organograma....................................................................................................................21
1.4 Layout..............................................................................................................................22

2 FUNDAMENTAÇÃO TEÓRICA....................................................................................23

2.1 Introdução ao Cenário ITIL.............................................................................................23

2.2 Evolução da ITIL.............................................................................................................25
2.3 Introdução a ITIL V3.......................................................................................................25
2.4 Estrutura da ITIL V3........................................................................................................26
2.5 Ciclo de Vida do Serviço.................................................................................................28
2.6 Estagios do Ciclo de Vida do Serviço..............................................................................30
2.6.1 Estratégia do Serviço.....................................................................................................30
2.6.2 Desenho do Serviço.......................................................................................................30
2.6.3 Transição do Serviço.....................................................................................................31
2.6.4 Operação do Serviço.....................................................................................................31
2.6.5 Melhoria continuada do Serviço...................................................................................31

3 PROJETO FICTPREV.....................................................................................................33

3.1 Situação Inicial.................................................................................................................33

3.2 A identificação da necessidade de uma modelagem de fluxo de atendimento................34
3.3 O processo de desenvolvimento do modelo de fluxo de atendimento.............................35
3.4 Definindo quais serviços deveriam ser prestados............................................................35
3.4.1 Manutenção Corretiva...................................................................................................36
3.4.2 Análise de Causa Raiz...................................................................................................36
3.4.3 Melhoria........................................................................................................................37
3.4.4 Novas Solicitações (Acima de 350 h abordagem de projeto).......................................38
3.4.5 Atualização de arquivos, noticias no portal de conteúdo (Vignette). Criação de Senhas
e Reset de Senhas......................................................................................................................38
3.4.6 Suporte Disponível........................................................................................................39
3.5 Definindo Responsabilidades em relação ao Cliente.......................................................40
3.5.1 Do gerenciamento do Projeto FictPrev Apliações.........................................................40
3.5.2 Controle de Configuração, Métricas e Controle de Qualidade:...................................41
3.5.3 Equipe de Suporte à Produção:.....................................................................................41
3.6 Desenhando o Fluxo de Atendimento..............................................................................42
3.6.1 Fluxo para atendimento de Manutenção Corretiva.......................................................43
3.6.2 Fluxo para atendimento de Análise de Causa Raiz.......................................................44
3.6.3 Fluxo para atendimento de Melhorias e Novas Solicitações.........................................45
3.7 Desenvolvimento de um Sistema de Chamados..............................................................47
3.7.1 Catastrófico (Severidade 1):..........................................................................................47
3.7.2 Maior – Sem Solução Temporária (Severidade 2):.......................................................47
3.7.3 Maior – Com Solução Temporária (Severidade 3):.......................................................48
3.7.4 Menor (Severidade 4):...................................................................................................48
3.7.5 Cosmético (Severidade 5):............................................................................................48
3.7.6 Interno (Severidade 6):..................................................................................................49
3.8 Construindo a documentação necessária de acordo com os tipos de atendimento
suportados.................................................................................................................................50
3.8.1 Manutenção Corretiva...................................................................................................50
3.8.2 Análise de Causa Raiz...................................................................................................51
3.8.3 Melhoria/Novas Solicitações.........................................................................................53
3.8.3.1 Ata de Reunião:..........................................................................................................53
3.8.3.2 Documento de Estimativa:.........................................................................................54
3.8.3.3 Documento de Implementação:..................................................................................54
3.8.3.4 Documento de Revisão:.............................................................................................54
3.8.3.5 Documento de Descrição das Mudanças:...................................................................55
3.9 Apresentação e Treinamento da Equipe...........................................................................58
3.10 Os resultados obtidos com as mudanças implantadas......................................................58
3.10.1 Sobre o relacionamento com o cliente (FICTPREV)..................................................58
3.10.2 Sobre Infraestrutura.....................................................................................................59
3.10.3 Sobre Processos...........................................................................................................59
3.10.4 Sobre a equipe projetoFictPrev...................................................................................59
3.10.5 Sobre os atendimentos.................................................................................................59
3.10.5.1 Percentual de Tipos de chamados abertos................................................................59
3.10.5.2 Comparativo sobre Números de Chamados Abertos................................................60
3.10.5.3 Demonstração de Reincidencia de Chamados.........................................................61
3.10.6 Sobre Custos................................................................................................................62
 LISTA DE ILUSTRAÇÕES

Ilustração 1 – Logo da Empresa HP.........................................................................................18

Ilustração 2 – Organograma do Projeto FictPrev da Empresa HP............................................21
Ilustração 3 – Mapa Físico do Site de Araraquara da HP.........................................................22
Ilustração 4 – Evolução da ITIL...............................................................................................25
Ilustração 5 – Ciclo de Vida do Serviço....................................................................................28
Ilustração 6 – Fluxo de Atendimento para Manutenção Corretiva...........................................43
Ilustração 7 – Fluxo de Atendimento para Análise de Causa Raiz...........................................44
Ilustração 8 – Fluxo de Atendimento para Melhorias e Novas Solicitações I..........................45
Ilustração 9 – Fluxo de Atendimento para Melhorias e Novas Solicitações II.........................46
Ilustração 10 – Demonstração de Template de Documento de 5 passos do Projeto FictPrev. .51
Ilustração 11 – Demonstração de Template de Documento de Análise de Causa Raiz Projeto
FictPrev I...................................................................................................................................52
Ilustração 12 – Demonstração de Template de Documento de Análise de Causa Raiz Projeto
FictPrev II.................................................................................................................................53
Ilustração 13 – Demonstração de Template de Documento de Implementação Raiz Projeto
FictPrev.....................................................................................................................................54
Ilustração 14 – Demonstração de Template de Documento de Descrição das Mudanças Raiz
Projeto FictPrev I......................................................................................................................55
Ilustração 15 – Demonstração de Template de Documento de Descrição das Mudanças Raiz
Projeto FictPrev II.....................................................................................................................56
Ilustração 16 – Demonstração de Template de Documento de Descrição das Mudanças Raiz
Projeto FictPrev III...................................................................................................................56
Ilustração 17 – Demonstração de Template de Documento de Descrição das Mudanças Raiz
Projeto FictPrev IV...................................................................................................................57
Ilustração 18 – Demonstração de Template de Documento de Descrição das Mudanças Raiz
Projeto FictPrev V.....................................................................................................................57
Ilustração 19 – Gráfico para Demonstração de Percentual de chamados.................................60
Ilustração 20 – Gráfico para Comparação dos chamados para o Primeiro e Segundo
Qadrimestre...............................................................................................................................61
Ilustração 21 – Gráfico para Representação de Chamados Reincidentes.................................62
Ilustração 22 – Gráfico para Demonstração de redução de Custos..........................................63
 LISTA DE TABELAS

Tabela 1 – Distribuição dos Processos e Funções dentro dos estágios do Ciclo de vida do
Serviço......................................................................................................................................29
 LISTA DE SIGLAS

J2EE – Java Enterprise Edition

 INTRODUÇÃO

Dentro do contexto atual, a TI vem se consolidando cada dia mais como um

instrumento para a otimização de processos e para a automatização de processos antes
manuais, o que significa um aumento na eficácia e diminuição do tempo necessário e da
possibilidade de erros na realização de tais processos.
A emrpesa Brand Cosméticos já possuia um sistema, desenvolvido na linguagem
Poewrbuilder, que se tornou obsoleto no decorrer dos anos devido à alguns motivos que serão
enumerados e explicados com mais detalhes no decorrer deste trabalho.
A empresa optou pelo desenvolvimento de um novo sistema, levando como base a
maioria dos princípios de negócio existentes no sistema antigo, porém agora em uma nova
plataforma: a plataforma web.
O tema deste trabalho foi escolhido por demonstrar que mesmo empresas que já
tenham seus próprios sistemas, ainda assim, podem ter a necessidade do desenvolvimento de
novas versões destes; foi escolhido também por ser um caso de sucesso no qual estive inserido
como agente ativo na mudança, podendo vivenciar assim, todos os valores agregados pela
entrega do novo sistema.
O trabalho estará organizado da seguinte forma:
O primeiro capítulo será uma apresentação da empresa na qual este projeto foi
desenvolvido.
O segundo capítulo, teremos a fundamentação teórica deste trabalho, mostrando uma
breve explicação sobre as plataformas J2SE e J2EE, nas quais foi baseado o desenvolvimento
do SPECTRA Redesign.
No capítulo seguinte, mostraremos a situação inicial da empresa Brand Cosméticos e
de seu primeiro sistema, o SPECTRA Plus. Mostraremos também o ciclo de vida do projeto
 16

de desenvolvimento do SPECTRA Redesign, bem como a maneira que foram executadas

todas as fases dele.
Os resultados obtidos pela implantação do novo sistema serão apresentados no quarto
capítulo.
1 EMPRESA

Esse capítulo apresenta a empresa HP, seu foco, sua trajetória durante décadas. Além
de apresentar o organograma da empresa para o projeto e mapa físico para o projeto FictPrev.
O mapa físico apresenta o site de araraquara onde a maior parte da equipe se
localizava.

1.1 Introdução

A HP é uma empresa de tecnologia que opera em mais de 170 países em todo o mundo
em vários ramos do mercado de TI.
Poucas empresas oferecem um portifólio de produtos de tecnologia tão completo como
a HP. Oferecendo infra-estrutura para negócios que abrangem desde dispositivos palm-top a
algumas das instalações com os super-computadores mais poderosos do mundo. Oferece
também uma variada gama de produtos e serviços aos clientes, de fotografia a entretenimento
digitais, da computação à impressão residencial.
Este variado portifólio ajuda a empresa a associar os produtos, serviços e soluções
corretos às necessidades específicas de cada cliente.
 18

Ilustração 1 – Logo da Empresa HP

Fonte: Intranet HP

Hewlett-Packard Company
Rod. Manoel de Abreu, KM 4,5 - Distrito Industrial III
Araraquara, SP 14805-500
BRASIL.

1.2 Histórico Cronológico

 Fundada em 1939 por Bill Hewlett e David Packard, dois estudantes da

Stanford University. Bill continuou os estudos em Stanford e no MIT, enquanto
Dave começou a trabalhar na GE. Morando em Palo Alto – Califórnia, fizeram
um investimento inicial de 538 dólares para montar numa garagem seu
primeiro produto que foi um oscilador de áudio, um instrumento muito usado
por engenheiros de som para fazer testes. Um de seus primeiros clientes foi a
Walt Disney Studios que adquiriu 8 destes osciladores para desenvolver e testar
o som para o filme de animação "Fantasia", de 1940.
 Em 1940, a medida que a HP cresce, Dave e Bill criam um estilo de gerência
agressiva que forma a base de sua cultura de empresa aberta, como a Política
de Portas Abertas, escritórios sem portas e a gerência por objetivos que
possibilita seus funcionários trabalhar visando metas e determinando a melhor
maneira dentro de suas próprias áreas de responsabilidade.
 19

 Em 1942 iniciam a construção do seu primeiro prédio próprio em Palo Alto.

Planejaram o prédio de forma que pudesse se transformar numa mercearia caso
não desse certo.
 Na época da segunda guerra mundial eram especialistas em geradores de sinal
e incorporaram muitas de suas idéias e produtos a indústria naval americana.
 A partir da década de 50 seus contadores de frequência e produtos relacionados
faturaram bilhões de dólares.
 Em 1958 adquire sua primeira empresa, F.L. Moseley de Pasadena,
California, produtor de plotters, entrando assim no mercado de impressão.
 Em 1959 se estabelece na Europa com um departamento de vendas na
Suíça e uma fábrica da Alemanha.
 Em 1963 faz uma joint-venture (empreendimento conjunto) com a
empresa japonesa Yokogawa Electric, entrando no mercado asiático.
 Em 1966 lança seu primeiro computador, HP 2116A. Tinha 4 Kb de
memória de núcleo magnéticos, expansível a 32 Kb. O primeiro exemplar foi
instalado a bordo de uma embarcação de pesquisa, num ambiente de ar salgado
por mais de 10 anos.
 Em 1968 lança a primeira calculadora de mesa, HP 9100A, que permitia
armazenar programas em cartões magnéticos e efetuar complexos cálculos
científicos.
 Em 1972 fazem a primeira calculadora de mão, pequena ao ponto de
caber num bolso de camisa e o primeiro computador de uso geral, introduzindo
a era de processamento de dados distribuído, uma vez que serve tanto à
engenharia de alta tecnologia como as operações quotidianas de processamento
de dados administrativos.
 Em 1974 substitui a memória de núcleo magnético pela memória
dinâmica de acesso aleatório nos mini computadores.
 Em 1975 cria uma interface padrão (HP-IB ou interface bus) para
sistemas de instrumentos, que é reconhecida como um padrão internacional,
permitindo conectar um ou mais instrumentos de forma fácil a um computador.
 Em 1980 lança seu primeiro computador pessoal, o HP-85 e a primeira
impressora a laser.
 Em 1982 introduz a tecnologia do superchip de 32-bit com o HP 9000.
Neste ano também é lançado o primeiro handheld HP-75C (primeiro
computador de mesa), com 16K RAM e 48K ROM.
 20

 Em 1984 lança a impressora ThinkJet de 96 dpi, com tecnologia térmica

de jato de tinta para pcs de mesa e portáteis que estava em desenvolvimento
desde 1978. Neste mesmo ano lança também uma impressora laser de 300 dpi.
 Em 1986 inicia a aplicação comercial para a arquitetura RISC. A
Compaq começa a utilizar os processadores Intel 80386 em seus pcs.
 Em 1988 lança a HP DeskJet.
 Em 1991 lança seu primeiro palmtop, HP 95LX, a junção de uma
potente calculadora financeira com processamento de um pc, agenda
eletrônica, planilha Lotus 1-2-3, processador de textos e que permite
transferência de dados por raios infravermelho. A DeskJet 500C que permite
impressão colorida também é lançada neste ano.
 Em 1993 nasce a família Presário e é lançado o HP Omnibook 300, um
portátil com bateria capaz de durar um vôo através dos Estados Unidos.
 Em 1994 inicia em conjunto com a Intel o desenvolvimento de um
processador de 64 bits, hoje chamado de Itanium, lançado em 2001.
 Em 1996 morre Dave Packard.
 Em 1997 recebe um prêmio Emmy pela contribuição na tecnologia de
compactação MPEG para videos.
 Em 1998 lança um palmtop com interface gráfica rodando Windows
CE.
 Em 1999 a HP compra a parte pertencente à Yokogawa Electric da
Hewlett-Packard Japan.
 Em 2000 lança o servidor especializado para internet Superdome.
 Em 2001 morre Bill Hewlett.
 Em 2002 ocorre a fusão entre HP e a Compaq Computer Corporation
formando a HPQ. Formada por 3 executivos da Texas Instruments após um
encontro em uma doceria em 1982 em Houston, Texas, a Compaq se juntou à
HP, agregando uma equipe especializada em soluções computacionais; A
corporação formada por esta união foi avaliada em 87 bilhões de dólares.
 Em 2003 lança o HP DVD Movie Writer dc3000, que transforma VHS
em DVD.
 Em 2008 a HP Compra a EDS(Electronic Data Systems)
 Em 2009 (11 de Novembro) a 3Com e a Hewlett-Packard anunciaram
que a Hewlett-Packard iria adquirir a 3Com por $2.7 biliões.
 Em 2010 (a 28 de Abril), a Palm, Inc. e a Hewlett-Packard anunciaram
que a HP iria adquirir a Palm por 1.2 biliões, um negócio oficialmente fechado
a 1 de Julho de 2010.A 6 de Agosto de 2010, o CEO Mark Hurd demite-se,
 21

cargo temporariamente assumido por Cathie Lesjak. A 30 de Setembro de

2010, Léo Apotheker foi nomeado o novo CEO e Presidente da HP.

1.3 Organograma

Segue organograma da empresa HP desde o presidente até as lideranças internas do

projeto FictPrev.

Ilustração 2 – Organograma do Projeto FictPrev da Empresa HP

Fonte: Documentação Interna (2011)
 22

1.4 Layout

Mapa do site da empresa HP em araraquara. Cada cor no mapa representa a disposição

das baias para um projeto. O projeto FictPrev se encontra destacado em verde escuro com a
legenda FICTPREV em vermelho.

Ilustração 3 – Mapa Físico do Site de Araraquara da HP

Fonte: Documentação Interna (2011)
 2 FUNDAMENTAÇÃO TEÓRICA

Esse capítulo apresenta uma fundamentação teórica simples sobre ITIL, pois, o
framework da empresa HP é alinhado com as boas práticas de ITIL V3 e esse framework foi
usado para a implantação do fluxo de atendimento de solicitações de serviços de TI no projeto
FictPrev.

2.1 Introdução ao Cenário ITIL

Por muito tempo as organizações conseguiam dar continuidade a seus negócios mesmo
tendo pouco apoio da TI (Tecnologia da Informação). Hoje, porém, a realidade é outra : a TI é
um fator importantissimo para o sucesso das organizações, sendo, em alguns casos, um
diferencial critico na competitivade.
Atualmente as organizações veem a TI como um parceiro estratégico, ela faz parte do
negócio (está integrada a ele, ou deveria estar). Os investimentos em relação a TI são tratadas
nas reuniões de planejamento estratégico junto com a alta cúpula administrativa das empresas.
O cenário atual do mercado torna impossivel tratar a TI isoladamente, ela está deixando de ser
tratada apenas por técnicos e está sendo incorporada na estratégia da empresa para alcançar
suas metas de negócios.
Ainda existem algumas empresas, obviamente, em que a TI não é tratada com esse
mesmo nível de integração, nesses casos a TI ainda é tratada como um componente
tecnológico, nesses casos a TI é apenas informada sobre as decisões que foram tomadas,
 24

nesses contexto ela se torna muito reativa a mudanças e muitas vezes não consegue atender
prontamente a todas elas.
Já em empresas onde a TI é tratada como parceira nos negócios é possivel antecipar as
mudanças e fazer um planejamento adequado para atendê-las. A ITIL V3 é uma biblioteca que
vai ajudar a TI a se integrar com o negócio.
Com o aumento da importância dentro das organizações, a TI passou a ter vários
desafios.
Segue alguns deles :
- Para se manter no mercado competitivo as empresas precisam inovar. Para qualquer
inovação que as organizações venham a oferecer, disponibilizando novos serviços ou
produtos, dependerá da TI de alguma forma. Temos aqui o desafio da agilidade para
adaptação as mudanças no negócio.
- Para que a TI possa justificar o ROI (retorno sobre o investimento) é necessário que a
área de negócios e a TI falem a mesma lingua.
A TI custou muito dinheiro para as organizações nos utlimos anos, por isso é
necessário justificar esse orçamento e comprovar como cada investimento vai render retornos
para o negócio.
- Com a competividade acirrada do mercado as organizações se veem obrigadas a
diminuir seus gastos internos, com isso todas as áreas das organizações são afetadas, por isso
é necessário que a TI consiga maior eficiencia e eficacia nas suas operações. Em resumo
temos o desafio de otimizar os recursos e custos das operações de TI.
- A TI se tornou um risco para o operacional da organização, pois qualquer
indisponibilidade no serviço de TI impacta diretamente o negócio Por isso, é necessário que
ela seja flexivel o suficiente para atender a novas demandas e ao mesmo tempo criar um
ambiente estável. Temos aqui um grande desafio: aumentar a disponibilidade do serviço sem
perder a agilidade.
- A segurança da informação é algo de grande importancia para as organizações, pois
elas são possuem muitas ifnormações guardadas em banco de dados, sistemas e servidores. As
empresas são afetadas diretamente por leis como “Sarbanes Oxley” e normas do Bando
Central. Por isso, a TI tem o desafio de oferecer segurança e conformidade com todas as leis
e normas que impactam o negócio além de oferecer o menor risco possível.
 25

2.2 Evolução da ITIL

A figura a seguir apresenta a evolução da ITIL desde sua criação até a ultima
atualização para disponibilização da ITIL V3.

Ilustração 4 – Evolução da ITIL

Fonte: www.tiexames.com.br (2011)

2.3 Introdução a ITIL V3

ITIL é um acrônimo de Information Technology Infrastucture Library.

Desenvolvida primeiramente pela Central Computing and Telecommunications
Agency (CCTA) se encontra hoje sob o domínio do Office of Government Commerce (OGC).
OGC é um orgão do governo Britânico que cria padrões e desenvolve metodologias
dentro dos departamentos do governo com o objetivo de otmizar e melhorar os processos
internos.
 26

A ITIL é constituida por uma descrição de práticas coerente e integrada para o

gerenciamento de serviços de TI, que auxiliam a implantar e manter um gerenciamento de
serviços de TI focando em pessoas, processos e recursos que são usados na entrega de
serviços que atendam as necessidasdes dos clientes.
A ITIL é :
- Um modelo não proprietário
- Não é prescritivo
- Fornece boas práticas e as melhores práticas
- É usada por milhares de empresas no mundo todo
- Ajuda a atingir os requisitos da ISO/IEC 20000

2.4 Estrutura da ITIL V3

A ITIL é composta por uma série de livros que estão disponível para compra nas
grandes livrarias. É de domínio público a utilização dessas práticas nas empresas, porém todo
o material da ITIL possui direitos de cópia para a coroa inglesa.
A ITIL define objetivos e atividades e as entradas e saídas de cada processo
encontrado em uma organização de TI. Mas, a ITIL não dá uma descrição específica de como
essas práticas devem ser executadas, pois em cada organização elas devem ser adaptadas. O
enfase está nas sugestões que foram compravadas na práticas mas que em determinadas
situações podem ser implantadas de forma diferente. Ela não é um método mas sim um
framework (estrutura) para desenhar os processos mais comuns de TI, papéis e atividades
indicando a ligação entre eles e que linha de comunicação é necessária. É baseada na
necessidade de fornecer serviços de alta qualidade, com enfase no serviço e seu ciclo de vida.
Parte da filosofica da ITIL é baseada nos sistemas de qualidade como por exemplo a
sério ISO 9000 Qualidade total. A ITIL suporta esses sistemas com uma descrição clara dos
processos e boas práticas em Gerenciamento de Serviços de TI.
A ITIL V1 possuia aproximadamente 40 livros abordando vários assuntos relacionados
ao Gerenciamento de Infraestrutura, focados principalmente no gerenciamento de Serviços de
TI. A ITIL V2 possuia 7 livros principais.
A nova biblioteca da ITIL V3 é composta por:
 27

Conteúdo principal : 5 livros principais que representam os estágios do ciclo de vida

do serviço, essa é a grande sacada da ITIL V3.
- Estratégia do Serviço
- Desenho do Serviço
- Transição do Serviço
- Operação do Serviço
- Melhoria Continuada do Serviço
Conteúdo complementar: guia introdutório, guias de bolsos, guias complementares
com aplicação da ITIL em cenários específicos, estudos de caso, material para treinamento,
artigos e serviços de suporte via web.
Para um melhor entendimento do ciclo de vida do serviço, é importante ter o
conhecimento sobre o que é um:
- Serviço
Um Serviço é um meio de se entregar valor aos clientes, facilitando os resultados que
os clientes querem alcançar sem assumir custos e riscos.
“A service is a means of delivering value to customers by facilitating outcomes
customers want to achieve without the ownership of specific costs and risks.” (ITSMF, 2007)
- Processo
Um processo pode ser descrito como um conjunto de atividades coordenadas
combinando e implantando recursos e habilidades com o objetivo de produzir uma saida. Essa
saida criará valor direta ou indiretamente a um cliente. Um processo pode ser composto por
vários elementos. Em resumo, todo processo tem uma entrada (objetivo) e atividades que vão
utilizar essa entrada para produzir uma saida (resultado).
Para Magalhães, Ivan Luizio (2007, p. 43 ) “Um processo é formado por diversas
atividades que interagem para o alcance do objetivo especificado e a geração do resultado
desejado.”
- Função
Função é um time ou grupo de pessoas especializadas e os recursos necessários para
realizar um ou mais processos ou atividades. Uma função pode ser quebrada em vários
departamentos ou grupos, porém, também podemos encontrar uma pessoa ou grupo
desempenhando várias funções.Cada função tem seu próprio corpo de conhecimento, isto é, é
especialista em determinado assunto, e foca em otimizar seu trabalho e gerar resultados
específicos. (ITSMF, 2007)
 28

2.5 Ciclo de Vida do Serviço

A abordagem do ciclo de vida do serviço é algo novo para a TI, mas não para outras
áreas. Precisamos entender que um serviço nasce, se desenvolve, vai para a operação e um dia
ele morre ou é aposentado.
O ciclo de vida do serviço é um modelo que passa uma visão geral dos estágios pelos
quais os serviços passam desde sua concepção até seu encerramento.
Para que um serviço gere valor para o negócio é necessário que ele seja gerenciado
desde o inicio (seu primeiro estágio).
O ciclo de vida do serviço tem um eixo central que é a Estratégia do Serviço. A
Estratégia do Serviço também é o estágio inicial do ciclo de vida.
Esse estágio inicial, vai guiar todos os outros estágios:
- Desenho do Serviço
- Transição do Serviço
- Operação do Serviço
Ao redor de todos os estágios do ciclo de vida, vem a melhoria continuada.

Ilustração 5 – Ciclo de Vida do Serviço

Fonte: http://www.ogc.gov.uk/guidance_itil_4671.asp
 29

Os Processos e Funções estão distribuídos ao longo dos estágios desse ciclo de vida,
como apresentado a seguir, porém, não serão detalhados nessa fundamentação teória.

Tabela 1 – Distribuição dos Processos e Funções dentro dos estágios do Ciclo de vida do
Serviço

Fonte: Autora
 30

2.6 Estagios do Ciclo de Vida do Serviço

Para a ITIL os estágios pelos quais o serviço passa durante o seu ciclo de vida pode ser
descrito conforme segue.

2.6.1 Estratégia do Serviço

É nesse estágio que a TI vai se integrar com o negócio. Essa é o grande diferencial da
ITIL V3. As organizações estão acostumadas a ver a TI apenas como um departamento de
tecnologia que é avisado sobre as decisões tomadas pela empresa.
Quando a TI é vista dessa forma no momento em que o comunicado é feito, a TI
precisa dar um jeito de atender a demanda, é nesse momento que começam os conflitos
relacionados a falta de recursos e falta de tempo para a solução.
Nesse estágio da ITIL V3 a TI tem que buscar entender quais são as demandas dos
clientes, e identificar e apresentar riscos e oportunidades dentro dessas demandas, pensar no
retorno sobre o investimento (ROI) para o negócio, decidir por terceirizar ou não certo
serviço. A TI vai gerenciar seu portifólio de serviços e este vai conter o funil de serviços
(dentro desse funil estarão os serviços considerados e os em desenvolvimento).
A TI normalmente possui mais demanda que sua capacidade de atendimento, porém,
nessa etapa ela vai fazer a priorização dessa demanda. Nem toda demanda vira de fato um
serviço é por isso que a TI precisa fazer a gestão estratégica do seu portifólio de serviços.
Aplicando-se as praticas da Estratégia de Serviços da ITIL V3 é possivel que a TI
tenha a visão da razão de se ter um serviço dentro do seu portfólio.
Todos os dados que são considerados na Estratégia do Serviço são usados como base
para os estágios futuros do ciclo de vida do serviço de TI.

2.6.2 Desenho do Serviço

Os dados que foram utilizados na Estratégia do Serviço serão utilizados para o

Desenho do Serviço, esse desenho deve conter: orçamento, mercado alvo e como o serviço
será utilizado pela organização. O serviço será projetado de acordo com a estratégia já
definida, levando-se em conta o valor que esse serviço vai gerar para o cliente.
Se todas as informações tiverem sido coletadas durante o estágio de Estrattégia do
Serviço, a TI terá condições de projetar o serviço de acordo com o que foi planejado.
 31

O Desenho do Serviço vai transformar os objetivos estratégicos em serviços do

portifólio de TI.
Nesse estágio já deve ser levado em consideração dados como qual será o Acordo de
Nível de Serviço (ANS), quais os riscos envolvidos para o atendimento da demanda, quais os
fornecedores necessários e qual a infraestrutura necessária para suportar o serviço que está
sendo desenhado.
Nesse estágio além do desenho e desenvolvimento do serviço de TI, serão criados os
processos de gerenciamento de serviços de TI, esses processos irão transferir e manter
funcional esse serviço que está sendo criado.

2.6.3 Transição do Serviço

Nesse estágio o foco é a migração do serviço para a operação. É nesse estágio do ciclo
que é transferido tudo o que foi criado ou melhorado para o ambiente de produção.
Esse estágio necessita de uma atenção muito grande com os detalhes para que o
Serviço seja colocado em produção com o menor impacto possivel para a organização.

2.6.4 Operação do Serviço

Esse estágio se preocupa em manter funcional o serviço atual (que está em produção
nesse momento). Nesse estágio os processos e função vão lidar com as atividades do dia-a-
dia, como o gerenciamento de incidentes e de problemas e o cumprimento de requisições. E as
funções

2.6.5 Melhoria continuada do Serviço

Ao redor de todos os estágios do ciclo de vida do serviço se enconta a melhoria

continuada do serviço, esse estágio foca na qualidade. Avaliando tanto os serviços como os
processos que fazem parte dos estágios do ciclo de vida do serviço.
A idéia aqui é que o serviço que foi entregues não é estático. Ele pode ser ótimo hoje,
porém amanhã pode não ser mais, pois a demanda do cliente está sempre aumentando. Sendo
assim , essa abordagem de melhoria contínua é utilizada para avaliar se o serviço continua
atendendo as necessidades do negócio, avaliando o feedback recebido.
 32

Nada impede, e é até a intenção desse estágio, que o ciclo de vida gire várias e várias
vezes, reavaliando a estratégia do serviço, para que haja um realinhamento com as
necessidades do negócio.
Avaliando todos os ciclos de vida é fácil perceber que se a TI passar por todos os
estágios sempre que for criar ou alterar um serviço, ela estará menos suscetível a erros. Pois
os serviços serão desenhados conforme os requisitos dos clientes e projetados corretamente,
gerando assim, menos trabalho para o pessoal de produção mante-lo.
Em resumo, todos terão menos retrabalho.
 33

3 PROJETO FICTPREV

Esse capítulo apresenta um caso de sucesso no seguimento de Aplicações da empresa

HP, onde houve a implantação de um Fluxo de atendimento de serviços de TI no projeto
FictPrev.

3.1 Situação Inicial

A FictPrev é uma empresa do ramo de Previdência Privada que suporta todo o

operacional desse seguimento para diversas empresas brasileiras de previdência privada. O
projeto FictPrev suportava todos os recursos de software necessários para que o cliente
FictPrev tivesse condições de prestar esse serviço aos seus clientes.

O projeto FictPrev era tratado como um cliente interno da HP, e por esse motivo não
possuía Gerente de Projeto para gerenciar as atividades da equipe de aplicações, devido a ser
uma conta de atuação muito antiga, o único instrumento usado para documentação das
necessidades dos usuários e atuação dos analistas era o Outlook. Sempre que havia uma
atividade a ser desenvolvida o Gerente da FictPrev enviava um e-mail ao grupo do Outlook
que continha os membros da equipe do projeto FictPrev descrevendo a necessidade. Os
próprios membros da equipe se organizavam para atender a demanda e assim que concluíam
retornavam o e-mail para indicar que estava concluída.
Algumas das deficiências neste cenário inicial são:
 Falta de documentação pré e pós-atendimento;
 Falta de distribuição de responsabilidades;
 Falta de compartilhamento do conhecimento da regra de negócio e técnico;
 Falta de métricas;
 34

3.2 A identificação da necessidade de uma modelagem de fluxo de atendimento

O modo como era realizado o atendimento apresentado no primeiro capítulo era muito
falho, pois muitas atividades ficavam sem atendimento e muitas atividades que já haviam sido
executadas eram repetidas.
Além da falta de documentação pré- atendimento o projeto ainda possuía um déficit
gigantesco em relação à documentação pós-atendimento, quase nada ou de fato nada existia
em relação à documentação dos sistemas tanto de forma técnica quanto em relação a regras de
negócio.
Isso dificultava de forma extrema a transferência de conhecimento da equipe de
atendimento quando ocorria alteração de recursos na equipe. Todo o conhecimento em
relação aos sistemas do cliente estava guardado na cabeça de alguns recursos chave do projeto
e a saída de algum desses recursos acarretaria uma situação de extremo perigo para a
manutenção de atendimento, além disso, com o acúmulo de atividades e a falta de distribuição
de responsabilidades existentes, essas peças chaves nunca podiam repassar o conhecimento, já
que sempre estavam sobrecarregados de atividades.
Esse excesso de carga de atividade e concentração de conhecimento acarretaram vários
problemas de ordem organizacional, como acúmulo de férias, por exemplo, já que a equipe
não possuía autonomia para trabalhar sem esses recursos chaves.
Toda essa situação foi responsável pelo excesso de horas extras dos analistas e
descontentamento tanto dos usuários quanto do cliente como um todo, já que não era possível
nenhuma melhoria, somente a sustentação dos sistemas já existentes.
Nenhuma métrica era retirada, já que o projeto não apresentava registros coerentes
sobre os atendimentos e dessa forma, não havia como justificar tantas horas extras que eram
realizadas.
Além das deficiências apresentadas no primeiro capítulo, outras deficiências foram
detectadas:
 Acúmulo de horas extras;
 Sistemas estagnados por falta de melhorias;
 Usuários descontentes com analistas;
 Analistas descontentes com usuários;
 35

Por esses motivos, o projeto FictPrev começou a ser mau visto diante do cliente e da
própria HP. Portanto, era necessário de alguma maneira corrigir a forma de atendimento para
que fosse possível a retirada de métricas e documentações coerentes das atividades realizadas,
assim como as atualizações de férias e outras questões organizacionais.

3.3 O processo de desenvolvimento do modelo de fluxo de atendimento

Com o cenário apresentado, foi identificada a necessidade de alocação de um Gerente

de Projetos com o suporte de um Analista de Qualidade para o projeto FictPrev, para que a
necessidade do cliente fosse estudada. Com o apoio de alguns analistas chaves que já atuavam
neste projeto e com o conhecimento de alguns usuários chaves dos sistemas, uma estratégia de
melhorias no atendimento dos serviços foi traçada por eles.

Inicialmente, foram levantados quais os serviços deveriam ser prestados para os

determinados sistemas, foram definidas as responsabilidades para ambas as partes e tudo isso
foi documentado num Acordo de Nível de Serviço, para que em paralelo a este documento,
pudessem surgir um Fluxo de Atendimento de chamados e consequentemente, um sistema de
chamados para atender esse Fluxo definido.

3.4 Definindo quais serviços deveriam ser prestados

Estudando a necessidade do cliente, chegou se a conclusão de que os seguintes

serviços deveriam ser prestados para os seguintes sistemas:
Manutenção dos seguintes softwares:
 Private
 Módulo Cliente do Private
 Módulo REA (Relatórios Extra Amadeus)
 Módulo Autopatrocinados do Private
 36

 Portal de conteúdo (Vignette)

 E-Solutions
 Portal E-Solutions Simuladores
 IN26 (Manutenção de dados cadastrais, alteração de percentual e reset de senha
do Vignette)
 Empréstimos (Access)

3.4.1 Manutenção Corretiva

Desenvolver, testar e implementar soluções temporárias inclusive seguindo o processo

de controle de mudanças do cliente FictPrev, quando existir.
Efetuar o registro de todos os incidentes
Premissas:
A equipe do cliente FictPrev deverá registrar os incidentes num Sistema de Chamados a
ser desenvolvido.
Estes incidentes deverão ser priorizados pelo cliente FICTPREV, o qual indicará ao
projeto FictPrev, a ordem de execução em que os incidentes devem ser atendidos.
Para documentar a correção destes incidentes serão abertos pelo projeto FictPrev os
documentos de “5 Passos – Reporte de Incidente”, onde serão registrados: incidentes,
possíveis causas e solução temporária e solução definitiva, quando for possível determiná-la
imediatamente.

3.4.2 Análise de Causa Raiz

Investigação da causa do incidente, análise da causa raiz e correção dos mesmos

Trata dos incidentes que forem classificados como severidade 1, 3 e 4, que estão
descritas no capítulo 3.4 deste relatório
Trata dos incidentes cuja causa raíz não foi identificada imediatamente durante o
atendimento de Manutenção Corretiva.
 37

A equipe do projeto FictPrev receberá o documento de “5 Passos – Reporte de

Incidentes” e determinará sua causa raiz através de análise de sistemas, para encaminhar as
soluções definitivas
Premissas:
O time do projeto FictPrev poderá registrar a necessidade de análise de causa raíz num
Sistema de Chamados a ser desenvolvido a partir do resultado do atendimento de um
chamado de Manutenção Corretiva
A equipe do cliente FICTPREV deverá registrar a necessidade de análise de causa raíz
no Sistema de Chamados
Estes atendimentos deverão ser priorizados pelo cliente FICTPREV, o qual indicará ao
projeto FictPrev, a ordem de execução em que devem ser feitos.
A identificação da causa raíz dos incidentes está sujeita a compartilhamento de recursos
que atenderão a linha de manutenção corretiva/suporte.

3.4.3 Melhoria

Entende-se por Melhorias, as manutenções evolutivas nos sistemas implantados para o

cliente FICTPREV que exigem esforço limitado a 160 horas.
Para esta modalidade será feito desenvolvimento e/ou implementação de novos
processos ou sistemas.
Estas solicitações deverão ser colocadas em uma lista de pendências, utilizando-se o
Sistema de Chamados a ser desenvolvido (Tipo de Atendimento = Backlog) e deverão ser
priorizadas pelo cliente FICTPREV, o qual indicará ao projeto FictPrev a ordem de execução
de cada uma.
O projeto FictPrev registrará um chamado de Estimativas no Sistema de Chamados e
conduzirá inicialmente o levantamento de requisitos, análise, elaboração de proposta técnica e
estimativas e apresentará ao cliente FICTPREV
O cliente FICTPREV deverá aprovar ou rejeitar a proposta
Premissas:
A equipe do cliente FICTPREV deverá registrar os incidentes no Sistema de
Chamados
 38

Estes atendimentos deverão ser priorizados pelo cliente FICTPREV, o qual indicará ao
projeto FictPrev, a ordem de execução em que os incidentes devem ser atendidos.
Caso o resultado da análise identifique esforço maior que 160 horas, o tipo de serviço
será reclassificado como Novas Solicitações conforme descrito no item 3.1.4 desse Relatório.

3.4.4 Novas Solicitações (Acima de 350 h abordagem de projeto)

Entende-se por Novas Solicitações, as manutenções evolutivas nos sistemas

implantados para o cliente FICTPREV que exigem esforço acima de 160 horas
Para esta modalidade será feito desenvolvimento e/ou implementação de novos
processos ou sistemas
Estas solicitações deverão ser colocadas em uma lista de pendências, utilizando-se o
Sistema de Chamados a ser desenvolvido (Tipo de Atendimento = Backlog) e deverão ser
priorizadas pelo cliente FICTPREV, o qual indicará ao projeto FictPrev a ordem de execução
de cada uma.
O atendimento a esta frente pode demandar a alocação de recursos adicionais,
contratados por tempo determinado ou por empreita.
O projeto FictPrev registrará um chamado de Estimativas no Sistema de Chamados e
conduzirá inicialmente o levantamento de requisitos, análise, elaboração de proposta técnica e
estimativas e apresentará ao cliente FICTPREV
O cliente FICTPREV deverá aprovar ou rejeitar a proposta
Premissas:
A equipe do cliente FICTPREV deverá registrar os incidentes no Sistema de
Chamados
Estes atendimentos deverão ser priorizados pelo cliente FICTPREV, o qual indicará ao
projeto FictPrev, a ordem de execução em que os incidentes devem ser atendidos.

3.4.5 Atualização de arquivos, noticias no portal de conteúdo (Vignette). Criação de

Senhas e Reset de Senhas
 39

Este serviço se refere a manutenção dos portais de conteúdo solicitadas pelos clientes
do cliente FICTPREV
As ações de atualização de arquivos, notícias, criação de senhas e reset de senhas são
feitas conforme solicitação dos clientes do cliente FICTPREV, em geral diariamente, por um
recurso alocado.
Premissas:
Em se tratando de ação rotineira, o projeto FictPrev registrará tais atendimentos no
Sistema de Chamados a ser desenvolvido
Os atendimentos diários não estão sob a necessidade de priorização do cliente
FICTPREV por se tratar de atividade contínua e imprescindível à exposição atualizadas das
informações para os usuários do portal Vignette
A execução está dentro do acordado de horas de suporte a produção.
Quando houver necessidade emergencial, o cliente FICTPREV deverá registrar o
chamado no Sistema de Chamados
Os atendimentos eventuais, em caráter emergencial, deverão ser priorizados pelo
cliente FICTPREV, o qual indicará ao projeto FictPrev, a ordem de execução em que os
incidentes devem ser atendidos.
Fora do escopo do serviço:
O projeto FictPrev não se responsabiliza pela manutenção da infraestrutura envolvida
na atualização das bases
O projeto FictPrev não se responsabiliza pelo conteúdo dos arquivos e notícias que são
disponibilizados no portal de conteúdo Vignette

3.4.6 Suporte Disponível

O papel do projeto FictPrev é o de fornecer serviço técnico de construção, alteração,

teste unitário e integrado em softwares mantidos por este time, visando garantir a
disponibilidade dos sistemas utilizados pelo cliente FICTPREV
O papel também se estende ao projeto FictPrev no que se refere ao suporte para
upgrade das versões dos sistemas de Terceiros, quais sejam: Amadeus e Intech
 40

Também é atribuição do projeto FictPrev manter a operação do portal de conteúdo,

atualizando as informações para o cliente FICTPREV
O projeto FictPrev manterá um time alocado, que atenderá os sistemas do cliente
indicados nesse levantamento de segunda a sexta-feira das 8:00 às 12:00 e de 13:00 17:00
(hora-local São Paulo, Brasil), exceto feriados
A composição do time alocado contará no mínimo com os seguintes profissionais:
Gerente de Projeto
Analista de Qualidade
Líder Técnico
Analista de Negócios Previdência Privada/Fundos de Pensão
Analista de Negócios Benefícios
Atendimento de Chamados
Testadores

3.5 Definindo Responsabilidades em relação ao Cliente

Durante a documentação das atividades também foram definidos os papéis e

responsabilidades:

3.5.1 Do gerenciamento do Projeto FictPrev Apliações

Gerenciar os serviços e recursos alocados para o atendimento dos sistemas atendidos

pelo Acordo de Serviços;
Facilitar a priorização de chamados do cliente FICTPREV;
Controlar o backlog de manutenções e melhorias e divulgá-lo em bases semanais para
o funcionário que o cliente FICTPREV indicar;
Determinar as solicitações que estão fora do escopo do Acordo de Serviços;
Garantir a qualidade do serviço e o atendimento do nível de serviço acordado;
Mentoração da equipe do projeto FictPrev;
Revisão de estudos, propostas e soluções de incidentes;
 41

Identificar e documentar riscos e, dependendo da criticidade, informar o cliente

FICTPREV;
Revisar riscos periodicamente e mitigá-lo quando necessário;
Controlar custos e gerenciar aprovações de despesas;
Garantir entrega das solicitações, de acordo com expectativa do cliente FICTPREV;
Manter o cliente FICTPREV, atualizados quanto ao status das atividades.

3.5.2 Controle de Configuração, Métricas e Controle de Qualidade:

Coletar e registrar métricas geradas pelo projeto

Fazer o controle de configuração de todos os itens de software e documentos que estão
sob a responsabilidade do projeto FictPrev referente ao projeto.
Revisões de qualidade, visando garantia do processo exigidos pelos padrões de
mercado.

3.5.3 Equipe de Suporte à Produção:

Reportar status das atividades para Gerente do Projeto;

Criação e Desenvolvimento de Requisição de Mudanças;
Testes unitários, integrados e acompanhar o teste de aceitação funcional das
Requisições de Mudanças desenvolvidas;
Seguir processos de desenvolvimento e correção de defeitos estipulados para o projeto
Produzir as documentações de desenvolvimento e de defeitos e mantê-las atualizadas.
Seguir e executar o processo de Gerenciamento de Mudanças, quando necessário.
Manter a documentação do projeto atualizada;
Lançar horas diariamente, para possibilitar o controle de horas/atividades executadas.
Exemplos de Atendimentos:
 Correção de incidentes em funcionalidades do Private, Access e E-Solutions
 Erro no Access de Empréstimo
 42

 Suporte na execução das Folhas

 Correção de dados replicados incorretos no Portal
 Incidente na Replicação de Dados BackOffice – Portal – BackOffice
 Instalação de Novas versões dos sistemas Amadeus e Contabil
 Criação de usuarios no portal
 Permissões de acesso no portal
 Manutenção de conteúdo estático no portal
 Erro Reserva Matemática
 Erros no Modulo Cliente

Tendo em mãos exatamente quais os serviços que deveriam ser prestados e quais eram os
papéis da equipe de atendimento e do cliente FictPrev a equipe do projeto FictPrev culminou
na decisão de criar uma modelagem de fluxo de atendimento que suprisse a necessidade tanto
do cliente quanto do projeto FictPrev em mostrar seus resultados e melhorar seu
atendimento.
Para essa modelagem foi utilizado o Framework de Processos da HP que visa a maturidade
dos projetos e permitem que os mesmos possam ter o desempenho medido de acordo com
níveis e padrões de mercado. Esse framework, conforme dito no inicio do capitulo 3 deste
trabalho, está alinhado com as boas práticas para gerenciamento de serviços do ITIL V3.

3.6 Desenhando o Fluxo de Atendimento

Foi desenhado um fluxo para cada tipo de atendimento descrito no capítulo 3.1. Para
isso foi utilizada a ferramenta Microsoft Visio, conforme segue:
 43

3.6.1 Fluxo para atendimento de Manutenção Corretiva

Ilustração 6 – Fluxo de Atendimento para Manutenção Corretiva

Fonte: Documentação Interna do Projeto
 44

3.6.2 Fluxo para atendimento de Análise de Causa Raiz

Ilustração 7 – Fluxo de Atendimento para Análise de Causa Raiz

Fonte: Documentação Interna do Projeto
 45

3.6.3 Fluxo para atendimento de Melhorias e Novas Solicitações

Ilustração 8 – Fluxo de Atendimento para Melhorias e Novas Solicitações I

Fonte: Documentação Interna do Projeto
 46

Ilustração 9 – Fluxo de Atendimento para Melhorias e Novas Solicitações II

Fonte: Documentação Interna do Projeto
 47

3.7 Desenvolvimento de um Sistema de Chamados

O próximo passo foi a criação de um sistema baseado em SharePoint para a inclusão

de chamados relacionados às atividades que deveriam ser executadas, esse sistema foi
chamado de “Sistema de Chamados”, a partir dele o usuário abria um chamado e nesse
chamado inseria todas as informações necessárias para o atendimento do mesmo. O chamado
permanecia inicialmente no status “Aberto” e de acordo com o fluxo apresentado no capítulo
anterior era atualizado.
No momento da abertura do chamado o usuário já deveria definir qual a severidade do
atendimento a esse chamado que deveria estar organizada da seguinte forma:

3.7.1 Catastrófico (Severidade 1):

O defeito catastrófico envolve situações onde a perda do serviço não é recuperável,

podendo levar o cliente a perder dinheiro, reputação e negócios.
Neste caso estão incluídas situações do tipo:
A caixa registradora de um supermercado não está funcionando e desta forma o cliente
não consegue pagar suas mercadorias.

3.7.2 Maior – Sem Solução Temporária (Severidade 2):

O defeito impede ou tem o potencial de impedir que uma função importante de

negócio seja executada pelo sistema ou aplicação. Não existe nenhuma forma de contornar o
problema a não ser a interrupção parcial da função de negócio.
Neste caso estão incluídas situações do tipo:
A caixa registradora de um supermercado está calculando o total da compra, porém os
códigos dos produtos são entrados manualmente porque a leitura do código de barras não está
funcionando.

Estas situações são tão graves quanto as anteriores, porém não impacta a totalidade do
negócio e algumas funcionalidades do sistema ou aplicação continuam em execução. Porém,
 48

há grande probabilidade de que estas situações podem levar o cliente a perder dinheiro,
reputação e clientes.

3.7.3 Maior – Com Solução Temporária (Severidade 3):

O defeito impede ou tem o potencial de impedir que uma função importante de

negócio seja executada pelo sistema ou aplicação. Porém existe uma forma efetiva de
contornar o problema e um pequeno impacto será sentido pelo negócio.
Neste caso estão incluídas situações do tipo:
A caixa registradora de um supermercado está funcionando normalmente, porém só
esta aceitando pagamentos em dinheiro, cheque ou cartão de débito. Cartões de crédito não
poderão ser usados para pagamento.
A gravidade destas situações é bem menor que as anteriores, pois a probabilidade de
perda é mínima e a função do negócio será executada.

3.7.4 Menor (Severidade 4):

O defeito impede ou tem o potencial de impedir que uma pequena função do negócio
seja executada pelo sistema ou aplicação.
Neste caso estão incluídas situações do tipo:
A caixa registradora de um supermercado está funcionando normalmente, porém a
função “Calculadora” não esta funcionando. Esta função às vezes é utilizada para transferir o
total da compra diretamente para a memória permitindo os cálculos adicionais.

3.7.5 Cosmético (Severidade 5):

O defeito é mínimo e não impede que a função do negócio seja executada de forma
apropriada. Esta severidade é apropriada para erros que forneçam mais um incômodo que um
problema real ou para erros de processos/padrões do cliente ou tipo de documentação.
Neste caso estão incluídas situações do tipo:
Relatórios com cabeçalhos errados.
Telas com campos deslocados.
Campos editados de forma não apropriada.
Documentação do sistema ou aplicação não condiz com a aplicação em execução.
 49

3.7.6 Interno (Severidade 6):

O defeito não tem nenhum impacto no negócio e não é visível ao Cliente. Este tipo de
defeito não deve ser reportado ao cliente, pois são erros ocorridos internamente.
Neste caso estão incluídas situações do tipo:
Erros no uso de padrões e procedimentos de Aplicações.
Execução errada de jobs (fora de ordem, parâmetros incorretos...) que foram
reprocessados sem impacto para o ciclo batch.
Ausência de arquivos necessários para a execução do Job.

Com o chamado aberto, a equipe de atendimento foi organizada pelo Gerente de

Projeto de forma a dividir as responsabilidades no atendimento dos sistemas suportados, e um
relacionamento entre sistemas e analistas responsáveis foi estabelecido para uso do “Sistema
de Chamados”. Dessa maneira cada membro ficou com suas atividades bem definidas, e
quando um chamado era aberto o “Sistema de Chamados” já direcionava um e-mail para os
analistas responsáveis pelo sistema relacionado ao chamado, possibilitando assim que o
atendimento fosse mais rápido.Quando o analista recebia o e-mail de acordo com a
priorização das atividades que era feita junto ao Gerente de Projeto pelo Gerente de cada área
da FictPrev o atendimento era iniciado, nesse momento o chamado iria para o status “Em
andamento”, caso faltassem informações, o analista tinha a possibilidade de indicar isso no
chamado alterando o status do mesmo para “Aguardando informações”, para isso o analista
deveria indicar no campo observações quais eram as informações faltantes, dessa maneira,
mesmo que o analista ficasse por uma semana aguardando informações, o cliente não teria
como reclamar, pois seria fácil provar que a pendência era do cliente e não da equipe de
Aplicações.
Também foi disponibilizado a possibilidade da FictPrev indicar que a pendência era
relacionada a informações que eles também estavam aguardando e que por esse motivo ainda
não haviam passado, para isso foi disponibilizado o status “Aguardado informações de
terceiros” assim a FictPrev também teria como provar junto ao usuário final que a informação
faltante não dependia deles.
Quando o chamado fosse finalizado o mesmo passaria para o status “Disponível para
Aceite”, nesse momento, o usuário da FictPrev que havia aberto o chamado deveria verificar
 50

se de fato sua necessidade foi atendida e em caso positivo alterar o status do chamado para
“Fechado” ou em caso negativo alterar o status do mesmo para “Rejeitado”.
Em todos os passos de alteração de status tanto o usuário responsável pela abertura do
chamado quanto o analista responsável pelo atendimento eram informados via e-mail da
alteração.

3.8 Construindo a documentação necessária de acordo com os tipos de atendimento

suportados

Para cada tipo de atendimento foram utilizados alguns documentos disponíveis no

Framework de Processos e customizados para a necessidade do projeto FictPrev.

3.8.1 Manutenção Corretiva

Para a manutenção corretiva foi definido um “Documento de 5 Passos”. Esse

documento apresentava um template mais simples, pois deveria ser utilizado para documentar
soluções temporárias e indicar uma sugestão de solução definitiva.
O Documento de 5 passos era desenvolvido pelo analista do projeto fictprev que
estava atendendo ao chamado em questão e poderia ser utilizado novamente caso um
chamado semelhante fosse aberto antes que a solução definitiva fosse realizada, dessa forma,
o conhecimento deveria ser compartilhado entre a equipe de atendimento e o atendimento
futuro seria realizado com maior eficácia e rapidez.
Segue conteúdo de um documento de 5 passos:
 51

Ilustração 10 – Demonstração de Template de Documento de 5 passos do Projeto FictPrev

Fonte: Documentação Interna do Projeto

3.8.2 Análise de Causa Raiz

O Documento de Análise de Causa Raiz era utilizado sempre que fosse necessário
encontrar a causa de um determinado problema que estava ocorrendo.
Exemplo:
Um JOB é executado todos os dias, porém algumas vezes ocorre um erro, sempre o
mesmo erro é necessário uma análise de causa raiz para encontrar qual é o problema com o
JOB e a solução para o mesmo.
O documento devia conter todos os dados referentes ao problema encontrado , análise
e solução para o mesmo.
 52

Ilustração 11 – Demonstração de Template de Documento de Análise de Causa Raiz Projeto

FictPrev I
Fonte: Documentação Interna do Projeto
 53

Ilustração 12 – Demonstração de Template de Documento de Análise de Causa Raiz Projeto

FictPrev II
Fonte: Documentação Interna do Projeto

3.8.3 Melhoria/Novas Solicitações

Para melhorias e novas solicitações foi determinado a utilização de alguns documentos

como:

3.8.3.1 Ata de Reunião:

 54

Pois nesse documento constariam tudo o que foi acordado entre o cliente FICTPREV e
o analista do projeto fictprev que estivesse atendendo a atividade.

3.8.3.2 Documento de Estimativa:

Nesse documento ficaria indicado a quantidade em horas que o atendimento levaria de

acordo com o levantamento da necessidade. Essas métricas seriam baseadas de acordo com
algumas diretrizes estipuladas pelo framework da HP.

3.8.3.3 Documento de Implementação:

Nesse documento estariam descritos os passos e detalhes sobre a implementação.

Ilustração 13 – Demonstração de Template de Documento de Implementação Raiz Projeto

FictPrev
Fonte: Documentação Interna do Projeto

3.8.3.4 Documento de Revisão:

 55

No documento de revisão eram feitas todas as revisões em pares relacionadas aos

documentos e aos artefatos alterados/criados durante o atendimento da atividade.

3.8.3.5 Documento de Descrição das Mudanças:

O documento de Descrição das Mudanças continha tudo o que seria feito durante o
atendimento da atividade, de forma detalhada.
Esse documento precisaria receber um “De acordo” do cliente FICTPREV para que o
desenvolvimento de fato fosse iniciado.
Segue alguns dos itens contidos no documento:

Ilustração 14 – Demonstração de Template de Documento de Descrição das Mudanças Raiz

Projeto FictPrev I
Fonte: Documentação Interna do Projeto
 56

Ilustração 15 – Demonstração de Template de Documento de Descrição das Mudanças Raiz

Projeto FictPrev II
Fonte: Documentação Interna do Projeto

Ilustração 16 – Demonstração de Template de Documento de Descrição das Mudanças Raiz

Projeto FictPrev III
Fonte: Documentação Interna do Projeto
 57

Ilustração 17 – Demonstração de Template de Documento de Descrição das Mudanças Raiz

Projeto FictPrev IV
Fonte: Documentação Interna do Projeto

Ilustração 18 – Demonstração de Template de Documento de Descrição das Mudanças Raiz

Projeto FictPrev V
Fonte: Documentação Interna do Projeto

Como as melhorias e novas solicitações eram atividades com carga horárias grandes
era necessário uma boa documentação dessa atividade detalhando tudo o que seria necessário
para tanto o projeto FictPrev quanto o cliente FICTPREV estivessem resgardados em relação
a entrega que deveria ser feita.
 58

Além disso, o detalhamento do atendimento poderia disceminar o conhecimento em

relação aos sistemas entre todos os integrantes da equipe do projeto fictprev.

3.9 Apresentação e Treinamento da Equipe

Depois que o desenho do fluxo foi concluido, uma apresentação do mesmo foi
disponibilizada e apresentada pela QA do projeto a equipe toda.
Assim como um treinamento foi dado, para que a equipe soubesse como utilizar o
fluzo, também foi disponibilizada toda a documentação do fluxo para consultas através de um
repositório de arquivos.
Os templates dos documentos que passaram a ser utilizados também foram
disponibilizados e com isso a equipe iniciou o trabalho de acordo com o fluxo desenvolvido.

3.10 Os resultados obtidos com as mudanças implantadas.

Com o fluxo e tipo de atendimento bem definidos tinhamos condições de retirar

métricas e apresentá-las com eficiência demostrando assim o avanço da qualidade de
atendimento de acordo com a maturidade do fluxo e dos analistas que o utilizavam.
Desses resultados apresentados podemos destacar melhorias como:

3.10.1 Sobre o relacionamento com o cliente (FICTPREV)

Implementação de reunião para apresentação de status seminal.

Controle Geral de chamados/projetos críticos ou complexos
Análise das Métricas
Implementação de reunião para priorização de atendimento
Definição de linhas de serviços e processos de implementação
Implementação de documentação básica para análise
Implementação de um novo sistema para monitoramento de chamados
 59

3.10.2 Sobre Infraestrutura

Apresentação para alta gerência do cliente sobre a situação real e crítica da

infraestrutura e acompanhamento periódico com os pares

3.10.3 Sobre Processos

Implementação de documentação de teste básica

Implementação de repositório para gerenciamento de arquivos
Melhor distribuição do trabalho com revisão e monitoramento pelo Líder Técnico
Integração básica entre sistemas

3.10.4 Sobre a equipe projetoFictPrev

Implementação de reunião semanal para mentoração e transferência de conhecimento

Time engajado na estrutura da aplicação
Time mais confiante e colaborativo entre si
Redução de 38% do banco de horas e férias (Foram mais de 1.000 horas pendente)
Atividades estão sendo feitas somente no horário de trabalho
Todos os funcionários tiveram férias no ano de 2010 (houve caso em que o empregado
não tinha férias desde 3 anos)

3.10.5 Sobre os atendimentos

3.10.5.1 Percentual de Tipos de chamados abertos

O gráfico abaixo representa os chamados abertos pelo cliente entre janeiro e outubro
de 2010 e o percentual de chamados de melhoria, suporte a produção e backlog.
Foram fechados durante o mesmo período 3626 chamados entre as três classificações
acima citadas, o que representa uma média de 17,26 chamados por dia fechado pela equipe.
 60

Ilustração 19 – Gráfico para Demonstração de Percentual de chamados

Fonte: Documentação Interna do Projeto

3.10.5.2 Comparativo sobre Números de Chamados Abertos

Observando o gráfico abaixo notamos que houve uma diminuição de 9% no número

de chamados abertos. Isso indica que não houveram tantos chamados reincidentes e que
alguns problemas conhecidos foram solucionados definitivamente.
Essas são representadas na fatia de melhorias do gráfico representado pela Ilustração
19.
 61

Ilustração 20 – Gráfico para Comparação dos chamados para o Primeiro e Segundo

Qadrimestre
Fonte: Documentação Interna do Projeto

3.10.5.3 Demonstração de Reincidencia de Chamados

O gráfico a seguir representa o número de chamados reincidentes, isso quer dizer que se
repetem. Analisando o gráfico notamos um aumento significativo nos chamados reincidentes
entre os meses de Abril e Julho, estabilizando novamente em Agosto e Setembro e
culminando em uma redução significativa em outubro.

Essa redução deve-se as melhorias que foram implementadas no sistema.

A intenção é que o número de chamados reincidentes seja igual a zero.

 62

Ilustração 21 – Gráfico para Representação de Chamados Reincidentes

Fonte: Documentação Interna do Projeto

3.10.6 Sobre Custos

O gráfico abaixo representa os custos do projeto durante agosto de 2009 a outubro de

2010. Analisando o gráfico vemos uma diminuição crescente do custo do projeto entre agosto
de 2009 a janeiro de 2010, uma estabilidade entre janeiro de 2010 e fevereiro de 2010, um
pequeno diminuição de custos no mês de março de 2010 e um custo crescente entre abril de
2010 e outubro de 2010. É importante salientar que esse aumento de custos nos ultimos meses
está diretamente ligado com o aumento de desenvolvedores alocados no projeto com a função
de atender a demandas de melhoria dos sistemas que estavam a muito tempo esquecidas.
Não é possível estimar desde quando essas melhorias estavam esquecidas pois
conforme dito no inicio do trabalho não havia possibilidade de retirada de métricas, assim
como não havia nenhum repositório confiável para registro das atividades solicitadas.
Essa fatia de melhoria é representada na Ilustração 19.
 63

Ilustração 22 – Gráfico para Demonstração de redução de Custos

Fonte: Documentação Interna do Projeto
 64

conclusão
 REFERÊNCIAS

MAGALHÃES, IVAN LUIZIO. Gerenciamento de Serviços de TI na Prática, Uma

abordagem com base na ITIL. São Paulo: Novatec, 2007.

GASPAR, MARCELO; GOMES, THIERRY; MIRANDA, ZAILTON . TI Mudar e inovar -

resolvendo conflitos com ITIL v3 aplicado a um estudo de caso.Brasilia: Editora Senac,
2010.

FREITAS, MARCOS ANDRÉ DOS SANTOS. Fundamentos do Gerenciamento de

Serviços de TI: Preparatório para a Certificação ITIL® V3 Foundation. Editora
Brasport, 2010.

itSMF Ltd. An Introductory Overview of ITIL® V3. itSMF Ltd, 2007

CAIADO, BRUNO. Projetos ITIL: O que estamos realmente implementando?. Dezembro

2010 Disponível em: <http://www.itilnapratica.com.br/projetos-itil-o-que-estamos-realmente-
implementando />.
Acesso em: 02/09/2011.

CAIADO, BRUNO, Serviços: a ponte perdida entre negócios e TI. Agosto 2009
Disponível em:
< http://www.itilnapratica.com.br/servicos-a-ponte-perdida-entre-negocios-e-ti />.
Acesso em: 04/09/2011.

CAIADO, BRUNO, Como entender o modelo do ITIL® V3!. Julho 2011 Disponível em: <
http://www.itilnapratica.com.br/como-entender-o-modelo-do-itil-v3 />. Acesso em:
02/09/2011.

TIEXAMES. Treinamento ITIL V3 Fundations. Disponível em:

< http://www.tiexames.com.br /> Acesso em: 01/08/2011.

OGC. Ciclo de Vida do Serviço. Disponível em:

<http://www.ogc.gov.uk/guidance_itil_4671.asp /> Acesso em: 19/09/2011.