UNIJUI - UNIVERSIDADE REGIONAL DO NOROESTE DO ...

UNIJUI - UNIVERSIDADE REGIONAL DO NOROESTE DO ESTADO DO RIO 

GRANDE DO SUL 

DCEEng – DEPARTAMENTO DE CIÊNCIAS EXATAS E ENGENHARIAS 

CENTRAL DE ATENDIMENTO E SISTEMA DE CHAMADOS 

BASEADO NO FRAMEWORK ITIL 

RICARDO PLETSCH KUNTZ 

Ijuí 

Dezembro/201

UNIJUI - UNIVERSIDADE REGIONAL DO NOROESTE DO ESTADO DO RIO 

GRANDE DO SUL 

DCEEng – DEPARTAMENTO DE CIÊNCIAS EXATAS E ENGENHARIAS 




Trabalho de Conclusão de Curso 

apresentado ao Curso de Informática - Sistemas de 

Informação do Departamento de Ciências Exatas e 

Engenharias (DCEEng), da Universidade Regional 

do Noroeste do Estado do Rio Grande do Sul 

(UNIJUÍ), como requisito para a obtenção do título 

Bacharel em Informática - Sistemas de Informação. 

Orientador: Ms. Romário Lopes de Alcântara 

Ijuí 

Dezembro/2011




Trabalho de Conclusão de Curso apresentado ao Curso 

de Informática - Sistemas de Informação do 

Departamento de Ciências Exatas e Engenharias 

(DCEEng), da Universidade Regional do Noroeste do 

Estado do Rio Grande do Sul (UNIJUÍ), como requisito 

para a obtenção do título Bacharel em Informática - 

Sistemas de Informação. 

Orientador: Prof. Ms. Romário Lopes de Alcântara 

BANCA EXAMINADORA 

Ijuí 

Dezembro/2011 

Prof. Ms. Marcos R. M. Cavalheiro

Agradecimentos 

Primeiramente, quero agradecer a Deus por me estender a mão durante a conclusão deste 

trabalho, pois, apesar das dificuldades, me levantou e fez com que não desanimasse. Por ser meu 

alicerce e porto seguro. 

À minha esposa Andressa, pelos incentivos e por não me deixar desanimar. A alegria 

contagiante me renova e sua dedicação e amparo me dão a certeza de que você me completa. 

À minha família, que sempre esteve ao meu lado e nunca mediu esforços param me 

ajudar, que me colocou no rumo em todas as vezes que me desviei e me deu carinho quando 

precisei. 

À orientação do professor e mestre Romário Lopes de Alcântara pela disponibilidade, 

ajuda e incentivo. 

me tornar. 

Aos demais professores e mestres que foram fundamentais no profissional que sou e irei 

Aos colegas que, mesmo durante o aprendizado foram amigos e, com certeza, são os 

responsáveis por deixar o ensino mais prazeroso. 

Por fim, aos amigos, sempre dispostos a ajudar e apoiar.

“A medida de um homem não está naquilo que alcança, 

mas naquilo que almeja alcançar.” 

Kahlil Gibran

SUMÁRIO 

Lista de Abreviaturas ....................................................................................................................... 9 

Lista de Figuras ............................................................................................................................. 11 

RESUMO ...................................................................................................................................... 14 

ABSTRACT .................................................................................................................................. 15 

1 INTRODUÇÃO ..................................................................................................................... 16 

1.1 Posicionamento .................................................................................................. 16 

1.2 Objetivo Geral ................................................................................................... 17 

1.3 Organização do Trabalho................................................................................... 17 

1.4 Local da Implantação......................................................................................... 18 

1.4.1 Descrição da Empresa ............................................................................. 18 

1.4.2 Estrutura da Área de TI ........................................................................... 19 

1.4.3 Proposta ................................................................................................... 24 

2 ASPECTOS GERAIS DA ITIL ............................................................................................ 25 

2.1 Sobre ITIL ......................................................................................................... 25 

2.1.1 Gestão de Serviços .................................................................................. 28 

2.2 Ciclo de Vida de ITIL ........................................................................................ 28 

2.3 Serviço ............................................................................................................... 30 

2.4 Processo ............................................................................................................. 30 

2.5 Central de Atendimento ..................................................................................... 31 

2.5.1 Atribuições .............................................................................................. 31 

2.5.2 Objetivos ................................................................................................. 31

2.5.3 Atividades ............................................................................................... 32 

2.5.4 Estrutura .................................................................................................. 32 

2.5.5 Implementação ........................................................................................ 33 

2.6 Foco do Trabalho sobre ITIL............................................................................. 35 

2.6.1 Gerenciamento de Incidentes .................................................................. 35 

2.6.2 Gerenciamento de Problema ................................................................... 41 

2.6.3 Gerenciamento de Mudança ................................................................... 46 

2.7 Ferramentas para Desenvolvimento .................................................................. 50 

2.7.1 Scriptcase ................................................................................................ 50 

2.7.2 Mysql ...................................................................................................... 50 

2.7.3 FusionCharts ........................................................................................... 51 

3 MODELAGEM DO SISTEMA PROPOSTO ....................................................................... 52 

3.1 Domínio do Sistema .......................................................................................... 52 

3.2 Descrição dos Objetivos .................................................................................... 52 

3.3 Lista de Requisitos ............................................................................................ 53 

3.4 Local do Sistema ............................................................................................... 54 

3.5 Processo de Software ......................................................................................... 55 

3.5.1 Modelo Evolutivo ................................................................................... 55 

3.5.2 Modelo Cascata ....................................................................................... 55 

3.6 Arquitetura do Sistema ...................................................................................... 56 

3.7 Cenários ............................................................................................................. 56 

3.7.1 Cenários Primários .................................................................................. 56 

3.7.2 Cenários Secundários .............................................................................. 57 

3.8 Listagem dos Casos de Uso ............................................................................... 57 

3.9 Projeto Lógico das Tabelas do Sistema ............................................................. 58 

3.9.1 Nome externo: chamado ......................................................................... 59 

3.9.2 Nome externo: chamado_mudança ......................................................... 59 

3.9.3 Nome externo: ec_conhecido .................................................................. 59 

3.9.4 Nome externo: especificacao .................................................................. 59 

3.9.5 Nome externo: ic_conhecido .................................................................. 60 

3.9.6 Nome externo: incidente ......................................................................... 60 

7

3.9.7 Nome externo: incidente_problema ........................................................ 60 

3.9.8 Nome externo: matriz_prioritaria ........................................................... 60 

3.9.9 Nome externo: mudanca ......................................................................... 61 

3.9.10 Nome externo: problema ......................................................................... 61 

3.9.11 Nome externo: setor ................................................................................ 61 

3.9.12 Nome externo: solicitacao ....................................................................... 62 

3.9.13 Nome externo: tipo ................................................................................. 62 

3.9.14 Nome externo: user ................................................................................. 62 

3.9.15 Nome externo: responsavel_especificacao ............................................. 63 

3.10 Diagrama de Casos de Uso ................................................................................ 63 

3.10.1 Caso de Uso ............................................................................................ 63 

3.11 Diagrama de Classe ........................................................................................... 67 

3.12 Diagrama de Estado ........................................................................................... 68 

3.12.2 Diagrama de Estado de Mudança............................................................ 69 

3.13 Relação de Programas a serem desenvolvidos .................................................. 70 

3.13.1 Programas de Cadastro: .......................................................................... 70 

3.13.2 Programas de Consultas: ......................................................................... 70 

3.13.3 Programas de Relatórios/ Indicadores: ................................................... 70 

3.14 Projetos de Entrada (Cadastros) e Saídas (Relatórios) ...................................... 71 

3.14.1 Tela de Login .......................................................................................... 71 

3.14.2 Tela de Abertura de Chamado ................................................................ 71 

3.14.3 Definição de Fluxo (Solicitação ou Incidente) ....................................... 72 

3.14.4 Responsáveis pelos Serviços ................................................................... 72 

3.14.5 Matriz Prioritária ..................................................................................... 73 

4 RESULTADOS DA IMPLANTAÇÃO DA CENTRAL DE ATENDIMENTO E SISTEMA 

DE CHAMADOS .......................................................................................................................... 74 

CONSIDERAÇÕES FINAIS ........................................................................................................ 78 

BIBLIOGRAFIA ........................................................................................................................... 80 

8

LISTA DE ABREVIATURAS 

6M’s – Mão de obra, material, meio ambiente, método, máquina e medida 

AJAX – Asynchronous Javascript and XML 

ANS – Acordo de Nível de Serviço 

BD – Base de dados 

BDEC – Banco de Dados de Erros Conhecidos 

CCTA – Central Computing and Telecommunications Agency 

COBOL – Common Business Oriented Language 

DB – Data Base 

DBA – Data Base Administrator 

EC – Erros Conhecidos 

EFQM – European Foundation for Quality Management 

HTML – Hypertext Markup Language 

HTTP – Hypertext Transfer Protocol 

HTTPS – Hypertext Transfer Protocol secure 

IC – Incidentes Conhecidos 

ICT – Information and Communication Technology 

ISO – International Organization for Standadization 

IT – Information Technology 

ITIL – Information Technology Infrastructure Library 

JSON – Javascript Object Notation 

9

OGC – Office of Government Commerce 

PHP – Hypertext Preprocessor 

SGBD – Sistemas Gerenciadores de Banco de Bados 

SIC – Sistema Interno de Comunicação 

SLA – Service Level Agreement 

SQL – Structured Query Language 

TI – Tecnologia da Informação 

XML – Extensible Markup Language 

10

LISTA DE FIGURAS 

Figura 1.1- Vista aérea do parque fabril da empresa Bruning Tecnometal S.A. ........................... 19 

Figura 1.2 – Tela inicial para abertura de chamado. ..................................................................... 20 

Figura 1.3 – Distribuição do chamado por área............................................................................. 21 

Figura 1.4 – Histórico de transferência de chamado. .................................................................... 21 

Figura 1.5 – Histórico de chamados concluídos. ........................................................................... 22 

Figura 1.6 – Indicador de eficiência da equipe de TI. ................................................................... 23 

Figura 2.1 – Livros que compõem a biblioteca ITIL (OGC)......................................................... 26 

Figura 2.2 – Mapa de ITIL (ITIL, 2007). ...................................................................................... 27 

Figura 2.3 – Fluxo do Ciclo de vida de ITIL (ITIL, 2007)............................................................ 28 

Figura 2.4 – Ciclo de Vida de Serviços de TI (QUEIROZ, 2009). ............................................... 29 

Figura 2.5 – Processo (MAGALHÃES E PINHEIRO, 2010). ...................................................... 30 

Figura 2.6 - Central de Serviços Centralizada (ARRUDA, 2010). ............................................... 33 

Figura 2.7 – Entradas e Saídas do processo de Gerenciamento de Incidentes (ARRUDA, 2010).35 

Figura 2.8 – Ciclo de vida de um incidente (MAGALHÃES E PINHEIRO, 2010). .................... 38 

Figura 2.9 – Escalonamento de Incidentes (MAGALHÃES E PINHEIRO, 2010). ..................... 39 

Figura 2.10 – Entradas e saídas principais do processo (ARRUDA, 2010). ................................. 43 

Figura 2.12 – Exemplo (com 5M’s) do diagrama de Ishikawa (RIGONI, 2009).......................... 45 

11

Figura 3.1 - Tabela de abertura de chamado. ................................................................................ 59 

Figura 3.2 - Tabela de discriminação dos chamados afetados pela mudança ............................... 59 

Figura 3.3 - Tabela de erros conhecidos. ....................................................................................... 59 

Figura 3.4 - Tabela discriminada dos serviços prestados pelo TI. ................................................ 59 

Figura 3.5 - Tabela de incidentes conhecidos. .............................................................................. 60 

Figura 3.6 - Tabela de incidentes. ................................................................................................. 60 

Figura 3.7 - Tabela de discriminação dos incidentes transformados em problema. ...................... 60 

Figura 3.8 - Tabela do Acordo de Nível de serviço (ANS). .......................................................... 60 

Figura 3.9 - Tabela de mudanças. .................................................................................................. 61 

Figura 3.10 - Tabela de problemas. ............................................................................................... 61 

Figura 3.11 - Tabela de setores. ..................................................................................................... 61 

Figura 3.12 - Tabela de solicitação de serviço. ............................................................................. 62 

Figura 3.13 - Tabela da área de serviços de TI. ............................................................................. 62 

Figura 3.14 - Tabela de usuários (equipe técnica) do sistema. ...................................................... 62 

Figura 3.15 - Tabela de responsável por área de serviço. .............................................................. 63 

Figura 3.16 – Diagrama de Caso de Uso do sistema de chamados. .............................................. 63 

Figura 3.17 – Diagrama de Classe. ................................................................................................ 67 

Figura 3.18 – Diagrama de estado da abertura de chamado. ......................................................... 68 

Figura 3.19 – Diagrama de estado da Mudança. ........................................................................... 69 

Figura 3.20 – Tela de Login. ......................................................................................................... 71 

Figura 3.21 – Abertura de Chamados ............................................................................................ 71 

Figura 3.22 – Definição do Fluxo do Chamado (Solicitação ou Incidente). ................................. 72 

Figura 3.23 – Responsáveis pelo serviço....................................................................................... 72 

Figura 3.24 – Matriz de Prioridades (Impacto x Urgência). .......................................................... 73 

12

Figura 4.1 – Chamados Abertos no Período. ................................................................................. 74 

Figura 4.2 – Chamados encerrados no período (por tipo). ............................................................ 75 

Figura 4.3 – Nível de atendimento por chamado........................................................................... 75 

Figura 4.4 – Chamados por nível de suporte. ................................................................................ 76 

Figura 4.5 – Discriminação da área “Diversos”. ........................................................................... 77 

13

RESUMO 

A área de TI tem uma grande importância para as empresas. Seu papel é no mínimo, estar 

alinhado com o negócio para fornecer informações que apoiem as decisões da área executiva. 

Além de gerar e gerenciar a informação, é obrigação da área de TI manter o bom funcionamento 

dos serviços, evitando possíveis perdas competitivas. Pensando na importância e no impacto que 

a indisponibilidade de um serviço pode causar a uma empresa, tornaram-se necessários estudos 

para encontrar as melhores práticas da gestão de serviços de TI. E foi o que a OGC (Office of 

Government Commerce) fez criando o framework ITIL (Information Technology Infrastructure 

Library). 

Baseado no gerenciamento de incidentes, problemas e mudanças, descrito em ITIL, este 

trabalho visa implantar uma central de atendimento e um sistema de chamados para a empresa 

Bruning Tecnometal SA. A central terá a função de centralizar os contatos com usuários e o 

sistema de chamados é a proposta de sistema para receber e registrar todos os contatos com o TI, 

desde requisições de serviço, notificação de incidentes, até a alteração de algum sistema. 

Palavras-chave: Informação. Central de Atendimento. ITIL. 

14

ABSTRACT 

The IT has a great importance to business. The IT's role is to be aligned with business to 

provide information and to support the executive's decisions. In addition to generating and 

managing information, the IT obligation is to maintain satisfatory service operation, in this way, 

avoiding losses in competition. 

Furthermore, thinking about the importance and the impact that the unavailability of a 

service can cause to a company, it turns out to be necessary further studies to find better 

management practices on IT services. That is the reason why the OGC (Office of Government 

Commerce) created the framework called ITIL. 

Moreover, ITIL work is based on incidents management, problems, and changes. Besides 

that, ITIL's goal is to stablish a service desk system and a call center to Bruning Tecnometal S/A 

company. The call center's function is to centralize the contacts with its users. On the other hand, 

the service desk system was created for the purpose of receiving and recording IT's contacts. It 

englobes service, requests, notification of incidents, and even system changes. 

Keywords: Information. Service Desk. ITIL 

15

1 INTRODUÇÃO 

1.1 Posicionamento 

No atual momento, onde o cenário corporativo foca a evolução tecnológica, empresas 

inovam e, além da tecnologia, visam ao suporte como diferencial competitivo. Devido às 

constantes mudanças, torna-se necessário estar preparado para agir com rapidez e objetividade 

perante as falhas e imprevistos. É de consenso que independente do cliente (interno ou externo), a 

disponibilidade de serviços de TI deve ser prioridade e o atendimento (suporte) devem ser de 

qualidade. 

Com o amadurecimento da consciência corporativa em relação à área de TI, ficou evidente 

a necessidade de alinhar a TI como negócio da empresa. Com isso, a TI passou de uma simples 

área de apoio, para uma área diretamente relacionada com a alta gerência, abastecendo os 

executivos com informações fundamentais para decisões estratégicas e gerenciais. Dessa forma, 

ficou evidente a necessidade de evoluir a qualidade dos serviços prestados pela área. 

Muitas vezes, a ausência de informação sobre a indisponibilidade de algum serviço, 

somada a dificuldade de encontrar o responsável pela solução do problema causa algumas críticas 

por parte dos clientes. A reincidência desses problemas pode agravar a insatisfação, quando não 

muito, uma quebra de confiança por parte do cliente, em relação à equipe de TI. 

Com o intuito de contornar esse problema, foram definidas as melhores práticas de ITIL 

sobre o Gerenciamento de Serviços de TI. A partir de uma metodologia baseada em processos, a 

ITIL visa à melhoria contínua que afeta desde pessoas até a tecnologia, tendo a redução dos 

custos e a agilidade dos processos como parceiros estratégicos do negócio. 

16

1.2 Objetivo Geral 

O objetivo principal deste trabalho é, a partir de uma pesquisa bibliográfica sobre as 

melhores práticas reunidas na ITIL, desenvolver um sistema de chamados para suporte a usuários 

na empresa Bruning Tecnometal SA. Esta pesquisa tem seu foco baseado em ITIL devido a casos 

de sucesso, onde ficou evidenciado o aumento de produtividade da área de desenvolvimento da 

empresa. 

Um dos focos de ITIL é o Gerenciamento de Serviços de TI. Como referência, podemos 

usar um Service Desk, que é considerado uma evolução se comparado com o Help Desk. A 

diferença entre os dois é que, ao contrário do Help Desk, o Service Desk tem um canal 

centralizado de atendimento ao cliente. Uma das metas do Service Desk é que a grande maioria 

dos contatos com a área de suporte deve ser solucionada pelos responsáveis do atendimento em 

1º nível, isso faz com que os técnicos e especialistas da área dediquem mais do seu tempo para a 

criação e mudanças. Outra atividade dos responsáveis pelo atendimento em 1º nível é deixar o 

cliente bem informado sobre a previsão de retorno do serviço, ou sobre a solução do problema, 

bem como, identificar melhorias, reforçar treinamentos e principalmente, caso não consiga 

solucionar um chamado, abastecer os técnicos e especialistas com informações sobre o problema. 

Baseado nos resultados de outras empresas que implantaram ITIL, estima-se que o 

atendimento em primeiro nível possa ser responsável por 65% de todos os chamados, porém, 

como a implantação será exponencial, têm-se a expectativa de alcançar a margem de 50% dos 

chamados. 

1.3 Organização do Trabalho 

O capítulo 2 trabalha com o conceito de ITIL (IT Infrastructure Library), uma ferramenta 

desenvolvida pelo governo britânico com o objetivo de padronizar os serviços prestados pela área 

de TI dos departamentos do governo. Um dos tópicos será a Central de Serviços (Service Desk), 

na empresa Bruning será denominada Central de Atendimento, tendo a proposta de suas 

atribuições, bem como sua implantação e os problemas que estão sendo esperados para a 

implementação. Também, será apresentado o foco sobre ITIL, ao qual será incorporado na 

17

Central de Atendimento. O Gerenciamento de Incidente, Gerenciamento de Problema e 

Gerenciamento de Mudanças serão os processos destacados da ITIL. 

No capitulo 3 será apresentado a modelagem do sistema proposto. Nele constará o 

domínio do sistema, a lista de requisitos, o processo de software, a arquitetura do sistema, os 

casos de uso, dentre outros. 

Por fim, o capítulo 4 mostrará os resultados obtidos com a pesquisa e implantação do 

sistema proposto. A pesquisa (capítulo 2) foi fundamental para a implantação dos processos 

descritos em ITIL. Já o capítulo 3 tem a importância de gerar a informação e apresentar os 

resultados, permitindo a conclusão sobre o sucesso do projeto. 

1.4 Local da Implantação 

1.4.1 Descrição da Empresa 

O trabalho será realizado na empresa Bruning Tecnometal S.A. (Figura 1.1) em sua 

unidade fabril localizada na Rua 25 de Julho, 2305, Bairro Jaciandi, na cidade de Panambi/RS. 

A empresa foi fundada em 1º de abril de 1947 pelo Sr. Ernesto Rehn, atuando no ramo 

metal-mecânico, fornecedora de produtos das linhas automotiva, rodoviária e agrícola, através do 

beneficiamento de metais utilizando tecnologias de processo nas áreas de estamparia, usinagem, 

soldagem e tratamentos superficiais. 

A empresa é certificada pelas normas ISO-14001, ISO-9001 e ISO-TS 16949. 

18

Figura 1.1- Vista aérea do parque fabril da empresa Bruning Tecnometal S.A. 

Fonte: Bruning Tecnometal S/A 

Abaixo são citadas algumas características do parque fabril da empresa: 

- Área: 65.000 m² construídos em uma área total de 441.000 m²; 

- Número de funcionários: 3.050; 

- Beneficiamento de aço: 4.600 ton. / mês; 

- Faturamento: em torno de 500 milhões / ano (previsão para 2011); 

1.4.2 Estrutura da Área de TI 

O departamento de TI da empresa é dividida em três áreas, a área de suporte a hardware e 

infraestrutura, a área de desenvolvimento e suporte COBOL e a área de desenvolvimento e 

suporte web (intranet). No topo da estrutura está o gerente de TI que é o responsável pelas 

decisões estratégicas e administrativas das três áreas. 

Com exceção da área de suporte, nas duas áreas de desenvolvimento os programadores 

são os responsáveis pelo suporte dos sistemas por eles desenvolvidos. Para qualquer dúvida que o 

usuário tenha ou algum problema identificado, o usuário tem acesso direto ao programador para 

informar ou questionar. Cientes da necessidade de registrar todos os contatos com usuários, a 

19

área de TI TI desenvolveu desenvolveu um sistema de chamados, onde onde o o usuário seleciona seleciona o sistema sistema e reporta o 

o 

problema ou dúvida para o programador, por por ele definido, conforme figura 1.18. 

1.4.2.1 O Sistema de Chamados Atual 

Figura 1.2 – Tela inicial para abertura de chamado. 

O sistema de chamados é a garantia do usuário de que seu problema vai ser atendido. 

Nele, o usuário usuário seleciona seleciona o o tipo tipo do do problema problema (onde (onde geralmente separamos as as áreas), áreas), conforme 

conforme 

figura 1.3 e especifica o problema (seleciona o o sistema sistema ou o o dispositivo dispositivo com problema). 

problema). 

20

Como Como é é o o usuário usuário que define os responsáveis pelo sistema, habilitamos habilitamos a possibilidade de 

transferir os os chamados entre a equipe de TI, TI, deixando deixando o usuário devidamente devidamente informando sobre sobre a 

transferência. Existe também, um histórico de transferência (figura 1.4), onde é possível ver a 

origem do chamado. 

Figura 1.3 – Distribuição do chamado por área. 

Figura 1.4 – Histórico de transferência de chamado. 

chamado 

21

Há ainda, um relatório sobre chamados concluídos (figura 1.5), onde é possível verificar a 

data de conclusão e a informação passada ao usuário usuár sobre a solução do problema/solicitação. 

problema/ 

Figura 1.5 – Histórico de chamados concluídos. 

Outra funcionalidade é o relatório sobre a eficiência da área (figura 1.6). Nela é exibida a 

média de solicitações diárias, a média média de de transferências e o tempo médio para a solução do 

chamado em um determinado período. período. 

22

1.4.2.2 Dificuldades Encontradas 

Figura 1.6 – Indicador de eficiência da equipe de TI. 

Na atual forma de trabalho, não há uma maneira confiável de avaliar o desempenho da 

equipe. Para cada problema identificado exi existe ste uma solução, porém, não é possível distinguir se a 

solução é definitiva ou uma forma de contorno para restabelecer o serviço. Também, não existe a 

informação se a maioria dos cha chamados emitidos é de solicitação ou problema. Deixando evidente 

que o indicador ador de chamados concluídos e o ranking de eficiência (figura (figura 1.6) 1.6) não são são suficientes 

para avaliar a equipe. 

23

1.4.3 Proposta 

Com o intuito de melhor atender ao usuário (cliente interno) e aumentar a produtividade 

da área de desenvolvimento, foi identificada em ITIL uma excelente referência para as melhores 

práticas nos processos de atendimento. Com isso, pretende-se implantar uma central de serviços, 

denominada central de atendimento, onde será centralizado o contato preliminar com o cliente. 

A ideia é definir os acordos de níveis de serviço e apresentar para a empresa quais 

serviços serão prestados pela área. Dessa forma, caberá à central fazer o filtro inicial de chamado 

e o atendimento preliminar ao usuário, o qual será tratado como suporte em primeiro nível. 

No caso de a central não conseguir prover o suporte para determinado problema, este será 

encaminhado à área técnica, ao qual será tratado como suporte em segundo nível. A solução do 

suporte em segundo nível irá abastecer uma base de conhecimento que servirá como referência 

para a central em chamados futuros. 

Trabalhando dessa forma, permite-se que em um determinado momento (definido pela 

gerência) seja feita uma análise sobre os chamados, onde será avaliada a sua reincidência e 

tomadas ações para que a sua solução seja definitiva. 

24

2 ASPECTOS GERAIS DA ITIL 

2.1 Sobre ITIL 

A ITIL foi criada pela CCTA, atualmente denominada como OGC, no final da década de 

1980. O OGC é um órgão do governo britânico que tem como finalidade a padronização e 

melhorias dos processos internos dentro dos departamentos do governo britânico. A criação da 

biblioteca de ITIL teve como objetivo, a melhoria dos processos específicos de TI. A partir de 

1990, ITIL se expandiu para a Europa inteira e acabou recebendo contribuições no seu 

desenvolvimento de empresas como IBM e Microsoft (ITIL, 2011). 

Tendo o foco voltado para a qualidade e na proposição de melhores práticas para o 

Gerenciamento de Serviços de TI, a ITIL viabiliza a implantação da certificação ISO 9000 e ao 

modelo europeu (EFQM). Como resultado, foi adotado também, pelos países da América do 

Norte, tornando-se a referencia principal para esse segmento de TI. Hoje, seu uso é explorado por 

empresas públicas e privadas em países de todo o mundo, tendo como base uma pesquisa 

realizada pela Forester Research em empresas com faturamento igual ou superior a US$ 1 bilhão 

(MAGALÃES E PINHEIRO, 2010): 

- 13% em 2004; 

- 40% em 2006; 

- 80% em 2008; 

Essa evolução na adoção das práticas de ITIL pelas empresas foi motivada, 

principalmente, pelo ganho dos seguintes aspectos: 

- Aumento da disponibilidade dos Serviços de TI; 

- Identificação e acompanhamento das mudanças nos Serviços de TI; 

25

- Medição do retorno sobre os investimentos em TI. 

- Satisfação em relação à qualidade e na relação custo/ benefício dos Serviços de TI; 

- Provisionamento das entregas e manutenção dos serviços; 

- Segurança (desde o sentido estrutural, a disponibilidade de serviços e mudanças). 

No início, a ITIL era integrada por 40 livros (por isso chamam de biblioteca). Mas a partir 

de 2000 ela foi reformulada, conforme figura 2.1 e reduzida para oito livros, sendo denominada 

como ITIL v2. As práticas defendidas por ITIL eram as seguintes: 

• Service Support (Suporte ao Serviço); 

• Service Delivery (Entrega de Serviço); 

• Planning and Implementation (Planejamento e Implementação); 

• Applications Management (Gerenciamento de Aplicações); 

• Security Manager (Gerenciamento de Segurança); 

• Information and Communication Technology (ICT) Infrastructure Management 

(Gerenciamento da Infraestrutura de TI e de Comunicações); 

• Business Perspective (Perspectiva de Negócio); 

• Software Asset Management (Gerenciamento dos Ativos de Software). 

Figura 2.1 – Livros que compõem a biblioteca ITIL (OGC) 

Posteriormente, em maio de 2007, foi lançada uma atualização sobre a versão 2 de ITIL, 

denominada de ITIL v3. A comparação entre ITIL v2 e v3 mostra que os principais processos de 

26

ITIL v2 permaneceram na v3, porém, os processos foram revisados e melhorados 

(CHIARI,2010). 

O novo ciclo de vida dos Serviços, proposto em ITIL v3 e conforme figura 2.2, teve como 

foco o melhor entendimento, organizando os processos de uma forma cíclica. Dessa forma, a 

versão 2 é substituída por um conjunto de 5 livros: 

- Service Strategies (Estratégias de Serviço); 

- Service Design (Desenho de Serviço); 

- Service Transition (Transição de Serviço); 

- Service Operation (Operação de Serviço); 

- Continual Service Improvement (Melhoria Contínua de Serviço); 

Figura 2.2 – Mapa de ITIL (ITIL, 2007). 

27

2.1.1 Gestão de Serviços 

A gestão de serviços é uma estrutura de gestão que planeja, monitora e controla a 

qualidade do serviço. Seu objetivo é coordenar recursos específicos, técnicos e organizacionais 

que agreguem valor ao cliente. Dessa forma é possível obedecer às exigências dos clientes e 

empresas, otimizar a qualidade dos serviços prestados e reduzir os custos do serviço a longo 

prazo (MAGALÃES E PINHEIRO, 2010). 

2.2 Ciclo de Vida de ITIL 

A estrutura dos manuais é baseada no ciclo de vida dos serviços. Coube a Estratégia de 

serviço ser definida como o eixo de onde gira o ciclo de vida. 

Figura 2.3 – Fluxo do Ciclo de vida de ITIL (ITIL, 2007). 

Das ações implementadas pelos meios de serviço de Transição, Operação e Desenho, são 

geradas ações de melhorias que refletem o aprendizado contínuo (melhoria contínua) e ajudam a 

melhorar os projetos com base nos objetivos estratégicos (ITIL, 2007). 

Para QUEIROZ (2009), o ciclo de vida de serviços de TI é dividido em 3 partes: 

28

- Análise de requisitos e definição inicial, composto pelos livros de Service Strategy e 

Service Design. Nele são definidos os requisitos do negócio e planejados os resultados esperados, 

além da disponibilidade do serviço; 

- Migração para o ambiente de produção, composto pelo livro de Service Transition. 

Durante a implementação de um novo sistema ou alteração de um sistema já existente, tem-se a 

responsabilidade de testar, acompanhar e validar a implementação. 

- Operação e melhoria em produção, composto pelos livros de Service Operation e 

Continual Service Improvement. É responsável por manter a disponibilidade dos serviços, para 

alcançar os resultados esperados e identificar alguma oportunidade de melhoria nos serviços, 

respectivamente. 

Figura 2.4 – Ciclo de Vida de Serviços de TI (QUEIROZ, 2009). 

29

2.3 Serviço 

Segundo o dicionário (AURÉLIO, 2008), o termo serviço pode ser definido como o 

desempenho de uma função obrigatória ou necessária. Para a área de TI é possível dizer que um 

serviço é um componente (físico ou virtual) fornecido como suporte para um ou mais processos. 

Para facilitar o entendimento, um sistema contábil utiliza uma base PostgreSQL e rede. O 

banco PostgreSQL e a rede são serviços que atuam como suporte para que o sistema contábil 

funcione normalmente. 

Queiroz (2009) define serviço de TI como “um meio para entregar valor aos clientes, 

propiciando os resultados que eles queiram alcançar sem que eles tenham que assumir custos e 

riscos específicos”. 

2.4 Processo 

Magalhães e Pinheiro (2010) afirmam em seu livro "Gerenciamento de Serviços de TI na 

Prática" que processo é uma série de ações, atividades, mudanças, etc., conectadas entre si e 

realizadas por agentes com o fim de satisfazer um propósito ou alcançar uma meta. 

Ainda, segundo os mesmos, os processos são o mais alto nível de definição de atividades 

de uma organização. Os procedimentos são mais detalhados e descrevem exatamente o que deve 

ser executado em determinada atividade do processo. 

Figura 2.5 – Processo (MAGALHÃES E PINHEIRO, 2010). 

30

2.5 Central de Atendimento 

A central de atendimento será fundamental para a implementação do Gerenciamento dos 

Serviços de TI e ao contrário do que se pensa, ela não é um processo e sim uma função. Muitos 

pensam que a central é um ponto de suporte aos usuários, mas mais que isso, a Central de 

Serviços é a interface principal de operação entre a área de TI e os usuários dos seus serviços. Ela 

é responsável pelo atendimento preliminar, desde um esclarecimento sobre serviços, solicitação 

de serviço, até para informar a ocorrência de um erro no serviço (ARRUDA, 2010). 

2.5.1 Atribuições 

Com a implantação da central de serviços, podemos dividir a área de suporte, da área 

responsável pela solução dos problemas e desenvolvimento. Com essa mudança, acredita-se que 

o usuário tenha o benefício de um suporte com agilidade e qualidade, proporcionando também, o 

aumento de produtividade da área técnica que não terá o seu trabalho interrompido com 

chamadas diretas dos usuários (somente se a central não conseguir solucionar o problema). 

A central de serviços é considerada uma evolução em relação ao help desk devido à 

unificação do suporte em primeiro nível, ou seja, cabe à central tratar todas as solicitações 

relacionadas aos serviços prestados pela área de TI. No help desk existiam vários atendentes de 

diferentes níveis, fazendo com que o usuário do serviço passasse por vários níveis de atendimento 

sem ter o problema solucionado (MAGALHÃES E PINHEIRO, 2010). 

2.5.2 Objetivos 

Para Arruda (2010), são objetivos da central: 

• Minimizar os contatos dos usuários com a área técnica, concluindo os chamados 

num primeiro nível de suporte; 

• Utilizando a informação como ferramenta (base de erros conhecidos e base de 

conhecimento), é de responsabilidade da central ,restaurar os serviços o mais breve 

possível; 

• Conhecer o negócio, para saber o impacto causado por cada serviço prestado pela 

área; 

31

2.5.3 Atividades 

• Manter o usuário abastecido com informações sobre o agendamento das mudanças 

e sobre o restabelecimento do funcionamento do serviço; 

• Acompanhar o incidente durante o seu ciclo de vida e deixar o usuário 

devidamente informado sobre a solução (provisória ou definitiva). 

As seguintes atividades são definidas (MAGALHÃES E PINHEIRO, 2010): 

2.5.4 Estrutura 

• Receber e armazenas todos os contatos dos usuários; 

• Acompanhar os pedidos e reclamações; 

• Gerar uma avaliação inicial de todos os incidentes comunicados; 

• Realizar o suporte de primeiro nível; 

• Encaminhar para a área técnica (segundo nível de suporte) os incidentes não 

solucionados, obedecendo os níveis de serviços estabelecidos (SLA). 

• Monitorar os atendimentos e escalar de acordo com os níveis estabelecidos; 

• Informar os usuários sobre o status do incidente e comunicar a evolução do 

atendimento; 

• Identificar a necessidade de treinamento dos usuários; 

• Gerar informações gerenciais; 

• Ajudar na identificação de problemas. 

Como a empresa é situada em apenas uma cidade e não possui filial, utilizaremos a 

estrutura centralizada, onde o objetivo é centralizar todas as solicitações de suporte em um único 

local. Com a central de serviços centralizada há um ganho na redução de custos e otimização da 

utilização de recursos (ARRUDA, 2010). 

32

2.5.5 Implementação 

Figura 2.6 - Central de Serviços Centralizada (ARRUDA, 2010). 

Seguindo as diretrizes de Magalhães e Pinheiro (2010), o projeto de implantação é 

dividido em cinco etapas: 

2.5.5.1 Levantamento das informações 

Para que a central de serviços tenha sucesso, é necessário que a mesma tenha uma 

documentação completa sobre fluxos, scripts e regras de escalonamento para qualquer incidente 

ou consultas feitas pelos usuários. Muita informação será complementada durante a execução do 

projeto, mas a organização/criação de uma base inicial de conhecimento é fundamental para que 

o analista tenha em que se basear e tirar as dúvidas. 

O livro de ITIL destaca como fundamental nessa etapa, a definição de categorias de 

atendimento, prazos de solução e a estrutura para o Acordo de Nível de Serviço (ANS, ou SLA 

em inglês) (MAGALHÃES E PINHEIRO, 2010). 

2.5.5.2 Definição de nível de habilidade necessário para manter o processo 

Nesta etapa é estipulado o nível de conhecimento necessário para o atendimento. Como a 

central será iniciada do princípio, foi optado pela central de serviços básica. À medida que houver 

33

uma evolução na base do conhecimento, paralela à evolução da base de dados do sistema, haverá 

uma qualificação nos serviços prestados pela central (MAGALHÃES E PINHEIRO, 2010). 

2.5.5.3 Definição da forma mais eficaz para atender à demanda 

No item 2.5.4 foi definido que a central será implantada de maneira centralizada. 

2.5.5.4 Definição dos níveis de serviço 

Definiremos os níveis de serviços que serão utilizados para o atendimento, focaremos no 

equilíbrio entre desempenho e segurança x custo e na quantidade e custo de recurso x 

desempenho/disponibilidade dos serviços (MAGALHÃES E PINHEIRO, 2010): 

2.5.5.5 Gerenciamento do resultado 

Estabelecer regras para gerenciamento das informações, transformando-as em relatórios 

gerenciais. Extrair indicadores de desempenho da equipe técnica e da central de serviços. 

2.5.5.6 Problemas Previstos 

Foram identificados alguns fatores críticos de sucesso (ARRUDA, 2010): 

• Usuários tentarão acesso direto ao técnico responsável pelo serviço antes da 

implantação da central; 

• Convencer a equipe sobre a importância de um atendimento de qualidade; 

• Investir na capacitação da equipe para renovar as tecnologias empregadas; 

• Motivação e comprometimento da equipe de atendimento; 

• Certificar que toda a equipe de TI participe da definição dos acordos de nível de 

serviço (ANS). 

• Alocar as pessoas com conhecimento e perfil adequado para a execução das 

diferentes tarefas. 

34

2.6 Foco do Trabalho sobre ITIL 

2.6.1 Gerenciamento de Incidentes 

Para Magalhães e Pinheiro (2010), o gerenciamento de incidente tem como objetivo 

assegurar que após a ocorrência de um incidente, o serviço de TI afetado tenha seu 

funcionamento restaurado o mais breve possível, fazendo com que a indisponibilidade não tenha 

impactos sobre o negócio. Para que os serviços sejam restabelecidos o mais breve possível, pode 

ser utilizada uma solução de contorno (workaround), que faz com que o serviço afetado retorne 

suas funcionalidades, de maneira provisória, reduzindo o impacto do incidente no negócio. 

O livro de ITIL (2007) define o incidente como a entrada principal do processo. Essa 

entrada deriva, não somente dos usuários, mas também de ferramentas de monitoramento 

(infraestrutura) e equipes de operação que podem identificar alguma instabilidade nos serviços. 

Figura 2.7 – Entradas e Saídas do processo de Gerenciamento de Incidentes (ARRUDA, 2010). 

A central de serviços é o primeiro contato com o usuário e também é responsável por 

catalogar/registrar a ocorrência, ela ainda acompanha todo o ciclo de vida do incidente. 

Monitorando o estado e o progresso do incidente, tendo a responsabilidade de manter as áreas 

usuárias dos serviços informadas sobre a previsão para regularização do serviço. Para falhas ou 

35

demora no atendimento do serviço, cabe à central rever os níveis de prioridade e alocação de 

recursos para o atendimento a determinado problema. 

Para auxiliar a central de atendimento e fazer com que os incidentes sejam atendidos no 1º 

nível de suporte, é importante dispor de um BDEC (banco de dados de erros conhecidos), onde se 

encontra um histórico de erros já conhecidos e que podem auxiliar a central na solução do 

incidente o mais breve possível, evitando o escalonamento para o segundo nível. 

2.6.1.1 Objetivos 

Incidentes: 

ARRUDA (2010) lista alguns dos principais objetivos do processo de Gerenciamento de 

• Resolver o incidente o mais breve possível, devolvendo a operabilidade do sistema 

(mesmo que seja provisório) ao usuário, respeitando a ANS; 

• Diminuir o impacto causado pelo incidente sobre o negócio; 

• Manter o usuário informado sobre o estado do incidente/ serviço; 

• A partir de um incidente, ter a capacidade de identificar as causas e se este pode 

tornar a acontecer. 

2.6.1.2 Solicitação de Serviço 

É o pedido de informação sobre o funcionamento do serviço/sistema ou um pedido de 

mudança em algum sistema/serviço. Sendo assim, nem todo chamado feito à central de 

atendimento é incidente (MAGALHÃES E PINHEIRO, 2010). 

Algumas solicitações: 

• Consulta sobre o funcionamento de algum aplicativo; 

• Informação sobre aquisição de algum serviço e ou produto de TI; 

• Solicitação de adequação da infraestrutura para mudança de layout. 

36

2.6.1.3 Erro Conhecido 

Identificado a partir de análises realizadas anteriormente como sendo a causa de um 

problema. Esses dados já estão armazenados na BDEC e são utilizados para solucionar incidentes 

que tenham os mesmos sintomas de outros incidentes já registrados previamente como erro 

conhecido (MAGALHÃES E PINHEIRO, 2010). 

A BDEC auxilia para que o incidente seja solucionado no primeiro nível de suporte 

(central de atendimento). Caso o incidente não tenha registros da BDEC ou não possa ser 

resolvido no primeiro nível, é encaminhado ao segundo nível de suporte. 

2.6.1.4 Processo 

Ao pesquisar a causa do incidente, o responsável pelo primeiro nível de suporte pesquisa 

no BDEC algum caso similar ao incidente atual. Ao identificar, deve-se aplicar a solução 

definitiva ou de contorno, normalizando o serviço e resolvendo o incidente. Caso não seja 

possível resolver, deverá encaminhar ao segundo nível de suporte. Dessa forma, o processo de 

gerenciamento de incidente deverá aumentar gradativamente o índice percentual dos incidentes 

encerrados no primeiro nível de suporte (MAGALHÃES E PINHEIRO, 2010). 

Apesar de diversas atividades a serem realizadas no processo de gerenciamento de 

incidente, as principais são: 

• Consulta ao BDEC, no objetivo de encontrar ocorrências similares que auxiliem na 

solução do incidente (mesmo que seja provisório) em um primeiro nível de 

suporte; 

• Classificar os incidentes, determinando prioridade a partir de uma análise de 

urgência x impacto do incidente; 

• Encerrar o incidente e restaurar o serviço de TI. 

37

2.6.1.5 Ciclo de Vida 

Um incidente pode ter diversos estados durante a sua vida. Dessa forma, pode-se auxiliar a 

central na previsão de normalização do serviço. A tabela de MAGALHÃES E PINHEIRO (2007) 

apresenta uma proposta de ciclo de vida. 

Estado Descrição 

Novo Ao ser registrado, o incidente assume o estado de "NOVO". 

Após uma primeira análise e a classificação em relação à sua prioridade, o 

Aceite incidente passa ao estado de "ACEITO". 

O incidente aceito está "PROGRAMADO" para atendimento, ou seja, 

encontra-se na fila de atendimento, esperando a definição de um analista para 

Programado execução do atendimento 

Atribuído O incidente já foi atribuído a um técnico responsável. 

Em andamento O trabalho de investigação e diagnóstico da causa do incidente já foi iniciado. 

O trabalho de investigação e diagnóstico da causa do incidente foi 

Em espera interrompido. 

A solução permanente ou de contorno foi implementada e o serviço de TI 

Resolvido afetado, restabelecido. 

A equipe de Central de Serviços contatou o usuário que comunicou o 

Encerrado incidente e obteve a confirmação da restauração do serviço de TI. 

Figura 2.8 – Ciclo de vida de um incidente (MAGALHÃES E PINHEIRO, 2010). 

2.6.1.6 Escalonamento 

Para Magalhães e Pinheiro (2010), o escalonamento visa à solução de um incidente no 

menor tempo possível, disponibilizando conhecimento (escalonamento horizontal) e recursos 

necessários (escalonamento vertical). 

No escalonamento horizontal, o incidente é tratado primeiramente pela central de serviços, 

responsável pelo atendimento em primeiro nível. Tendo como premissa que a solução é 

desconhecida (não se encontra no BDEC), ou não seja possível determinar a causa do incidente, 

passa-se para o atendimento em segundo nível e assim sucessivamente, conforme figura. 

38

Figura 2.9 – Escalonamento de Incidentes (MAGALHÃES E PINHEIRO, 2010). 

O escalonamento vertical consome um nível maior de suporte, mas também consome 

dinheiro e recursos, com o objetivo de resolver o incidente o mais breve possível. Também serve 

para suprir uma falha no processo do escalonamento horizontal (MAGALHÃES E PINHEIRO, 

2010). 

O monitoramento do progresso dos escalonamentos é fundamental para identificar 

possíveis erros de processo e para identificar possíveis melhorias no processo. 

2.6.1.7 Relatório de Gestão 

Kaplan e Norton (1997) escreverem em seu livro que “o que não é medido não é 

gerenciado”. Seguindo essa linha de raciocínio, por exemplo, ao acompar o processo de 

gerenciamento de incidentes, será possível gerar relatórios que auxiliem uma análise sobre carga 

de trabalho prevista e quantidade de itens de configuração sob gerenciamento. 

Magalhães e Pinheiro (2010) apresenta uma proposta de estrutura para o relatório de 

gestão do processo de gerenciamento de incidentes, a qual pode ser reduzida ou ampliada de 

acordo com a necessidade de cada organização: 

39

• Volume de atendimentos realizados; 

• Distribuição dos incidentes por serviço, prioridade, etc.; 

• Distribuição dos incidentes por área usuária; 

• Necessidade de capacitação e atualização da equipe de suporte; 

• Percepção de satisfação das áreas usuárias com atendimentos realizados; 

• Desempenho dos fornecedores de tecnologias empregadas nos serviços de TI; 

• Informação sobre o acumulo de trabalho (incidentes não atendidos); 

• Número de incidentes atendidos, sem a confirmação do usuário; 

• Informação sobre atrasos ocorridos na execução do atendimento dos incidentes, 

detalhando a causa e a solução implementada. 

2.6.1.8 Dificuldades Previstas 

A implementação dos processos baseados nas melhores práticas reunidas na ITIL depende 

da mudança proposta e incorporada pela área de TI. Portanto, é necessário focar em alguns itens 

fundamentais para o sucesso da iniciativa (MAGALHÃES E PINHEIRO, 2010); 

• Clareza em relação a necessidades do negócio; 

• Alocação de recursos com conhecimento suficiente e perfil adequado para 

desempenhar tais tarefas; 

• Motivação e comprometimento da equipe de suporte; 

• Definição detalhada dos objetivos e responsabilidades; 

• Disponibilização de ferramenta que automatize o processo. 

2.6.1.9 Avaliação de Performance 

ARRUDA (2010) sugere alguns indicadores de performance, para avaliar o processo: 

• Número total de incidentes (segmentar por área de negócio); 

• Tempo médio para reparo; 

• Incidentes resolvidos por nível de serviço; 

• Redução do tempo médio de solução; 

40

• Incidentes resolvidos com a Base de Conhecimento (incidentes conhecidos e erros 

conhecidos). 

2.6.2 Gerenciamento de Problema 

Todos os dias, vários chamados são feitos para a área de TI solucionar problemas em 

sistemas ou sobre o mau funcionamento de hardware e softwares proprietários, o que acaba 

sobrecarregando a equipe de suporte e por vezes, até gerando gargalo na área. Por isso, é possível 

que muito dos problemas sejam tratados de forma provisória, fazendo com que o sistema seja 

restabelecido o mais rápido possível, para evitar a pressão dos usuários (OGC, 2010). 

A partir da solução provisória, a área de suporte assume o risco de reincidência, alocando 

novamente recursos e tempo da equipe de suporte para solução. Como a equipe de suporte quase 

nunca tem tempo, o incidente acaba sendo “varrido para baixo do tapete”. 

Para solucionar esse problema, é usado o processo de Gerenciamento de Incidentes, onde 

as causas não identificadas (desconsiderando os erros conhecidos) estarão catalogadas, 

permitindo uma análise e posterior correção, para que o incidente não torne a acontecer. Para 

facilitar o entendimento, pode-se considerar que um incidente tenha causa e efeito. A causa é o 

que motiva o erro e o efeito é o sintoma. Quando somente o efeito de um incidente é tratado, 

denomina-se solução de contorno (responsabilidade do gerenciamento de incidentes) e quando a 

causa é tratada, denomina-se solução definitiva (ARRUDA. 2010). 

Ter o alinhamento entre o Gerenciamento de Problema e Gerenciamento de Mudança é 

muito importante, pois a partir da descoberta da solução definitiva é feita uma análise dos riscos 

sobre o serviço, antecedendo a implementação da mudança. A análise dos riscos antes da 

implementação da solução do problema previne que outros incidentes possam surgir, causando 

um impacto ao usuário que sofrerá com a indisponibilidade de algum serviço. 

2.6.2.1 Objetivo 

Foram identificados por Arruda (2010), os objetivos principais do processo de 

Gerenciamento de Problemas. São eles: 

41

• Reduzir os problemas e incidentes com erros conhecidos de modo que não impacte 

sobre o negócio; 

• Tratar pro ativamente os problemas e incidentes, de forma que não sejam 

recorrentes; 

• Reduzir o número geral de incidentes; 

2.6.2.2 Exemplo de Aplicação 

De maneira bem detalhada e clara, Magalhães e Pinheiro (2010) exemplificam o 

Gerenciamento de Problema, baseado em fatos ocorridos em uma empresa de grande porte: 

- Existe um problema em um serviço de TI que causa 50 incidentes por semana; 

- O tempo médio para solução desses incidentes é de 30 minutos; 

- Isso quer dizer que: 

• A equipe de suporte gasta 25 horas semanais para atender aos incidentes decorrentes 

de um problema não resolvido; 

• 50 vezes por semana há um usuário que é afetado por um dos incidentes; 

• Provavelmente, durante a solução do problema o usuário vai tomar café, tendo um 

gasto adicional de 15 minutos; 

• 50 vezes por semana o usuário perde em torno de 45 minutos de produtividade; 

• 38 horas por semana de falta de produtividade impactam o negócio, devido aos 

efeitos de um problema com causa não identificada. 

Dessa forma, podemos considerar que a empresa precisa de um funcionário extra para 

manter a produtividade, supondo que a mesma tenha jornada de trabalho de 40 horas semanais. 


A partir da relação entre incidentes, problemas e erros conhecidos, é feita uma análise com 

o intuito de identificar a “causa raiz” do problema. Para todo o incidente sem solução definitiva é 

emitido um aviso para a área de gerenciamento de problemas. De acordo com o impacto e 

42

importância do serviço afetado, é criado um novo registro de problema, na tentativa de evitar que 

o problema seja reincidente (ARRUDA, 2010). 

Figura 2.10 – Entradas e saídas principais do processo (ARRUDA, 2010). 

Ao contrário do gerenciamento de incidentes, cujo objetivo é restabelecer o serviço da 

maneira mais rápida possível, o objetivo do gerenciamento de problemas é evitar que incidentes 

reincidam sobre o negócio. 

2.6.2.4 Ciclo de Vida 

Um problema poderá ser registrado por qualquer membro da equipe de TI. O problema 

poderá ser identificado pela central de atendimento devido à reincidência do mesmo, ou pela área 

especialista (inclui gerência), que avaliou que o incidente pode ter um alto impacto sobre o 

negócio. 

Quando a causa do problema é identificada, altera-se o status para “Resolvido” e é feito o 

registro do que foi feito para solucionar o mesmo. Se a solução do problema não é atingida, é 

cancelado o registro do problema. 

43

Após o responsável identificar a solução do problema, é feita uma análise sobre esse item 

de configuração. Se após análise ficar evidenciado que o problema não foi solucionado, o status é 

alterado para “Rejeitado” e o processo é direcionado ao início do ciclo de vida. Identificada a 

solução após a análise, o status do chamado é alterado para “Fechado”. A imagem 4.5 representa 

o diagrama do ciclo de vida (MAGALHÃES E PINHEIRO, 2010). 

Figura 2.11 – Ciclo de vida de um problema (MAGALHÃES E PINHEIRO, 2010). 

2.6.2.5 Método para Solução de Problema 

Quando um problema é identificado, deve-se primeiramente encontrar a “causa raiz”, para 

em seguida tratá-lo de tal forma que o mesmo seja eliminado. O livro de Operação de Serviços 

indica algumas ferramentas da área de gestão da qualidade para identificar a “causa raiz” dos 

problemas (ITIL, 2007). 

2.6.2.5.1 Diagrama de Ishikawa 

Essa ferramenta foi criada em 1943 pelo engenheiro químico Kaoru Ishikawa, conforme 

exemplo da imagem 4.6, também é conhecida como “Diagrama de Causa e Efeito”, “Espinha de 

Peixe” e “Diagrama 6M”. Ela é utilizada para determinar as causas do problema. Segundo Rigoni 

44

(2009), Ishikawa propôs uma divisão baseada em 6M’s, ou seja, as causas do problema podem 

ser originadas da mão de obra, material, meio ambiente, método, máquina e medida. Para cada 

um dos ambientes dos 6M’s é feito um Brainstorming de causas possíveis, até a identificação da 

“causa raiz” (RIGONI, 2009). 

Figura 2.12 – Exemplo (com 5M’s) do diagrama de Ishikawa (RIGONI, 2009). 

2.6.2.5.2 Análise de Krepner e Tregoe 

Foi desenvolvido na década de 50 por Charles Kepner e Benjamin Tregoe. Da análise 

compõem-se três processos (RIGONI, 2009): 

• Análise do problema (identificação da causa do problema); 

• Análise da Decisão (escolha de uma solução para o problema); 

• Análise de Problema Potencial (planejamento da implantação da solução); 


Da mesma forma que ocorre em todos os processos da área de TI, o Gerenciamento de 

Problemas precisa de um acompanhamento da gerência. Os relatórios servem para a gerência 

45

avaliar a equipe e também para direcionar a atuação da equipe em relação aos impactos e 

severidade de algum problema, bem como uma nova estrutura na definição dos níveis de suporte. 

São indicados alguns itens que auxiliam na gestão (MAGALHÃES E PINHEIRO, 2010): 

• Quantidade de atendimentos total e segmentado por serviço, impacto e status; 

• Comparar a demanda com meses anteriores; 

• Soluções proativas x reativas; 

• Incidentes atendidos por problema solucionado; 

• Indicador de custo/mês e custo por problema; 

• Indicador individual da equipe; 

• Problemas não atendidos; 

• Taxa de conversão (problemas solucionados x problemas gerados). 

2.6.2.7 Dificuldade Prevista 

O Gerenciamento de Problemas tem uma relação diretamente ligada ao Gerenciamento de 

Mudanças e ao Gerenciamento de Incidentes. Esse relacionamento é fundamental para o sucesso, 

mas alguns fatores também são importantes (ARRUDA, 2010 e MAGALHÃES E PINHEIRO, 

2010): 

• Ter uma equipe treinada e capacitada para solucionar os problemas; 

• Alimentar sempre que necessário o BDEC; 

• Avaliar corretamente o impacto do problema sobre o negócio; 

• Garantir que a informação originada dos incidentes seja completa e de qualidade. 

2.6.3 Gerenciamento de Mudança 

Mudança é o processo de mover-se de um estado definido a outro (MENDES, 2011). 

Como qualquer coisa da vida, mais cedo ou mais tarde será necessária uma mudança. Para 

os sistemas de informação e tecnologias então, é necessário ter um fluxo de mudanças que 

atendam as novas tendências. No gerenciamento de mudanças de ITIL está programado um 

46

tempo considerável, para que as mudanças passem pelos seguintes processos (CLEMENTI, 

2006): 

• Análise e estimativa sobre o impacto que a mudança pode causar no negócio; 

• A partir dos problemas identificados, estabelecer mudanças para solucioná-los; 

• Inovações tecnológicas e ideias que beneficiem o negócio também geram 

mudanças. 

Tais medidas são necessárias devido ao nível de criticidade da área de TI sobre as 

operações, originadas da importância da área dentro do negócio. Motivada pela evolução do 

negócio, cabe a TI acompanhar a tendência, melhorando a capacidade dos serviços, 

implementando melhorias nos sistemas e atualizando as políticas de segurança. 

Segundo uma pesquisa do Instituto Gartner, 80% dos problemas de indisponibilidade dos 

serviços de TI foram ocasionados devido a falhas de procedimento, ingerência sobre mudanças e 

sistemas ou atualizações mal testadas, que resultavam em uma sobrecarga nos servidores. O 

gerenciamento de mudanças proposto por ITIL sugere que antes de trabalhar para solucionar o 

problema, o mesmo seja analisado e testado, para então ser implementado no ambiente de 

produção (ARRUDA, 2010). 

2.6.3.1 Objetivos 

Este processo tem como objetivo controlar todas as mudanças, na tentativa de minimizar 

os impactos negativos sobe o negócio. Para isso, visa canalizar a aprovação e acompanhamento 

da mudança, garantindo que a área de TI e os serviços mantenham o alinhamento com os 

requisitos do negócio. 

Para Arruda (2010), podemos separar os objetivos deste processo nos seguintes itens: 

• Assegurar que os métodos padronizados estão sendo usados para o tratamento 

eficiente de todas as mudanças, reduzindo seus riscos e impactos; 

• Minimizar incidentes relacionados com as mudanças; 

47


• Balanço entre necessidade e impacto; 

Ao contrário do que se imagina, este processo não é responsável pela implementação ou 

execução das mudanças. Cabe ao processo, somente a decisão e o gerenciamento das mudanças, 

para que a implantação tenha a eficiência e eficácia necessária, sem correr riscos ou traumas por 

uma implantação mal planejada. A execução e implementação serão de responsabilidade da 

equipe técnica da área. 

mudanças: 

É proposta por Magalhães e Pinheiro (2010), uma proposta para tratamento de 3 tipos de 

• Mudança padrão: Deve ser documentada, mas não apresenta risco para a área de 

TI. Pode-se exemplificar a atualização de hardware e software na estação de 

trabalho, a configuração de firewall e alteração no banco de dados. 

• Mudança normal: Destinada a projetos que alterem a infraestrutura de TI. Esse tipo 

de mudança pode ter um impacto sobre os serviços disponíveis ao usuário. Como 

exemplo, podemos utilizar a atualização da versão de algum sistema. 

• Mudança emergencial: É uma mudança já prevista, mas devido à severidade e 

2.6.3.3 Benefício Proposto 

impacto, necessita ser implementada em caráter de urgência. Um exemplo é 

alguma alteração da legislação, onde a não implantação pode acarretar em multa. 

A vantagem mais evidente sobre o Gerenciamento de Mudanças é a facilidade de fazer 

mudanças de maneira organizada, minimizando os impactos negativos sobre o negócio e evitando 

que incidentes sejam originados da mesma. 

Os principais benefícios do Gerenciamento de Mudanças são (ARRUDA, 2010): 

• Melhor alinhamento dos serviços de TI com o negócio; 

• Aumento da visibilidade dentro da mudança. Têm-se um controle maior sobre a 

execução; 

48

• Redução de impacto negativo da mudança; 

• Melhor avaliação do custo da mudança 

• Habilidade para absorver um volume maior de mudanças. 


Para avaliar o gerenciamento de mudanças, devem ser colocados a disposição alguns 

relatórios que transpareçam as atividades desempenhadas pela área. Magalhães e Pinheiro (2010) 

indicam uma análise sobre o monitoramento do progresso das mudanças, auditorias de 

atendimento e um planejamento das atividades futuras. E ainda propõem uma estrutura para o 

relatório, que pode ser customizada de acordo com a necessidade de cada negócio, tendo os 

seguintes itens: 

• Volume de mudanças realizadas; 

• Distribuição das mudanças por área usuária; 

• Informação sobre o crescimento da demanda; 

• Identificação da satisfação dos usuários com as mudanças; 

• Informação sobre a quantidade de mudanças implementadas, separadas por tipo de 

mudanças (padrão, normal e emergencial); 

• Mudanças pendentes para implementação; 

• Quantidade de mudanças solicitadas e consideradas inviáveis. 

2.6.3.5 Dificuldades Previstas 

Apesar dos benefícios evidentes, também existem problemas que precisam ser 

enfrentados. A burocracia necessária, mesmo em mudanças simples, aliada a falta de treinamento 

da equipe e a falta de autoridade do responsável pelo processo podem afetar a credibilidade e 

incentivar o uso incorreto dos serviços, onde é mais fácil “burlar” o sistema, do que aguardar uma 

alteração no mesmo (MAGALHÃES E PINHEIRO, 2010). 

Dentre outros problemas, Arruda (2010) citou: 

• Falta de informação para análise de risco; 

49

• Falta de ferramenta integrada aos demais processos. 

• Falta de comprometimento da equipe. Se não houver o entendimento dos 

benefícios do processo, pode ocorrer um boicote da área por achar muito 

burocrático. 

• Priorização de todas as mudanças. Para toda a mudança deve haver uma análise de 

impacto sobre o negócio, para que sejam definidas as prioridades. 

2.7 Ferramentas para Desenvolvimento 

2.7.1 Scriptcase 

Para o desenvolvimento do sistema, será utilizada uma ferramenta case chamada 

Scriptcase. Essa ferramenta visa auxiliar o desenvolvimento e maximizar a produtividade da 

equipe de desenvolvimento. O fabricante define o Scriptcase como um ambiente de 

desenvolvimento de aplicações WEB (consultas, relatórios, formulários e menus), baseado em 

banco de dados. A facilidade de manuseio, rapidez na criação de aplicações e inúmeros recursos 

de programação são características diferenciais do Scriptcase. 

O funcionamento do Scriptcase está condicionado a um servidor web e pode ser acessado 

via internet/ intranet, sendo a portabilidade outro diferencial. O único requisito para utilização da 

ferramenta é o conhecimento básico de SQL, mas quanto mais conhecimento em SQL, PHP e 

Javascript, mais pode-se explorar a ferramenta. 

Como resultado do desenvolvimento, o Scriptcase gera os programas fontes em PHP, 

Javascript, HTML e AJAX. Os fontes gerados são completamente independentes da ferramenta, 

permitindo com que sejam copiados para qualquer servidor WEB. Por ser gratuito, o PHP pode 

ser utilizado nos ambientes Windows e Linux. (http://www.scriptcase.com.br) 

2.7.2 Mysql 

O MySQL será o sistema de gerenciamento de banco de dados. Atualmente o MySQL está 

na versão 5.5 e é mantido pela Oracle. Ele é um banco de dados relacional e de distribuição 

gratuita, sendo uma boa opção em relação ao custo/ benefício. (http://www.mysql.com) 

50

2.7.3 FusionCharts 

A ferramenta para exibir gráficos indicadores é a FusionCharts. Essa ferramenta está na 

sua terceira versão e tem uma versão light gratuita. A partir de dados formatados em XML ou 

JSON, a ferramenta monta os gráficos e os exibe utilizando javascript e Flash. 

(http://www.fusioncharts.com/free) 

51

3 MODELAGEM DO SISTEMA PROPOSTO 

3.1 Domínio do Sistema 

O sistema de chamados tem como foco, a partir de uma metodologia de centralização de 

suporte, documentar todos os contatos feitos pelos usuários e auxiliar a central no atendimento 

em primeiro nível de suporte. Sua implantação será sustentada nas melhores práticas de ITIL, 

com ênfase no gerenciamento de problemas, gerenciamento de incidentes e no gerenciamento de 

mudanças. 

3.2 Descrição dos Objetivos 

O sistema de chamados visa documentar as requisições e notificações de problemas por 

parte dos usuários. A partir de uma intranet local e, munido do seu crachá, o funcionário pode 

acessar o sistema utilizando qualquer computador da empresa e informar algum problema nos 

serviços de TI, ou requisitar algum serviço. 

Caso o chamado seja uma solicitação de serviço, a central avalia a necessidade de 

encaminhar para aprovação do gerente, havendo a possibilidade do gerente aprovar ou não a 

solicitação. A central também pode recusar alguma solicitação, quando a mesma não atende as 

regras de negócio. A solicitação pode ser atendida pela central ou pela equipe técnica. 

Outra possibilidade é a notificação de um incidente. O usuário descreve o problema e a 

central verifica se já existe alguma solução de contorno, onde se consegue devolver a 

operabilidade do serviço de forma rápida. Também, pode-se pressupor que uma restrição do 

hardware/ software seja a origem do incidente. Dessa forma, a central pode acessar a base de 

52

erros conhecidos e verificar se existe uma forma para retornar a operabilidade do serviço que foi 

atingido. 

Prevendo a incapacidade de solucionar tal incidente, a central pode encaminhar o chamado 

para a área técnica (2º nível de atendimento). O técnico verifica o chamado e avalia se aceita ou 

recusa (normalmente, quando outro técnico é responsável pelo sistema). Avaliando os acordos de 

nível de serviço e impacto sobre o negócio, cabe ao técnico avaliar se vai dar uma solução de 

contorno (disponibilizando o serviço novamente, mas sem solucionar o incidente), ou se 

transforma o incidente em problema e soluciona definitivamente o problema (podendo referenciar 

outros incidentes com a mesma causa). 

Após a solução do chamado (seja solução de contorno ou definitiva), é enviado um aviso 

ao usuário afetado, informando sobre a regularização do serviço. Também cabe aos supervisores 

da área avaliar os chamados e identificar melhorias e soluções para incidentes frequentes e sem 

solução definitiva (encerrados como solução de contorno). Desta forma, emite-se uma solicitação 

de mudança. 

Na solicitação de mudança é levado em consideração o impacto que a mudança pode ter 

sobre o negócio. Nas mudanças de alto impacto, são realizadas algumas reuniões de análise 

crítica, onde é avaliada a forma como a mudança será implantada e se ela irá atender a 

necessidade. Também é avaliada a necessidade de apoio externo de especialistas. Com isso, são 

feitas reuniões para levantamentos de requisitos e aprovação do projeto/orçamento. Para 

mudanças mais simples, onde o impacto sobre o negócio é baixo. O especialista avalia a mudança 

e apresenta ao responsável, que aprova ou sugere mudanças para sua implantação. 

O sistema tem como objetivo registrar as mudanças, avaliar a capacidade da equipe 

técnica e principalmente, o foco na melhoria contínua em seus serviços. Para haver harmonia 

entre os objetivos, cabe aos supervisores avaliarem as estatísticas e relatórios gerenciais. Muitas 

melhorias podem ser identificadas a partir da análise dos relatórios do sistema, cabe aos 

responsáveis aproveitá-los da melhor forma possível. 

3.3 Lista de Requisitos 

1- Cadastro das áreas de suporte 

53

2- Definição da central de atendimento 

3- Cadastro detalhado dos serviços prestados 

4- Abertura do chamado 

5- Central define fluxo (solicitação, incidente) 

6- Alimentar base de Erros Conhecidos 

7- Alimentar base de Incidentes conhecidos 

8- Central define atendimento em 2º nível 

9- Técnico altera status do chamado de incidente para problema 

10- Encerra chamado e envia feedback para usuário 

11- Emissão de solicitação de mudança 

12- Supervisor aprova projeto e prazo de mudança 

13- Relação de mudanças 

14- Incidentes/Problemas atendidos na mudança 

15- Relação de incidentes emitidos 

16- Relação de incidentes por área 

17- Relação de incidentes solucionados em 1º nível e 2º nível 

18- Relação de problemas 

19- Relação de mudança 

20- Relação do impacto causado nos incidentes/problemas 

21- Relação de solicitações/incidentes/problemas 

3.4 Local do Sistema 

O sistema será implantado na empresa Bruning Tecnometal SA, situado na rua 25 de 

Julho, Bairro Jaciandi, Panambi, RS. 

O responsável pelo sistema será o senhor Leandro Castoldi Lopez, tendo como contato 

telefônico nº: 55-3376-9000, ramal:9406 e e-mail Leandro@bruning.com.br, nos turnos manhã e 

tarde de segunda-feira à sexta-feira. 

54

3.5 Processo de Software 

O processo utilizado para o desenvolvimento do sistema é o ciclo evolutivo, dessa forma 

pode-se desenvolver com rapidez e controlar versões. A implantação será no modelo cascata, 

pois se pretende aproveitar a base de dados antiga e a implantação paralela. 

3.5.1 Modelo Evolutivo 

Segundo ALCÂNTARA (2007), para o modelo evolutivo, o processo é analisado em dois 

períodos. O período de exploração e o período de desenvolvimento evolutivo. 

O período de exploração identifica os requisitos que o sistema é obrigado a atender. Nesse 

período são identificados os requisitos funcionais, o esboço dos objetivos da aplicação, o esboço 

da arquitetura e ambiente tecnológico; e é nesse período que é feito o planejamento da fase 

evolutiva. 

No período de desenvolvimento evolutivo, a construção das classes, responsáveis pela 

funcionalidade do sistema é o foco. O ciclo evolutivo formado nesse processo se beneficia da 

iteração de cada uma das fases. A fase de especificação é a fase de identificação das classes. A 

fase de projeto é a fase que define a arquitetura (das classes e associações). A fase de construção 

codifica a classe detalhadamente. A fase de teste verifica e valida à funcionalidade das classes e a 

generalização permite a reutilização e outras técnicas. 

3.5.2 Modelo Cascata 

A implantação do sistema será de forma paralela. Os dados atuais do sistema serão 

normalmente usados e os novos dados serão gradativamente incorporados, com o intuito de 

comparar os dados antigos com dados gerados na nova estrutura. Dessa forma será possível 

comparar se a nova metodologia se torna satisfatória, de acordo com a expectativa 

(ALCÂNTARA, 2007). 

55

3.6 Arquitetura do Sistema 

A arquitetura do sistema será web, ao qual estará disponível em uma intranet local e pode 

ser acessada por meio de qualquer computador presente na rede. O desenvolvimento será feito a 

partir da ferramenta case chamada ScriptCase que se encontra na versão 5.02. Tal ferramenta 

deve ser instalada em um servidor web que pode ser apache ou IIS e necessita de uma versão do 

PHP, Zend Optimizer e um banco de dados padrão SQL, sendo o MySQL 5.5 o modelo e versão 

selecionados. A ferramenta ScriptCase, após desenvolvimento gera arquivos php, javascript e 

html. 

3.7 Cenários 

Ao se deparar com alguma indisponibilidade de algum serviço, seja por falha ou por não 

ter autorização prévia, qualquer funcionário da empresa pode acessar o sistema de chamados e 

munido do crachá de identificação, requisitar algum serviço, ou notificar uma falha. Essa 

requisição ou notificação é definida como chamado e será canalizada para a central de 

atendimento, que a partir da definição da prioridade e impacto do chamado, avalia se tem 

condições de responder, ou se encaminha o mesmo para a equipe técnica, definida como segundo 

nível de atendimento. A central ou a equipe técnica resolvem o chamado e uma notificação, via 

sistema interno de comunicação (SIC), é enviada para o emitente do chamado. 

3.7.1 Cenários Primários 

• Cadastro da Central e da equipe de técnicos; 

• Usuário acessa o sistema através de um navegador web; 

• O usuário passa o crachá para acessar o sistema; 

• Os dados são checados e acesso é autorizado (nível de usuário ou técnico); 

• Técnico cadastra todas as áreas (db tipo) de serviços de TI. 

• Técnico cadastra de maneira discriminada (db especificação) os serviços de cada área. 

• Usuário emite chamado; 

• Central verifica se a requisição é compatível com os serviços de TI; 

• Central escala chamados entre solicitação e incidente; 

56

• Central encerra chamado; 

• Central seleciona especialista para o atendimento em 2º nível; 

• Técnico recebe o chamado (incidente) e avalia se responde ou recusa para a central; 

• Técnico altera status do chamado para problema; 

• Técnico encerra o chamado; 

• Central alimenta base de incidentes conhecidos (IC); 

• Central alimenta base de erros conhecidos (EC); 

• Técnico emite solicitação de mudança; 

• Supervisor aprova prazo e projeto; 

• Técnico encerra mudança; 

3.7.2 Cenários Secundários 

• Crachá não encontrado/ Tente novamente; 

• Não há chamados pendentes; 

• Sistema inoperante/ Tente novamente; 

• Banco de dados inoperante / Avisar administrador (DBA); 

• Técnico tenta excluir uma das áreas de atendimento com item discriminado relacionado / 

Excluir primeiramente todos os subitens; 

• Técnico tenta excluir uma das discriminações da área que já foi utilizada em outros 

chamados / Impossível excluir item; 

3.8 Listagem dos Casos de Uso 

1. Cadastro das áreas dos serviços prestados 

2. Cadastro do discriminado de cada área; 

3. Emissão do chamado; 

4. Central define status do problema (solicitação/ incidente); 

5. Análise do impacto e prioridade; 

6. Autorização da gerência; 

7. Cancelar chamado; 

57

8. Encaminhar incidente/ solicitação para área técnica; 

9. Recusar chamado para central; 

10. Exportar solução para base de incidentes conhecidos (IC); 

11. Exportar solução para base de erros conhecidos (EC); 

12. Técnico muda status de incidente para problema; 

13. Notificar usuário sobre chamado (recusado/ encerrado); 

14. Encerrar chamado; 

15. Emissão de mudança 

16. Relacionar incidentes/ problemas com mudanças; 

17. Responsável aprova prazo e projeto de mudança; 

18. Relação dos incidentes por técnico/central; 

19. Relação de solicitações por técnico/central; 

20. Relação de problemas por técnico/central; 

21. Relação de incidente por área; 

22. Relação de solicitações por área; 

23. Relação de problemas por área; 

24. Relação de Incidentes solucionados/ contornados; 

25. Relação de problemas relacionados a incidentes; 

26. Relação de incidentes/ problemas afetados por mudanças. 

3.9 Projeto Lógico das Tabelas do Sistema 

O SGBD utilizado é o Mysql. Por ser gratuito, torna-se uma boa opção custo x benefício. 

Abaixo será listado o projeto lógico das tabelas, alocadas na database service_desk. 

Os tipos de dados serão considerados na seguinte forma: Numérico, Alfanumérico, Data, 

Hora, Lógico, Texto e Arquivo. Será utilizado o InnoDB como padrão de armazenamento das 

tabelas. 

58

3.9.1 Nome externo: chamado 

Chave Atributo Tipo de dado Tamanho Observação 

@ id_chamado Numérico 10 Chave Primária 

conteudo Texto 

data Data 

hora Hora 

encaminhado Lógico 

registro Alfanumérico 20 

id_especificacao Numérico 10 Chave Estrangeira 

impacto Lógico 1 Chave Estrangeira 

urgencia Lógico 1 Chave Estrangeira 

anexo Alfanumérico 50 

Figura 3.1 - Tabela de abertura de chamado. 

3.9.2 Nome externo: chamado_mudança 


@ id_chamado Numérico 10 Chave Primária 

@ id_mudanca Numérico 10 Chave Estrangeira 

Figura 3.2 - Tabela de discriminação dos chamados afetados pela mudança 

3.9.3 Nome externo: ec_conhecido 


@ id_incidente Numérico 10 Chave Primária 

@ id_especificacao Numérico 10 Chave Estrangeira 

Figura 3.3 - Tabela de erros conhecidos. 

3.9.4 Nome externo: especificacao 


@ id_especificacao Numérico 10 Chave Primária 

descricao Alfanumérico 30 

id_tipo Numérico 10 Chave Estrangeira 

Figura 3.4 - Tabela discriminada dos serviços prestados pelo TI. 

59

3.9.5 Nome externo: ic_conhecido 



@ id_especificacao Numérico 10 Chave Estrangeira 

Figura 3.5 - Tabela de incidentes conhecidos. 

3.9.6 Nome externo: incidente 



id_chamado Numérico 10 Chave Estrangeira 

data_encaminhado Data 

hora_encaminhado Hora 

solucao Texto 

responsavel Alfanumérico 30 

data_encerra Data 

hora_encerra Hora 

texto_recusa Texto 

recusado Lógico 

contorno Lógico 

Figura 3.6 - Tabela de incidentes. 

3.9.7 Nome externo: incidente_problema 



@ id_problema Numérico 10 Chave Estrangeira 

Figura 3.7 - Tabela de discriminação dos incidentes transformados em problema. 

3.9.8 Nome externo: matriz_prioritaria 


@ impacto Alfanumérico 1 Chave Primária 

@ urgencia Alfanumérico 1 Chave Primária 

status Alfanumérico 1 

Figura 3.8 - Tabela do Acordo de Nível de serviço (ANS). 

60

3.9.9 Nome externo: mudanca 


@ id_mudanca Numérico 10 Chave Primária 


prazo Data 



descricao Texto 

anexo Alfanumérico 20 

aprovacao Alfanumérico 1 

data_aprovacao Data 

3.9.10 Nome externo: problema 

Figura 3.9 - Tabela de mudanças. 


@ id_problema Numérico 10 Chave Primária 




solucao Texto 





recusado Alfanumérico 1 

3.9.11 Nome externo: setor 

Figura 3.10 - Tabela de problemas. 


@ id_setor Numérico 10 Chave Primária 


Figura 3.11 - Tabela de setores. 

61

3.9.12 Nome externo: solicitacao 


@ id_solicitacao Numérico 10 Chave Primária 




solucao Texto 




aprova_gerente Alfanumérico 1 

data_gerente Data 

hora_gerente Hora 


recusado Alfanumérico 1 

3.9.13 Nome externo: tipo 

Figura 3.12 - Tabela de solicitação de serviço. 


@ id_tipo Numérico 10 Chave Primária 


3.9.14 Nome externo: user 

Figura 3.13 - Tabela da área de serviços de TI. 


@ registro Alfanumérico 20 Chave Primária 

id_setor Numérico 10 Chave Estrangeira 

nome Alfanumérico 50 

nivel Numérico 11 

central Alfanumérico 1 

Figura 3.14 - Tabela de usuários (equipe técnica) do sistema. 

62

3.9.15 Nome externo: responsavel_especificacao 


@ id_especificacao Numérico 10 Chave Primária 

@ Registro Alfanumérico 20 Chave Estrangeira 

Principal Alfanumérico 1 

3.10 Diagrama de Casos de Uso 

Figura 3.15 - Tabela de responsável por área de serviço. 

Neste item é feita a diagramalização da integração de todos os casos de uso. 

3.10.1 Caso de Uso 

Figura 3.16 – Diagrama de Caso de Uso do sistema de chamados. 

O Caso de Uso mostrado tem o objetivo de revelar o funcionamento do sistema proposto. 

Os momentos principais são a abertura de chamado e a emissão de mudança. Segue o 

detalhamento do diagrama. 

63

acesso); 

Atores 

- TI (composto pelos técnicos, central e gerente; estruturados de acordo com o nível de 

- Pessoa (qualquer funcionário presente na base de dados da empresa); 

- Central 

- Técnico 

- Gerente 

- Usuários 

Casos de Uso relacionados 

- Cadastrar área dos serviços; 

- Cadastrar serviços; 

- Cadastrar equipe de TI; 

- Definir responsáveis pelos serviços; 

- Alimentar EC (erros conhecidos); 

- Solucionar chamados; 

- Alimentar IC (incidentes conhecidos); 

- Regrar matriz prioritária; 

- Definir fluxo do chamado; 

- Definir impacto/urgência do chamado; 

- Encaminhar chamado para 2ª nível de atendimento; 

- Notificar conclusão do chamado; 

64

- Cancelar chamado; 

- Aprovar solicitação; 

- Recusar chamado; 

- Definir chamado como problema; 

- Abrir chamado; 

- Emitir Mudança; 

- Aprovar Mudança. 

Pré Condições 

- O login deve estar acessível; 

- Área e serviço devem estar cadastrados; 

- Regras da matriz prioritária devem estar definidas; 

Cenários primários 

- É feita a leitura do código de barras do crachá para acessar ao sistema; 

- A área de TI cadastra as áreas dos serviços disponibilizados pelo TI; 

- A área de TI cadastra todos os serviços prestados pelo TI; 

- A área de TI define os responsáveis (equipe de TI) pelos serviços; 

- O usuário abre um chamado para requisitar algum serviço ou informar sobre algum 

problema em um dos serviços; 

- Central cancela chamado; 

- Central recebe o chamado e define o fluxo do chamado; 

- Central destaca técnico para solucionar o chamado; 

65

- Técnico recusa chamado que retorna para central; 

- Técnico muda o status do chamado para problema; 

- Equipe de TI abastece a base de EC (erros conhecidos); 

- Equipe de TI abastece a base de IC (Incidentes conhecidos); 

- TI soluciona chamado; 

- TI emite mudança; 

- Gerente aprova mudança; 

- Usuário visualiza chamados (próprios) em aberto; 

- TI visualiza chamados em aberto; 

- TI visualiza chamados encerrados; 

Cenários secundários 

- Erro na leitura do crachá/ Passe o crachá novamente; 

- Não há chamados em aberto/ Desejas abrir novo chamado? 

- Central tenta cancelar chamado sem explicar/ É necessário preencher o motivo do 

cancelamento do chamado; 

do chamado; 

- Técnico tenta recusar chamado sem explicar/ É necessário preencher o motivo da recusa 

- TI tenta encerrar chamado sem preencher a solução/ É necessário preencher a solução do 

chamado para esclarecimentos ao usuário; 

- O sistema está inoperante/ Entre em contato com a Central de Atendimento; 

- O banco de dados está inoperante/ Entre em contato com a Central de Atendimento. 

66

3.11 Diagrama de Classe 

Figura 3.17 – Diagrama de Classe. 

67

3.12 Diagrama de Estado 

3.12.1.1 Diagrama de Estado da Abertura de Chamado 

Figura 3.18 – Diagrama de estado da abertura de chamado. 

68

3.12.2 Diagrama de Estado de Mudança 

Figura 3.19 – Diagrama de estado da Mudança. 

69

3.13 Relação de Programas a serem desenvolvidos 

Relação dos programas de entrada no sistema 

3.13.1 Programas de Cadastro: 

FrmUser – Cadastro de Usuários 

FrmArea – Cadastro das Áreas de Serviço 

FrmServico – Cadastro dos Serviço de TI 

FrmMudanca – Emissão de Mudança 

FrmChamado – Abertura de Chamado 

FrmIC – Incidentes Conhecidos 

FrmEC – Erros Conhecidos 

3.13.2 Programas de Consultas: 

GridIncidentes – Consulta de Incidentes em Aberto 

GridProblemas – Consulta de Problemas em Aberto 

GridSolicitacao – Consulta de Solicitações em Aberto 

GridMudanca – Consulta de Mudanças em Aberto 

GridIC – Consulta de Incidentes Conhecidos 

GridEC – Consulta de Erros Conhecidos 

SearchIncidentes – Consulta de Incidentes Concluídos 

SearchProblemas – Consulta de Problemas Concluídos 

SearchSolicitacao – Consulta de Solicitações Concluídos 

SearchMudanca – Consulta de Mudanças Concluídos 

3.13.3 Programas de Relatórios/ Indicadores: 

GraphIncidente – Indicador dos Incidentes 

GraphProblema – Indicador dos Problemas 

GraphSolicitacoes – Indicador das Solicitações 

70

GraphMudança – Indicador das Mudanças 

GraphNivel – Indicador dos níveis de Suporte 

GraphPrioridade – Indicador da Prioridade dos Chamados 

GraphChamados – Indicador Geral dos Chamados 

3.14 Projetos de Entrada (Cadastros) e Saídas (Relatórios) 

3.14.1 Tela de Login 

3.14.2 Tela de Abertura de Chamado 

Figura 3.20 – Tela de Login. 

Figura 3.21 – Abertura de Chamados 

71

3.14.3 Definição de Fluxo (Solicitação ou Incidente) 

Figura 3.22 – Definição do Fluxo do Chamado (Solicitação ou Incidente). 

3.14.4 Responsáveis pelos Serviços 

Figura 3.23 – Responsáveis pelo serviço. 

72

3.14.5 Matriz Prioritária 

Figura 3.24 – Matriz de Prioridades (Impacto x Urgência). 

73

4 RESULTADOS DA IMPLANTAÇÃO DA CE CENTRAL NTRAL DE ATENDIMENTO E 

SISTEMA DE CHAMADOS 

Com dois meses de utilização do sistema e considerando o primeiro mês, mês como operíodo 

de mudança de processo e implantação do sistema, serão apresentados os resultados de 

07/10/2011 e 07/11/2011. Preliminarmente, pode-se pode se dizer que os resultados obtidos foram 

satisfatórios, tendo em vista que a a implantação implantação é recente recente e a base de conhecimento conhecimento (erros 

conhecidos e incidentes conhecidos) ainda está sendo abastec abastecida. 

No No referido referido período período foram abertos abertos 1157 1157 (mil (mil cento e e ciquenta e e sete) sete) chamados, chamados, sendo 

estes divididos nas seguintes áreas. 

Figura 4.1 – Chamados Abertos no Período. 

74

Desse Desse total, 1125 1125 (mil cento e vinte e cinco) chamados foram encerrados nesse período. 

Aproximadamente 61% eram incidentes, 37% de solicitações, 0,5% de problemas e 

aproximadamente 1,5% do total foi recusado. Detalhes na figura abaixo (figura 4.2): 

Figura 4.2 – Chamados encerrados no período (por tipo). 

De todos os chamados encerrados encerrados, 49,5% % foram encerrados pela central de atendimento 

(primeiro nível), sobrando obrando 50, 50,5% para o atendimento em segundo nível (definido como técnicos). 

Conforme figura 4.3: 

Figura 4.3 – Nível de atendimento por chamado. 

75

No gráfico seguinte é mostrada a solução dos chamados e o nível de atendimento 

destinado. O quantitativo do gráfico está segmentado em solicitação, incidente e problema. Pelo 

tamanho dos pilares, pode-se notar que o número de atendimentos entre primeiro e segundo nível 

de suporte é próximo. Também pode-se deduzir que os problemas são resolvidos apenas pelo 

suporte em segundo nível. 

Figura 4.4 – Chamados por nível de suporte. 

Uma melhoria a ser feita no sistema, é em relação à definição da área e serviço 

selecionados no chamado. Conforme a imagem abaixo (Figura 4.5), dando sequência ao gráfico 

(Figura 4.1) onde a área selecionada é “Diversos”, mostra-se o seguinte gráfico: 

76

Figura 4.5 – Discriminação da área “Diversos”. 

O O indicador indicador “Outros” “Outros” do do gráfico gráfico denota denota a falha do processo em generalizar gene 

um serviço em 

uma área área que já tem conotação generalizada. generalizada. Dessa forma, selecionando a área “Diversos” “Diversos” e e o 

o 

serviço “Outros” torna inviável a análise de uma possível melhoria, até por que os 85 chamados 

(indiferente de solicitação ou incidente) podem ser diferentes, ou pior, estarem alocados 

erroneamente nessa área. A A solução solução para isso é instruir a central para para que que entregue o chamado 

chamado 

para o segundo nível da maneira mais completa e, também, instruir os técnicos para que 

trabalhem apenas com dados da maneira ma correta. 

Com os resultados obtidos até o momento, pode-se se afirmar que a central resolve, em 

primeiro nível, aproximadamente 50% 50% dos chamados, o que acarreta uma redução redução de de quase 50% 

para a área de suporte que poderá focar nas mudanças e desenvolvimento. to. 

77

CONSIDERAÇÕES FINAIS 

O ITIL surgiu a partir da necessidade de padronizar e melhorar os processos internos da 

área de TI, catalogando os contatos dos usuários com a área de suporte e, assim, favorecendo ao 

processo de melhoria contínua e aprendizado do TI. Também por isso, este modelo se tornou uma 

das melhores práticas de TI, porém sua aplicação não é obrigatoriamente total, podendo ser 

parcial, de acordo com a necessidade e negócio da empresa. 

Como a implantação de ITIL afeta a cultura da empresa e da TI, foi adotada uma postura 

mais cautelosa em sua implantação na Empresa Bruning Tecnometal SA. Optou-se pela versão 2, 

pois da mesma forma que Chiari (2010) pensa, a mesma é destinada a empresas que tem a área de 

TI alinhada ao negócio, diferente da versão 3 que se destina a empresas que tem a TI como 

negócio. Também para evitar que a mudança seja traumática, foi definido que a implantação de 

ITIL abrangeria duas mudanças. A primeira mudança seria relacionada a processos, com a 

implantação da central de atendimento, e a segunda mudança, um sistema de chamados, com o 

objetivo de catalogar todos os contatos e gerenciar incidentes, problemas, requisições e 

mudanças. 

Desconsiderando pequenas atitudes comportamentais, pode-se concluir que a implantação 

da central de atendimento e sistema de chamados foi extremamente satisfatória. Com pouco mais 

de dois meses de implantação, a central de atendimento está resolvendo em torno de 50% dos 

chamados. Estima-se que com o abastecimento da base de conhecimento, esse indicador pode 

subir para até 80%. Contudo, pode-se concluir que, mesmo em uma parcela inicial, ITIL pode se 

transformar em um diferencial estratégico para empresas que tem a TI como negócio. 

O sistema proposto foi concluído, mas aperfeiçoamentos e trabalhos futuros podem ser 

feitos. Como o sistema roda em uma intranet local e é acessado por máquinas restritas, não houve 

a preocupação em colocar segurança no banco de dados, para prevenir SQL Injection e nem em 

implementar o protocolo HTTPS para que a transmissão dos dados seja criptografada. 

78

Outro aspecto que pode ser melhorado, é a abrangência do sistema em relação ao ITIL. O 

sistema proposto está tratando apenas o gerenciamento de incidente, o gerenciamento de 

problema e o gerenciamento de mudança. Utilizando ferramentas profissionais em conjunto com 

o sistema, pode-se abranger o gerenciamento de disponibilidade e após ter um plano de negócio 

bem estabelecido, pode-se implantar o gerenciamento de configuração. 

Também, com a maturidade do sistema e com a aderência total da equipe de TI, é possível 

estipular prazos para conclusão do chamado. A partir do histórico dos chamados e tendo como 

auxílio a base de conhecimento, somando-se à matriz prioritária é bem possível dar ao usuário 

uma estimativa para a solução do seu problema. 

E, por fim, com a evolução da tecnologia e o constante aprimoramento dos processos, 

novas soluções devem surgir para ajudar a melhorar a qualidade dos serviços prestados pelo TI. 

79

BIBLIOGRAFIA 

MAGALHÃES, Ivan L.; PINHEIRO, Walfrido B. Gerenciamento de Serviços de TI na 

Prática. São Paulo. Editora Novatec, 2010. 

Best Manager Pratice. OGC Official Site. Londres – Inglaterra. Disponível em: 

http://www.best-management-practice.com, 2011. 

KAPLAN, Robert S.; NORTON, David P. A Estratégia em ação: Balanced Scorecard, 

4ª Edição. Rio de Janeiro. Editora Campus, 1997. 344p. 

ITIL. Official ITIL® Website. Disponível em: http://www.itil-officialsite.com, acessado 

em novembro de 2011. 

ROBINSON, Luis., ITIL v3 – O que é um serviço. Disponível em: 

http://www.robinson.luis.nom.br. 2011. 

ITSM. IT Service Manager. Reino Unido: ITSMF. Disponível em: 

http://www.itsmportal.com , 2011. 

CHIARI, Rene. Principais diferenças entre ITIL v2 e v3. ITIL® na Prática. Brasil. 

Disponível em http://www.itilnapratica.com.br . Abril, 2010. 

OGC. Office of Government Commerce - Service Operation. Londres – Inglaterra: 

Editora The Stationery Office (TSO), 2010. 

RIGONI, José R. G. Os Gurus da Qualidade – Kaoru Ishikawa. Disponível em: http:// 

http://www.totalqualidade.com.br, 2011. 

80

ARRUDA, Átilla. ITIL – Fundamentos em Gerenciamento de Serviços de TI. Brasil. 

Disponível em: http://www.atillaarruda.com.br/files/apostila_itil.doc, 2010. 

OLIVEIRA, Eurico H. de. ITIL v3 – É correto contornar Incidentes através de processos 

de Gerenciamento de Mudanças? Aghata Maxi Consulting – Serviços Gerenciados de 

Segurança e Governança de TI, Disponível em: http://aghatha.wordpress.com/2011/05/08/e- 

correto-contornar-incidentes-atraves-de-processos-de-gerenciamento-de-mudancas. 2011. 

MENDES, Gláucia M. P.. Gerenciamento de Mudança. Scribd em: 

http://www.scribd.com/doc/49651981/Gerenciamento-de-Mudanca , 2011. 

QUEIROZ, Helen. ITIL v3 – Nova estrutura do Modelo. Brasilia - Brasil. 2009. 

ALCÂNTARA, Romário L. Práticas de Modelagem Orientada a Objetos utilizando 

UML. Ijuí – Brasil. Unijuí, 2007. 

AURÉLIO. Minidicionário Aurélio da Língua Portuguesa. Rio de Janeiro. Editora 

Nova Fronteira, 2008. 

CLEMENTI, Sergio. ITIL - Gerenciamento de Mudanças. 2006. Disponível em: 

http://www3.fsa.br/LocalUser/gti/4 GTI Atividades ITIL/A06 ITIL Gerenciamento de 

Mudanças.pdf, acessado em novembro de 2011. 

81

UNIJUI - UNIVERSIDADE REGIONAL DO NOROESTE DO ... - Unijuí

Transforme seus PDFs em revista digital e aumente sua receita!

UNIJUI - UNIVERSIDADE REGIONAL DO NOROESTE DO ... - Unijuí

Transforme seus PDFs em revista digital e aumente sua receita!

Delete template?

Save as template ?