Gerenciamento de problemas à luz da ITIL v3: Implantando a gestão

Transcrição

Gerenciamento de problemas à luz da ITIL v3: Implantando a gestão
SERVIÇO NACIONAL DE APRENDIZAGEM COMERCIAL
Pós-Graduação Lato Sensu em Governança de Tecnologia da Informação
Rodrigo Tessarollo Neves
Gerenciamento de problemas à luz da ITIL v3:
Implantando a gestão por meio do software Open Ticket Request
System (OTRS)
Brasília-DF
2013
SERVIÇO NACIONAL DE APRENDIZAGEM COMERCIAL
Rodrigo Tessarollo Neves
Gerenciamento de problemas à luz da ITIL v3:
Implantando a gestão por meio do software Open Ticket Request
System (OTRS)
Trabalho de Conclusão de Curso
apresentado como requisito para a
obtenção do título de Especialista em
Governança de Tecnologia da Informação
ao Serviço Nacional de Aprendizagem
Comercial – SENAC, Unidade EAD –
SENAC/DF.
Orientador Prof. ME. Edilberto Magalhães Silva
Brasília-DF
2013
FICHA CATALOGRÁFICA
Neves, Rodrigo Tessarollo
Gerenciamento
de
problemas
e
incidentes:
Abordando
uma
ferramenta de apoio a gestão / Rodrigo Tessarollo Neves. – Brasília:
Rodrigo Tessarollo Neves, 2013.
Monografia (especialização) – SENAC – Serviço Nacional de
Aprendizagem Comercial. Centro Nacional de Educação a Distância, 2013.
Inclui Bibliografia.
1. ITIL v3. 2. Gerenciamento. 3. Problemas. 4. Incidentes.
I. Gerenciamento de problemas e incidentes: Abordando uma
ferramenta de apoio a gestão.
CDU666
Rodrigo Tessarollo Neves
Gerenciamento de problemas à luz da ITIL v3:
Implantando a gestão por meio do software Open Ticket Request
System (OTRS)
Projeto
apresentado
ao
Serviço
Nacional de Aprendizagem Comercial –
SENAC,
Distrito
Federal,
como
requisito parcial para obtenção do título
Aprovado1 em <xx de xxxxxxxxx de 201x>
BANCA EXAMINADORA
____________________________________________________
Prof. ME Edilberto Magalhães Silva
Tutor Orientador
____________________________________________________
<Prof.(a). Dr/ME/Esp (usar o maior título) Nome do 2o Membro da Banca >
Convidado
____________________________________________________
Prof.ª ME Alexandra Cristina Moreira Caetano
Coordenadora Pedagógica
1
Sua monografia será defendida perante uma banca composta por três avaliadores, os quais farão
uma arguição (duração de 20 minutos) após a sua defesa expositiva (duração de 20 minutos). Após a
arguição a banca emitirá um parecer pela aprovação ou não aprovação da sua monografia.
Dedico esse trabalho aos povos indígenas
esquimós que vivem ao Norte do Alaska,
e, pra variar, aos meus pais, pois são os
melhores e mais grandiosos que essa
galáxia já viu.
RESUMO
O mercado globalizado, a falta de recursos financeiros e as novas tecnologias
trouxeram necessidades de adequação entre a TI (Tecnologia da Informação) e o
negócio das empresas, para que estas continuem atuantes em seus mercados. Esse
ambiente instável fez com que as empresas começassem a buscar metodologias
que racionalizassem e controlassem seus processos, assim surgiram ITIL
(Information Technology Infrastructure Library), COBIT (Control Objectives for
Information and related Technology), CMMI (Capability Maturity Model Integration),
PMI (Project Management Institute), entre outros. A empresa estudada nesta
pesquisa também tem buscado melhorar seus processos através de boas práticas
de mercado, ainda mais por ser uma empresa pública. A Peixe Bola, nos últimos 2
anos começou a estudar e utilizar a metodologia ITIL, que se aplica ao
Gerenciamento dos Serviços de TI, mas que não é área fim da empresa. A
prestação de serviços na Peixe Bola hoje está baseada na experiência de poucos
anos no negócio e das iniciativas de melhorias dos processos, por isso já existem
algumas ferramentas alinhadas as boas práticas, como a Gerenciamento de
Incidentes, de Mudanças e de Configuração, porem necessitam melhorias, e para
isso estão sendo adequadas ao ITIL. Com o objetivo de continuar melhorando os
processos o próximo passo é tratar do Gerenciamento de Problemas, pois na
pesquisa ficou clara a ausência de procedimentos e ferramentas para tratar dos
problemas na empresa. Não existe uma diferenciação entre o que é um incidente e
um problema. Para conduzir a mesma foi utilizada uma metodologia de pesquisa
baseada em estudo de caso, onde se analisou a situação da empresa, sendo
criadas propostas de melhorias. A esta foi de cunho qualitativo, pois foi realizada
com um grupo restrito de pessoas em um setor específico. Ao final cumpriram-se os
objetivos específicos através do levantamento da situação atual, em seguida a
comparação entre o ambiente encontrado e as boas práticas de ITIL, por fim
apresentada as propostas de melhorias.
Palavras-chave: ITIL. Gerenciamento. Problemas. Incidentes. OTRS.
ABSTRACT
The globalized market, the lack of financial resources and new technologies brought
fitness needs between IT (Information Technology) and the business enterprises so
that they can continue operating in their markets. This unstable environment caused
companies to begin looking for methods to rationalize and control their processes,
thus came ITIL (Information Technology Infrastructure Library), COBIT (Control
Objectives for Information and related Technology), CMMI (Capability Maturity Model
Integration), PMI (Project Management Institute), among others. The company
studied in this research has also sought to improve their processes through good
market even more for being a public company. The company Peixe Bola, in the last
two years he began to study and use the ITIL methodology, which applies to the
management of IT services, but that is not the end of the business area. The
provision of services in company Peixe Bola is now based on the experience of a few
years in the business and process improvement initiatives, so there are already some
tools aligned best practices, such as Incident Management, Change and
Configuration, however need improvements, and for it being appropriate to ITIL. In
order to continue improving processes the next step is to address the management
issues, since the research was the lack of clear procedures and tools to address the
problems in the company. There is a distinction between what is an incident and a
problem. To drive it was used a research methodology based on case study, where
we analyzed the situation of the company, being created proposals for
improvements. The qualitative nature of this was because it was conducted with a
group of people in a specific sector. At the end fulfilled to the specific objectives by
assessing the current situation, then the comparison between the environment and
the best practices found in ITIL finally presented the proposed improvements.
Keywords: ITIL. Management. Problem. Incident. OTRS.
LISTA DE ILUSTRAÇÕES
Figura 1: Fluxograma representando um processo................................................... 20
Figura 2: Gerenciamento de serviços ....................................................................... 21
Figura 3: ITIL v3, volumes e processos..................................................................... 23
Figura 5: Processo de Gerenciamento de Problemas............................................... 26
Figura 6: Controle de problemas e erros................................................................... 28
Figura 7: Modelo DIKW ............................................................................................. 29
Figura 8: Ciclo de vida de um Ticket ......................................................................... 31
Figura 10: FAQ do OTRS.......................................................................................... 34
Figura 11: Divisão das fases da pesquisa................................................................. 36
Figura 12: Modelo de diagnóstico e resolução de problemas ................................... 48
Figura 13: Proposta de melhoria para o registro de incidentes na Peixe Bola.......... 50
Figura 14: Fluxo de proposta de relacionamento entre as ferramentas existentes e a
proposta para a ferramenta Gerenciamento de Problemas (OTRS) ......................... 52
Figura 15: Modelo de tratamento de Problemas, interligado Incidentes, Configuração
e Mudanças............................................................................................................... 54
Figura 17: Configuração inicial do OTRS.................................................................. 61
Figura 18: Tela de login do OTRS............................................................................. 62
Figura 19: Tela inicial do OTRS ................................................................................ 63
Figura 20: Exemplo de uma fila de atendimento e suas subclassificações............... 65
Figura 21: Detalhamento do chamado "Ticket#: 2013050840000029 – sem acesso a
servidores" ................................................................................................................ 67
Figura 22: Respondendo a o chamado " Ticket#: 2013050840000029 – sem acesso
a servidores " ............................................................................................................ 69
Figura 23: Formulário de fechamento do chamado................................................... 71
LISTA DE QUADROS
Quadro 1: Vantagens e desvantagens da utilização do ITIL..................................... 22
Quadro 2: Cronograma de Implementação ............................................................... 18
Quadro 3: Objetivos x As formas de obtenção.......................................................... 36
Quadro 4: Dados coletados dos problemas mais frequentes na primeira etapa ....... 40
Quadro 5: Total de atendimentos realizados no período........................................... 41
Quadro 6: Problemas identificados na amostra de atendimentos da equipe ............ 43
Quadro 7: Soluções identificadas para a amostra analisada na equipe de
conectividade ............................................................................................................ 44
Quadro 8: Diagnóstico e solução para problemas de “sem conectividade”............... 45
Quadro 9: Comparação entre o Gerenciamento de Problemas pelo ITIL e a PEIXE
BOLA......................................................................................................................... 49
Quadro 10: Comandos básicos para instalação do OTRS via console Linux ........... 60
Quadro 11: Primeira etapa das entrevistas ............................................................... 78
Quadro 12: Segunda etapa das entrevistas.............................................................. 79
SUMÁRIO
1
INTRODUÇÃO................................................................................................... 13
1.1 Formulação da situação problema (Questões de pesquisa) .............................. 14
1.2 Objetivos e escopo............................................................................................. 14
1.2.1 Objetivo Geral................................................................................................. 14
1.2.2 Objetivos Específicos ..................................................................................... 14
1.2.3 Escopo............................................................................................................ 14
1.3 Justificativa ........................................................................................................ 15
1.4 Hipóteses ........................................................................................................... 16
1.4.1 Hipótese sobre governança de TI na empresa Peixe Bola............................. 16
1.4.2 Hipótese sobre padronização dos processos de trabalho da TI, especialmente
a parte que toca o gerenciamento de problemas na empresa Peixe
Bola.....................................................................................................................
16
1.4.3 Hipótese sobre a implantação e customização de ferramenta para o apoio ao
gerenciamento de problemas, e o gerenciamento do conhecimento ........................ 16
2
METODOLOGIA................................................................................................ 17
2.1 Cronograma de Implementação......................................................................... 18
3
REVISÃO DE LITERATURA E FUNDAMENTOS ............................................. 19
3.1 A importância da TI e do seu alinhamento com a Organização......................... 19
3.2 Processos de TI ................................................................................................. 20
3.3 O gerenciamento de serviços e o ITIL ............................................................... 20
3.4 Os processos do ITIL ......................................................................................... 22
3.4.1 Gerenciamento de incidentes ......................................................................... 24
3.4.2 Gerenciamento de problemas ........................................................................ 24
3.5 Gerenciamento do conhecimento ...................................................................... 28
3.5.1 Visão geral sobre a gestão do conhecimento................................................. 28
3.6 Utilizando o OTRS para apoiar o gerenciamento de problemas e construir uma
base de conhecimento .............................................................................................. 30
3.6.1 O que é um Sistema de Bilhetes (Sistema de Tickets)?................................. 30
3.6.2 O que é o OTRS?........................................................................................... 32
3.6.3 OTRS como base de conhecimento............................................................... 34
4
ESTUDO DE CASO........................................................................................... 35
4.1 Sobre a organização .......................................................................................... 35
4.2 Metodologia de pesquisa ................................................................................... 35
4.2.1 Visão geral sobre a coleta de dados na organização ..................................... 37
4.3 Coleta dos dados na organização...................................................................... 37
4.3.1 Análise das entrevistas: Primeira etapa.......................................................... 38
4.3.2 Análise de documentos e relatórios................................................................ 41
4.3.3 O atual sistema de incidentes......................................................................... 42
4.3.4 Análise das entrevistas: Segunda etapa......................................................... 44
5
DISCUSSÃO...................................................................................................... 47
5.1 Critérios para interpretação dos achados do estudo de caso ............................ 47
5.1.1 Paralelo do modelo atual com as boas práticas do ITIL v3 ............................ 47
5.1.2 ITIL v3 aplicado à resolução de problemas na Peixe bola.............................. 47
5.2 Proposição da solução e aplicação de boas práticas ........................................ 49
5.2.1 Qualificação dos registros de incidentes ........................................................ 50
5.2.2 Proposta de alinhamento do Gerenciamento de Problemas à Peixe Bola
....................................................................................................................................51
5.2.3 Proposta de implantação do OTRS para auxiliar o Gerenciamento de
Problemas................................................................................................................. 58
6
CONCLUSÕES E TRABALHOS FUTUROS..................................................... 73
6.1 Conclusões ........................................................................................................ 73
6.2 Trabalhos Futuros.............................................................................................. 74
REFERÊNCIAS E FONTES CONSULTADAS ......................................................... 75
APÊNDICE A: PERGUNTAS APLICADAS NA PRIMEIRA E SEGUNDA ETAPA
DAS ENTREVISTAS................................................................................................. 78
13
1 INTRODUÇÃO
Com a constante evolução do mundo corporativo, é cada vez maior a procura
por técnicas e padronizações de mercado seguros e consolidados por organizações
de todos os portes. Conforme a tecnologia muda, o ambiente tende a se tornar
menos seguro e confiável, e isso faz as empresas buscarem alternativas tanto para
a padronização quanto para o controle de seus processos de negócio, com o foco
principal em reduzir o risco de problemas, ou até minimizar as suas consequências.
Uma verdade é certa: o mundo hoje é globalizado e a TI (Tecnologia da Informação)
é parte fundamental dessa globalização.
Com base nisso, é possível afirmar que a TI e parte fundamental de qualquer
organização moderna, e sendo assim, as empresas buscam meios de viabilizar
estratégias para alinhar os interesses da TI com os interesses do negócio. Para
alinhar esses interesses, as organizações vem adotando padrões de boas práticas
que estabelecem processos genéricos de como as coisas devem acontecer para
que a organização possa atingir um determinado nível de maturidade. Entre alguns
outros padrões de boas práticas, podem ser citados: ITIL (Information Technology
Infrastructure Library), COBIT (Control Objectives for Information and related
Technology), CMMI (Capability Maturity Model Integration) e outros, para que seja
possível atingir de forma padronizada e segura os objetivos da TI em relação ao
negócio.
Entre outros processos presentes no guia de boas práticas ITIL na versão 3,
existem dois processos fundamentais na implantação adequada da Governança de
TI em uma organização, são eles o Gerenciamento de Problemas e o
Gerenciamento do Conhecimento.
Com a aplicação desses dois processos, as organizações podem viabilizar
meios mais eficazes para a solução de anormalidades que podem acontecer dentro
do ambiente de trabalho, uma vez que todo o conhecimento adquirido no dia a dia
pode ser armazenado em uma base de conhecimento centralizada de forma
uniforme, permitindo assim um diagnóstico mais preciso sobre problemas, visando
facilitar a tomada de decisão sobre o que precisa ser feito para reestabelecer a
normalidade do ambiente.
Existem algumas ferramentas no mercado (sistemas de software) que podem
auxiliar no processo de centralização do conhecimento adquirido. O OTRS (Open
14
Ticket Request System) é uma dessas ferramentas, que por sua vez é famoso por
ter bastante adoção e aceitação no mercado. É uma ferramenta gratuita, segura e
confiável, é de fácil manuseio e a sua instalação também é considerada rápida é
simples.
Sendo assim, a pesquisa será voltada ao estudo atual do cenário da empresa
para a formulação de uma proposta de implantação do processo de gerenciamento
de problemas à luz do ITIL v3 e apoiado pelo uso do OTRS.
1.1
Formulação da situação problema (Questões de pesquisa)
Quais as vantagens em se implantar um processo padronizado, maduro e
seguro para o gerenciamento de problemas bem como o gerenciamento do
conhecimento em uma organização?
1.2
Objetivos e escopo
1.2.1 Objetivo Geral
Propor a implantação de um processo padronizado para a controlar, organizar
e classificar problemas afim de se construir uma base de conhecimento para ser
usada como referência para poder saná-los com rapidez e eficiência.
1.2.2 Objetivos Específicos
1. Analisar o cenário atual da área de infraestrutura para que se possa avaliar a
forma como os problemas são identificados e resolvidos;
2. Realizar um paralelo do processo de gerenciamento de problemas do cenário
atual em relação as melhores práticas sugeridas pelo ITIL v3;
3. Propor e customizar ferramenta de apoio para gestão dos processos de
gerenciamento de problemas e gerenciamento do conhecimento do ITIL de
acordo com as necessidades da organização Peixe Bola;
1.2.3 Escopo
O escopo desse trabalho restringe–se a análise do departamento de
infraestrutura de TI da empresa Peixe Bola afim de se compreender as deficiências
existentes e em seguida elaborar um plano de implantação de um processo
15
otimizado para o gerenciamento de problemas. O planejamento de implantação do
processo será baseado à luz do framework ITIL na versão 3.
Também como escopo desse trabalho, afim de atender ao processo de
gerenciamento do conhecimento, analisar a viabilidade da implantação de um
sistema para a centralizar os problemas e as suas soluções.
1.3
Justificativa
A Peixe Bola é uma empresa pública do Brasil criada em 2010 para gerir
outras empresas públicas federais. A empresa trabalha atendendo as empresas que
estão sob a sua gestão, a mesma está segmentada em setores, cada setor com
suas chefias. Um desses setores é o Setor de Tecnologia da Informação (STI), onde
está o Setor de Infraestrutura e Suporte (SIS) que será o tema dessa pesquisa.
Durante os seus anos de existência, o SIS (Setor de Infraestrutura e Suporte)
adquiriu conhecimento no atendimento e suporte aos seus clientes (Usuários dos
setores da empresa), que proporcionou uma considerável maturidade, ao ponto de
que pudessem criar as suas próprias metodologias e processos. Estas metodologias
foram se desenvolvendo e evoluindo conforme a necessidade, fazendo com que não
só coisas boas acontecessem. Logo o processo desenvolvido começou a apresentar
deficiências e redundâncias, por esse motivo em 2011 foi realizada uma
comparação com alguns dos processos e teorias de boas práticas defendidas pelo
ITIL para gestão de serviços.
Logo em seguida, depois da verificação realizada anteriormente, foram
implantados alguns processos do ITIL v3, como o gerenciamento de serviços,
gerenciamento de configuração, o gerenciamento de mudanças e o gerenciamento
de incidentes. Estes estão ajudando a aprimorar e racionalizar a prestação de
serviços da empresa.
Como sequência as implantações dos processos anteriores, surgiu a
necessidade de iniciar a análise para a implantação dos processos de
gerenciamento de problemas e o gerenciamento do conhecimento, afim de auxiliar
na filtragem, classificação e ordenação de informações para resolução rápida e
eficaz de problemas.
Para ajudar o processo de gerenciamento do conhecimento, o uso de uma
ferramenta de apoio para facilitar o armazenamento e centralização das informações
16
se faz necessário. Diante da necessidade, a implantação do sistema OTRS servirá
como base de apoio para a classificação, ordenação e filtragem dos problemas por
ele controlados (OTRS).
1.4
Hipóteses
1.4.1 Hipótese sobre governança de TI na empresa Peixe Bola
Faz–se necessário o aprimoramento dos controles para governança de TI da
empresa Peixe Bola para atingir os objetivos traçados em seu PDTI (Plano Diretor
de Tecnologia da Informação)
1.4.2 Hipótese sobre padronização dos processos de trabalho da TI,
especialmente a parte que toca o gerenciamento de problemas na
empresa Peixe Bola
É necessário o aprimoramento e padronização dos processos de trabalho,
visando a evolução de maturidade do processo de gerenciamento de problemas no
Setor de Infraestrutura e Suporte, a fim de agilizar os meios de solução?
1.4.3 Hipótese sobre a implantação e customização de ferramenta para o
apoio ao gerenciamento de problemas, bem como o gerenciamento do
conhecimento
É necessário a implantação de uma ferramenta que possa auxiliar e
centralizar o conhecimento a respeito do gerenciamento de problemas afim de
construir uma solida base de soluções para agilizar as respostas para a tomada de
decisão?
17
2 METODOLOGIA
Para execução desta monografia foi adotada a modalidade de pesquisa
exploratória adotando–se a:
•
Análise bibliográfica incluindo o material base das disciplinas do curso de
Governança de TI do SENAC, com vistas a fundamentar teoricamente
seu conteúdo;
•
Análise bibliográfica complementar acerca do assunto abordado;
•
Análise do framework ITIL v3 e guias de boas práticas relacionadas à
governança de TI;
•
Análise especifica sobre os processos do ITIL v3 que tratam sobre o
gerenciamento de problemas e o gerenciamento do conhecimento;
•
Estudo de implantação de um sistema de apoio ao gerenciamento de
incidentes e gerenciamento de problemas afim de construir uma sólida
base de conhecimento para abordar o processo de gerenciamento do
conhecimento;
•
Estudo com obtenção de dados no cenário e fluxo de processos atuais
executados no departamento de infraestrutura de TI da empresa Peixe
Bola em relação ao modo como se lidam com problemas e incidentes;
Para obtenção dos dados e sua análise foram realizadas as seguintes
atividades:
•
Levantamento de referencial teórico;
•
Leitura e sistematização do conteúdo;
•
Elaboração do conteúdo e forma de investigação do cenário;
•
Obtenção dos dados;
•
Análise dos resultados.
Para obtenção dos dados foram utilizadas as seguintes técnicas
•
Observação participante;
•
Observação sobre os problemas e incidentes reportados ao departamento
de infraestrutura;
•
Questionários
18
•
Observação das atividades desempenhadas para sanar os problemas e
incidentes;
•
2.1
Reuniões com os colaboradores do departamento de infraestrutura.
Cronograma de Implementação
Quadro 1: Cronograma de Implementação
Tarefa / Mês
JUN/13 JUL/13
Meta: Análise dos processos de gerenciamento de problemas e
gerenciamento de incidentes do ITIL na versão 3
Atividade: Analisar o guia de boas práticas, definir a
abordagem a ser seguida, referencial teórico.
X
Meta: Realizar a análise atual do setor de infraestrutura e
suporte sobre o gerenciamento de problemas e incidentes.
Atividade: Realizar uma reunião com o pessoal do
departamento
X
Meta: Realizar a análise atual do setor de infraestrutura e
suporte sobre o gerenciamento de problemas e incidentes.
Atividade: Elaborar questionários par ajudar a entender o fluxo
de trabalho atual
X
Meta: Realizar a análise atual do setor de infraestrutura e
suporte sobre o gerenciamento de problemas e incidentes.
Atividade: Analisar o processo atual para resolução de
problemas e incidentes
X
Meta: Elaborar proposta para implantação dos processos de
gerenciamento de problemas e a proposta de implantação do
OTRS
Atividade: Com base nos dados obtidos, elaborar a proposta
de implantação
Fonte: Próprio autor
X
19
3 REVISÃO DE LITERATURA E FUNDAMENTOS
3.1
A importância da TI e do seu alinhamento com a Organização
Por um longo tempo a TI foi considerada um apenas um recurso simples de
suporte à organização. Beal, (2001, p. 78) diz que “por muito tempo a TI foi
considerada um centro de custo que a princípio não gerava qualquer retorno para o
negócio”, O’Brien (2004, p. 39) fala que “a tecnologia não é mais uma questão
secundária na concepção da estratégia das empresas, mas sua verdadeira causa e
guia”, o que leva a entender que hoje a TI não deve ser vista apenas como
tecnologias eficazes que suportam as operações da empresa, ou a tomada de
decisões, ela pode mudar a forma de competir das mesmas, direcionando-as para
um foco mais estratégico e para processos de negócio, que objetivam a
sobrevivência por meio de reestruturações ou de reformulações, num mercado
dinâmico em que as empresas atuam (O’BRIEN, 2004).
A TI está enriquecendo todo o processo organizacional, auxiliando na
otimização das atividades, facilitando a comunicação e melhorando o processo
decisório, já que as informações são mais eficientes e eficazes e chegam ao gestor
com mais velocidade e precisão (BEAL, 2001), incentivando as empresas a
investirem em TI, uma vez que isso comprova que a mesma pode oferecer
vantagens competitivas para as organizações e, segundo Collingwood (2006),
podendo faze-las crescer sete pontos percentuais a mais que as demais empresas
que não utilizam tais recursos, mas para que isso funcione, é preciso estabelecer o
alinhamento estratégico da TI com o negócio, já que, segundo Fernandes e Abreu
(2006, p 35), o alinhamento estratégico é o “processo de transformar a estratégia de
negócio em estratégia e ações de TI que garantam que os objetivos de negócio
sejam apoiados”, pois é fundamental que os objetivos, estratégias e valores da
organização estejam claros e bem definidos. Também é importante possuir uma
estratégia própria, explícita e alinhada com a estratégia da organização, ter uma
postura de agente de mudança e por último conduzir a TI com eficácia, eficiência, de
forma flexível e integrada (FERNANDES E ABREU, 2006).
20
3.2
Processos de TI
Processos são atividades relacionadas logicamente e direcionadas para um
objeto definido e quando utilizado da forma correta é possível observar as atividades
que estão descoordenadas, duplicadas, esquecidas ou desnecessárias (INFORM-IT,
2007).
Figura 1: Fluxograma representando um processo
Fonte: metainsight.com.br
Santos e Laurindo (2005) descrevem que a TI e a gestão de processos
propiciam ganhos de produtividade, não são somente ferramentas gerenciais para
redução de custos, mas também podem ser considerados como diferenciação de
mercado, trazendo competitividade e agregando valor a seus produtos e serviços,
onde os processos devem definidos de forma clara e objetiva, sendo necessário
seguir a seguinte estrutura: primeiro definir o que há para fazer; em segundo lugar,
saber qual resultado é esperado; em terceiro, medir os resultados esperados; e em
quarto como os resultados do processo afetam os demais (INFORM-IT, 2007).
3.3
O gerenciamento de serviços e o ITIL
A crescente dependência das organizações pelas soluções de TI para
alcançar seus objetivos, trouxe a necessidade de serviços de TI, que respondessem
a qualidade exigida pelos objetivos de negócio, atendendo às exigências dos
clientes. Neste cenário, para atender a essas necessidades, os serviços devem ser
confiáveis, estáveis e de alta qualidade, a um preço aceitável, pois uma aplicação TI
21
somente irá contribuir para alcançar os objetivos corporativos quando estiver
disponível para seus usuários ( INFORM-IT, 2007).
Serviço é um termo que faz menção ao ato de se entregar um bem de
trabalho intangível, ou seja, sem existência física ao cliente e/ou usuário, que faz o
uso do mesmo. Serviço se difere de produto pois, apesar de ser também ser um
bem, pode ser tocado, ou seja, é tangível. Uma outra definição sobre a diferença
entre produto e serviço é que, diferentemente de produto, um serviço não pode ser
armazenado, ele pode sim, ser consumido no momento que é produzido. O valor de
um serviço pode ser medido pela a utilidade que proporciona ao seu consumidor,
sendo assim, um serviço vem a ser um meio de se entregar valor ao cliente/usuário,
facilitando o resultado que os clientes querem alcançar, sem ter que assumir custos
e riscos. (INFORM-IT, 2007).
O gerenciamento de serviços de TI é extremamente importante para o
sucesso da TI e também da organização, pois a maior parte da vida de uma
aplicação de TI está em sua operação e aproximadamente 20 a 30% no seu
desenvolvimento. Para caso de falhas do sistema ou de alguma mudança
necessária, a gestão de serviços de TI preocupa-se com a parte do suporte de
manutenção e operação (INFORM-IT, 2007). É um conjunto que une pessoas,
processos de negócio e tecnologia da informação, de modo que os três juntos
colaborem entre si assegurando a qualidade de serviços tratados com os clientes
por meio do acordo de nível de serviço.
Figura 2: Gerenciamento de serviços
Fonte: Próprio autor
22
Assim como outras abordagens, o ITIL também possui vantagens e
desvantagens em sua adoção. No Quadro 1 a seguir, é possível observar a relação
de vantagens e desvantagens:
Para a organização de TI
antagens na utilização de ITIL
Para o cliente
Quadro 2: Vantagens e desvantagens da utilização do ITIL
Desvantagens na utilização de ITIL
V
• Oferta de serviços e acordos de qualidade dos mesmos é orientada para o cliente;
• Descrição dos serviços mais detalhados e na linguagem do cliente;
• Gestão da qualidade, disponibilidade, confiabilidade e custos é mais eficiente e eficaz;
• Comunicação entre cliente e organização melhora devido a definição de pontos de
contato;
• Estrutura mais clara da organização, torna-se mais eficiente e focada nos objetivos
corporativos;
• Controle maior sobre a infraestrutura e serviços da organização, facilitando o
Gerenciamento de Mudanças;
• Maior facilidade de terceirização de elementos dos serviços de TI;
• Facilita a introdução de sistemas de gerenciamento de qualidade como a ISO 9000 e a
BS 15000, por causa da mudança cultural do fornecimento de serviços;
• Melhora a comunicação interna e externa, com fornecedores e a padronização e
identificação de procedimentos, através de um modelo coerente de referência;
• A sua introdução pode requerer muito tempo e um grande esforço da organização,
juntamente com a mudança cultural. Podendo os objetivos não serem atingidos, causando
uma frustração;
• Pensar na estrutura do processo como único objetivo pode causar obstáculos
burocráticos, surgindo procedimentos desnecessários ou enganosos;
• Falta de entendimento sobre que os processos relacionados devem oferecer, quais
indicadores de desempenho e como os processos devem ser devem ser controlados;
• Identificação errada de objetivos e insuficiência de dados de referência para
comparação, não atingindo os resultados esperados com os serviços oferecidos e
ineficientes na redução de custos;
• Deixar o desenvolvimento da estrutura de processo a cargo de um setor, sem a opinião
de outros setores, podendo não ser aceita pelos mesmos;
• Falta de investimento em treinamento e pessoal nas “melhores práticas”;
Fonte: OGC, 2007.
3.4
Os processos do ITIL
O ITIL na versão 3 possui 26 processos que são listados na edição 2011 da
ITIL. Abaixo estão listados qual a publicação principal que fornece o conteúdo
principal de cada processo, possui cinco edições, publicados em maio de 2007 e
atualizado em julho de 2011 (INFORM-IT, 2007).
23
•
Estratégia de Serviço (Service Strategy)
•
Desenho de Serviço (Service Design)
•
Transição de Serviço (Service Transition)
•
Operação de Serviço (Service Operations)
•
Melhoria de Continuidade de Serviço (Continual Service Improvement)
Figura 3: ITIL v3, volumes e processos
Fonte: ITSM
Como o foco dessa pesquisa é o gerenciamento de problemas e o
gerenciamento do conhecimento, a partir desse ponto, somente será abordado as
edições respectivas a esses processos em particular.
O processo de gerenciamento de problemas é abordado na edição Operação
de serviço (Service Operations) do ITIL. Já o processo de gerenciamento do
conhecimento, é abordado na edição Transição de Serviço (Service Transition).
Visando realizar um paralelo para a distinção entre o gerenciamento de
problemas e incidentes, a seguir é mostrada uma breve introdução sobre o
24
gerenciamento de incidentes, onde o principal objetivo é relacionar de forma clara
esses dois processos entre si nos próximos capítulos que seguem.
3.4.1 Gerenciamento de incidentes
De acordo com o ITIL, um incidente é um imprevisto que leva um serviço de
TI a parar de forma súbita ou comprometer a qualidade de funcionamento do
mesmo. Sendo assim, o gerenciamento de incidentes tem por função a pronta
restauração e normalização da operação dos Serviços de TI para diminuir o impacto
nos negócios da empresa e mantendo o nível de serviço contratado e também
avaliar um incidente para determinar se o mesmo pode ocorrer novamente ou se é
o sintoma de um problema. No caso desse último, acionando o responsável pelo
gerenciamento de problemas. (OGC, 2007).
3.4.2 Gerenciamento de problemas
O gerenciamento de problemas tem por objetivo minimizar e eliminar as
consequências dos incidentes e problemas de TI ao negócio da empresa e suas
causas-raízes. Esta por sua vez, utiliza-se das informações disponibilizadas pelo
gerenciamento de incidentes para reduzir os problemas e fazer com que eles não
voltem a ocorrer. O gerenciamento de problema pode tratar os problemas de forma
proativa ou reativa (INFORM-IT, 2007).
Em linhas gerais, o gerenciamento de problemas objetiva promover uma
maior qualidade nos serviços de TI, reduzir o número de incidentes, trazer soluções
permanentes, promover o desenvolvimento técnico organizacional e maior taxa de
resoluções no primeiro atendimento pelo Service Desk (OGC, 2007).
Em termos de definição formal, a funcionalidade do modelo proposto pelo ITIL
pode ser descrito da seguinte forma: um problema é uma causa desconhecida de
um ou mais incidentes, ou seja, quando é identificada uma frequente ocorrência de
incidentes referente ao mesmo sintoma, essa reincidência caracteriza um problema.
Já um erro conhecido é um problema que está suficientemente diagnosticado pelo
qual foi identificada sua causa raiz e uma alternativa de solução tenha sido
identificada. A figura 4 descreve as etapas contidas dentro do gerenciamento de
Incidentes e de problemas, iniciando com vários incidentes referentes a mesma
situação, caracterizando-se assim um problema, depois no gerenciamento de
problemas descobrindo a causa raiz do mesmo e na sequência surgindo o erro
conhecido (INFORM-IT, 2007).
25
Figura 4: A relação de incidentes com problemas
Fonte: Próprio autor
A figura 4 apresenta o processo padrão do gerenciamento de problema, que
caracterizam os tratamentos reativos de problemas que são concentrados em
resolvê-los em resposta a um ou mais incidentes. Já o gerenciamento de problemas
proativos, está concentrado na identificação e resolução de problemas e erros
conhecidos antes dos incidentes ocorrerem (INFORM-IT, 2007).
O processo de gerência de problemas recebe informações de diferentes
locais do modelo ITIL, realiza atividades de processamento com as mesmas e as
entrega para outros locais dentro do mesmo modelo. Na Figura 5, é possível
visualizar esse modelo (OGC, 2007):
26
Gestão de
Incidentes
Gestão de
Incidentes
CMDB
Soluções de
contorno do
problema
(Work-Arounds)
Atividades da GP
•Controle de Problemas
•Controle de erros
•Prevenção pro ativa de
problemas
•Identificação de
tendências
•Informações gerenciais
dos dados de GP
•Revisão dos problemas
principais
Erros
conhecidos
RFC
Atualização do
registros de
problemas
Registro de
problemas
encerrados
Informações
Gerenciais
Figura 5: Processo de Gerenciamento de Problemas
Fonte: Próprio autor
O gerenciamento de problemas objetiva em reduzir o número de incidentes
graves e os problemas que afetem o negócio da empresa, para cumprir esses itens
o mesmo tem por responsabilidade garantir que as informações referentes a estes
estejam documentadas e disponíveis para primeiro e segundo nível de atendimento.
Essa tarefa não é fácil, porém é necessária.
As informações devem estar organizadas de forma que possam ser
acessadas rapidamente, e seguidamente revisadas e atualizadas para não
perderem o seu valor. Os itens a serem considerados são tecnologia, soluções
externas existentes, conhecimentos técnicos adquiridos internamente, frequência e
impacto dos incidentes e a interpretação de boas práticas interna.
Também utilizar as informações para treinar e entender a profundidade e
poder da mesma, como acessá-las e interpretá-las. Por último, um repositório
adequado de informações, integrado a um utilitário de Gerenciamento de Serviços
que forneça informações provenientes do processo de manipulação de incidentes
(INFORM-IT, 2007).
Para identificar problemas e erros conhecidos, são utilizadas informações do
gerenciamento reativo de problema (análise dos incidentes e a forma que eles
27
ocorrem) e do gerenciamento pró ativo de problemas (observando diferentes
períodos de reincidências dos incidentes), da infraestrutura de TI e do provimento de
bases de conhecimentos. Também podem ser identificados por desenvolvedores e
vendedores quando um novo produto é lançado (INFORM-IT, 2007).
3.4.2.1 Controle de problemas
O processo de transformação de problemas em erros conhecidos chama-se
controle de problemas. Este por sua vez se preocupa em tratar os problemas de
forma eficiente e efetiva identificando as causas-raízes. As atividades do processo
de controle de problemas são a identificação e registro do problema, sua
classificação, levando em consideração a categorização, o impacto, a urgência, a
prioridade e definindo um status, na sequência a investigação e diagnósticos do
mesmo até a descoberta de sua causa raiz, surgindo assim o erro conhecido.
Depois o mesmo é enviado para o controle de erros, se o problema foi resolvido
poderá ser encerrado (INFORM-IT, 2007).
3.4.2.2 Controle de erros
Sequencialmente, depois de conhecido o erro, surge o processo de Controle
de erros. Este foca em tratar e eliminar os erros conhecidos até que surja um roteiro
de alterações e aberta uma requisição de mudanças (RDM), que será tratado pelo
processo de gerenciamento de mudanças. O objetivo do Controle de erros é
apresentar os erros, monitorando-os e eliminando-os quando for praticável e de
custo justificável (INFORM-IT, 2007).
As atividades realizadas pelo controle de erro são a identificação e registro
erro, avaliação do erro (identificando os prós e contras da correção do erro), o
registro de soluções (investigação de soluções, preparação para criação de uma
RDM), encerramento de erro e monitoramento e progresso nas resoluções de erro
(INFORM-IT, 2007).
A Figura 6 apresenta a sequência de todas as etapas do gerenciamento de
problemas subdivididas entre controle de problemas e de erros.
28
Figura 6: Controle de problemas e erros
Fonte: Próprio autor
3.5
Gerenciamento do conhecimento
3.5.1 Visão geral sobre a gestão do conhecimento
Dados são considerados como uma sequência organizada de caracteres
agrupados que não estão inseridos em nenhum contexto e por isso fazem pouco ou
nenhum sentido. Quando esses mesmos dados são aplicados em alguma situação
devidamente contextualizada, então eis que temos uma informação, que faz sentido e
pode ser usada para obtenção de algum resultado especifico.
Santiago Jr (2004) diz que, por sua vez, o conhecimento pode ser definido
como uma informação organizada e que passa a fazer sentido, pois é possível se
obter o entendimento sobre o seu significado.
O gerenciamento do conhecimento pode ser representado utilizando-se um
gráfico presente no ITIL, que é mostrado na Figura 7. O gráfico é o DIKW - Data,
Information, Knowledge e Wisdom que seriam Dados, Informações, Conhecimento e
29
Sabedoria. O dado é uma série de fatos independentes que dizem respeito a
eventos. Os dados podem ser obtidos em um banco de dados, como sistemas de
gestão de serviços de TI (OTRS que será abordado a diante), em uma base de
dados de configurações (em português CMDB, originalmente do inglês BDGC) ou em
banco de dados não estruturado. Já informação serve para proporcionar um contexto
para esses dados isolados e independentes. A informação quase sempre é
armazenada em conteúdos multimídia como documentos, e-mail, banco de dados,
diretórios, etc. O seu conteúdo precisa ser fácil de se capturar, encontrar, reusar,
aprender e consultar com base nas experiências. Por sua vez, o conhecimento é a
composição, quase sempre em sua totalidade, por experiências tácitas, ideias e
iniciativa de valor. A sabedoria é a última escala desse gráfico e representa a
maturidade para se usar o conhecimento em prol do benefício positivo de alguma
situação especifica (ITIL v3, 2007),
Figura 7: Modelo DIKW
Fonte: Próprio autor
Sendo assim, o gerenciamento do conhecimento é o processo responsável
por analisar, capturar, armazenar e compartilhar conhecimento e a informação
numa organização, tendo como principal objetivo melhorar a eficiência das
decisões ao reduzir a necessidade de descoberta o redescoberta de conhecimento
(OGC, 2007), com isso, a gerenciamento do conhecimento cuida de agregar valor
30
às informações as filtrando, resumindo e agrupando de forma a se padronizar o
acesso as mesmas e facilitar a sua localização.
3.6
Utilizando o OTRS para apoiar o gerenciamento de problemas e construir
uma base de conhecimento
3.6.1 O que é um Sistema de Bilhetes (Sistema de Tickets)?
Um Sistema de Bilhetes (Sistema de Tickets) pode ser definido como um
software que atua sendo responsável pela centralização, pelo registro e pelo
tratamento de solicitações enviadas por clientes de dentro de um contexto
empresarial de prestação de serviços, podendo ser interno ou externo (OTRS, 2012).
No que se refere a clientes, estes podem ser tanto de natureza interna, como no
caso em que os próprios funcionários são os solicitantes, quanto externa, que é
quando o solicitante não possui vínculo organizacional.
Para compreender o funcionamento de um sistema de tickets, é fundamental
que esteja claro o conceito de ticket (bilhete). Um ticket representa uma solicitação de
serviço efetuada por um cliente interno ou externo, que possui um identificador único,
um número individual que lhe é atribuído no momento de sua criação, e que com isso
pode manter todo o histórico de seu ciclo de vida (conforme mostrado na figura 8),
permitindo que qualquer agente envolvido no processo saiba claramente o que se
passou e o que está acontecendo com aquele determinado ticket (OTRS, 2012).
Para se abrir um ticket, o cliente precisa enviar um e-mail para o
departamento de infraestrutura/suporte contendo as informações sobre o seu
problema, em seguida, o cliente recebe um e-mail automático de confirmação
dizendo que a sua solicitação foi aberta e que em breve será respondida com algum
resultado. Após o ticket ser recebido pelo operador responsável pela avaliação do
problema, o mesmo pode ser atendido com sucesso ou sem sucesso, os dados
referentes ao atendimento serão registrados no sistema para futuras consultas e o
cliente receberá uma resposta sobre qual decisão foi tomada a respeito do problema
levantado por ele.
De acordo com o OTRS (2012), o ticket pode ser comparado ao prontuário de
um paciente, que ao dar entrada no hospital lhe é associado um registro
(prontuário) e nele ficam guardados o estado clínico do paciente e sua evolução,
medicações administradas, etc., para que desse modo qualquer médico possa
31
acompanhar a evolução daquele paciente.
Figura 8: Ciclo de vida de um Ticket
Fonte: Próprio autor
32
3.6.2 O que é o OTRS?
O OTRS2 é a sigla de Open Ticket Request System, concebido para ser um
sistema de tickets para o apoio ao rastreamento de solicitações de atendimento que
uma empresa, organização ou instituição pode utilizar para distribuir bilhetes
(tickets) e através desses bilhetes construir uma base de conhecimento para se
gerenciar problemas e incidentes. É um meio padronizado de se gerenciar consultas
recebidas, reclamações, pedidos de suporte, relatórios de defeitos e outras
comunicações (INFORM-IT, 2013).
Como alguns outros Sistemas de Bilhetes ou Sistemas de Tickets, o OTRS vai
muito além do que apenas lidar com listas de e-mail. Para cada bilhete (ticket) aberto
existe um histórico que retrata tudo o que aconteceu com aquele ticket durante o
seu ciclo de vida. O OTRS tem a capacidade de agrupar múltiplas requisições para
o mesmo chamado (ticket), ou seja, a cada resposta do usuário, as informação
prestadas são agrupadas no atendimento principal, tornando assim possível trabalhar
sobre um chamado específico, em vez de trabalhar em cima de cada resposta
informada pelo usuário. É um sistema multiusuário, que possibilita que múltiplos
agentes possam trabalhar simultaneamente nos tickets abertos no sistema, seja
consumindo informações ou incluindo novas (INFORM-IT, 2013).
3.6.2.1 Principais características do OTRS
O OTRS possui uma interface web muito bonita e amigável, que facilita a
navegação pelo sistema.
Através dessa interface é possível administrar todo o sistema. A interface é
compatível com praticamente todos os navegadores modernos do mercado, e está
disponível para tanto para os clientes, que acessam para abrir os tickets, quanto
para os técnicos, que acessam para analisar os tickets abertos.
Toda a parte visual da tela pode ser customizável (OTRS, 2012).
Além da interface visual, o OTRS ainda fornece um rico suporte a e-mails.
Tem a capacidade de anexar arquivos nas aberturas de tickets por e-mail,
conversão automática de HTML para mensagens de texto puro, sem contar que os
e-mails podem ser filtrados pelos cabeçalhos, facilitando a pesquisa. Outra facilidade
2
A versão do OTRS utilizada é a 3.2.6. Pode ser
http://www.otrs.com/en/open-source/get-otrs/software-download/
encontrada
no
site
oficial:
33
é a entrega de respostas automáticas para clientes, configuráveis para cada queue (fila)
de atendimento.
Entre outras vantagens, destacam-se também o fato do OTRS rodar em muitos
sistemas operacionais (GNU/Linux, Solaris, AIX, FreeBSD, OpenBSD, Mac OS 10.x,
Microsoft Windows). Tem suporte a à ASP (Active Service Providing), suporte a
linkagem de vários objetos, por exemplo, tickets e entradas em FAQ, suporte a
integração com backends externos para os dados de clientes, por exemplo, via AD
(Active Directory), OpenLDAP, suporte ao framework para criação de estatísticas,
entre outras (OTRS, 2012).
Figura 9: Página inicial do OTRS, Lista de novos tickets aguardando atendimento
Fonte: Próprio autor
O OTRS possui uma funcionalidade voltada a realização de buscas de textos
de FAQ (Frequently Asked Questions). Os textos de FAQ podem ser incorporados
às respostas dos agentes aos tickets. A Figura 10 abaixo exibe a tela FAQ do
OTRS:
34
Figura 10: FAQ do OTRS
Fonte: Próprio autor
3.6.3 OTRS como base de conhecimento
Segundo a OGC (2007), a base de conhecimento é um repositório que
contém dados utilizados pelo sistema de gerenciamento do conhecimento.
Para se construir uma base de conhecimento, existem algumas ferramentas
chamadas de Sistemas de Tickets, conforme abordado nos tópicos anteriores,
disponíveis no mercado que podem auxiliar o processo de gerenciamento do
conhecimento. Além do OTRS, existe alguns outros exemplos de sistema de tickets,
são eles o "Open View Service Desk" produzido pela empresa HP e o "Unicenter
Service Plus Service Desk" que por sua vez é produzido pela empresa Computer
Associates. Estas duas ferramentas não são gratuitas, mas como alternativa,
temos o OTRS, que é uma ferramenta opensource cuja licença de uso é livre e que
por sua versa será o “TICKET SYSTEM” a ser explorada nesta pesquisa.
Juntamente com as informações obtidas através do preenchimento dos formulários
do OTRS, também é possível se construir a base de conhecimento através da inserção de
arquivos de texto, planilhas, etc, com o objetivo de enriquecer e manter mais consistente a
base do conhecimento.
O OTRS se destaca pela facilidade de uso e customização, bem como pela
adoção no mercado e por estar em completa conformidade com o ITIL V3 (OTRS,
2012).
35
4 ESTUDO DE CASO
4.1
Sobre a organização
A Peixe Bola é uma empresa pública do Brasil criada em 2010 para gerir
outras empresas públicas federais, atua gerenciando as outras empresas que estão
sob sua gerencia, e essas empresas gerenciadas seguem oferecendo diversos tipos
de serviços, que podem ser divididos em consultoria, desenvolvimento, acesso,
suporte, provimento, treinamento, administração, etc.
As empresas geridas pela Peixe Bola têm autonomia para definir os seus
trabalhos, seus produtos, seu público e seus objetivos.
A sua estrutura está dividida em Presidência, Diretoria, Subdiretoria,
superintendência, assessoria, gerência e coordenação.
A sede da Peixe Bola está fisicamente localizada em Brasília/DF, com
infraestrutura necessária que suporta operação de sistemas de missão crítica a
trabalhar 24 horas por dia. A rede da Peixe Bola está distribuída em pontos
estratégicos de vários estados do Brasil onde possui filiais. Nestes locais há as
unidades regionais da empresa que gerenciam as empresas públicas sob a sua
gerencia daquela região.
4.2
Metodologia de pesquisa
A coleta de dados ou pesquisa por dados, um procedimento racional e
sistemático, conforme Gil (2006), objetiva proporcionar respostas aos problemas que
são propostos. Sua necessidade surge quando não há informações necessárias ou
quando estas estão dispostas de forma desordenada.
No caso desta monografia, o objetivo foi realizar o levantamento da forma
como a Peixe Bola diagnostica e busca a solução dos problemas reportados pelos
seus clientes, com a finalidade de se propor a implantação de um sistema de
bilhetes (Ticket System) para o Gerenciamento de Problemas a fim de estabelecer
um processo padrão para tratar problemas e enriquecer o Gerenciamento do
Conhecimento com a soluções alcançadas. A Figura 11 a seguir mostra como
acontecerá a divisão da pesquisa desta monografia:
36
Figura 11: Divisão das fases da pesquisa
Fonte: Próprio autor
Neste capítulo será abordado a fase da Coleta de dados mostrada na figura,
as outras divisões serão abordadas no capítulo a seguir. O Quadro 3 descreve os
acordos entre os objetivos específicos e as formas de obtenção de acordo com a
metodologia da pesquisa, que é a qualitativa. Cada objetivo possui uma relação
direta com as etapas definidas e apresentadas anteriormente na Figura 11.
Quadro 3: Objetivos x As formas de obtenção
OBJETIVOS DA PESQUISA
FORMA DE OBTENÇÃO
Analisar o cenário atual da área de
infraestrutura para que se possa avaliar a
Entrevistas, análise de relatórios e planilhas;
forma como os problemas são identificados
e resolvidos;
Realizar um paralelo do processo de
gerenciamento de problemas do cenário Comparação
entre
os
levantamentos
atual em relação as melhores práticas realizados e o ITIL;
sugeridas pelo ITIL v3;
Sugerir melhorias dos processos ligados a
Sugerir a definição de um processo para
resolução de problemas na Peixe Bola, afim
tratar o Gerenciamento de Problemas
de se construir uma base de conhecimento;
Fonte: Próprio autor
Depois de conhecido o tipo de pesquisa a ser utilizado, é necessário definir o
método do estudo. Para uma pesquisa qualitativa, pode-se utilizar o estudo de caso
ou a pesquisa-ação. Nesta pesquisa será utilizado o estudo de caso, pois conforme
Yin (2001) o mesmo tem como forma de pesquisa questionar um contexto
desconhecido, buscando conhecer determinada realidade até então obscura,
investigando o “como” e os “por quês”. Com o estudo de caso é possível investigar
preservando “as características holísticas e significativas dos eventos da vida real”,
37
Yin(2001). O mesmo pode ser exploratório, descritivo ou explanatório, e de forma
geral tem como tendência tentar esclarecer uma decisão ou um conjunto de
decisões; como o motivo pelas quais foram tomadas, como foram implantadas e que
resultados foram atingidos, Yin (2001). O estudo em questão terá característica
exploratória, pois é necessário conhecer a realidade para criar um mapa da situação
atual e assim transcrevê-la.
4.2.1 Visão geral sobre a coleta de dados na organização
Conforme já descrito anteriormente e apresentado na Figura 11, a pesquisa
se dividiu em três fases, a de coleta de dados, análise e resultados. A primeira
etapa, de levantamento de dados para Yin (2001) pode ocorrer de seis formas
diferentes: através de documentos, registros em arquivos, entrevistas, observação
direta ou participante e de artefatos físicos. Esta pesquisa utilizou técnicas de
entrevistas e de análise de registros de atendimentos e de relatórios. As entrevistas
foram aplicadas no corpo técnico de segundo nível de atendimento em duas etapas.
Na primeira foi pedido aos técnicos que descrevessem os problemas mais comuns
que ocorrem no dia-a-dia detalhando cada um com informações relevantes. O
objetivo deste questionamento foi perceber os problemas diários enfrentados pelos
técnicos segundo suas percepções. Em seguida, foram analisados relatórios de
quantidade de atendimento mensal por equipe, objetivando identificar quais áreas
tiveram uma demanda maior de chamados por mês. Com os resultados da primeira
etapa de entrevistas e a análise dos relatórios, foi possível definir a estratégia para
consolidar as informações de forma mais objetiva. Foram observados os meses de
abril e maio de 2013, onde em cada mês foram analisados 120 incidentes com o
objetivo de levantar os cinco problemas que mais ocorreram neste período e a forma
como estes são tratados. Como última fase da coleta de dados, foi realizada a
segunda etapa de entrevistas, onde foram apresentados aos técnicos os cinco
problemas identificados e estes descreveram de forma genérica a maneira como os
mesmos identificam, diagnosticam e resolvem problemas.
4.3
Coleta dos dados na organização
A análise da situação atual objetiva apresentar a forma como a empresa lida
com a Gerenciamento de Problemas. Nesta etapa são apresentadas informações
que serão a base para a construção desta pesquisa. Este tópico se divide nas três
38
etapas de levantamento de informações, que são a primeira etapa de entrevistas,
análise de relatórios de atendimento e a segunda etapa de entrevistas.
Inicialmente realizou-se duas etapas em paralelo, as entrevistas com os
líderes das equipes de atendimento em segundo nível e a análise dos relatórios
mensais de atendimento das mesmas. Com essas informações, foi possível passar
para a terceira fase, onde foram realizados levantamentos no sistema de incidentes
para identificar os cinco problemas que mais ocorreram. Com base nestas fases, foi
realizada uma outra entrevista de encerramento. As perguntas aplicadas nas
entrevistas podem ser observadas no Apêndice A. A seguir, é possível identificar
cada etapa mais detalhadamente.
4.3.1 Análise das entrevistas: Primeira etapa
Nesta etapa, escolheram-se algumas equipes de atendimento de segundo
nível do setor da infraestrutura para se aplicar o questionário. Para estas, foram
questionados quais problemas são atendidos com mais frequência e para cada
problema descrito, pediu-se para relatar alguma informação relevante a respeito do
mesmo. No setor da infraestrutura existe a divisão do profissionais por equipe,
sendo assim, as equipes entrevistadas foram a de conectividade, de atendimento
interno, a equipe Windows e a Linux.
Na equipe de conectividade, foi entrevistado o coordenador de atendimentos.
Os problemas resolvidos por esta estão relacionados às redes da Peixe Bola, tanto
internas com externas. Segundo o mesmo, a equipe realizava atendimentos de
grande importância para a empresa.
Uma rede inoperante pode significar clientes de alguma empresa mantida
pela Peixe Bola sem serviços, impossibilitar o trabalho dos funcionários da Peixe
Bola ou de alguma outra empresa mantida por ela e sem falar que poderia paralisar
os veículos de comunicação, que são clientes de grande porte das empresas da
Peixe Bola, por exemplo.
Na entrevista foi relatado, que mensalmente, os principais problemas
encontrados estão relacionados a perda de conectividade com as linhas contratadas
junto a empresa de fornecimento de internet, chegando a 10% do total de canais que
acusam algum tipo de problema, seja de perda de sinal, equipamentos queimados
ou falha de sincronia em canais utilizando Frame Relay. Outros problemas que
ocorrem com frequência são os relacionados à lentidão. A lentidão pode ser tanto na
39
rede interna de algum cliente externo (anunciantes, veículos, etc.), quanto na rede
interna da Peixe Bola, nesse caso afetando os clientes que são funcionários da
empresa.
Já na equipe interna, que atende aos clientes que são funcionários da
empresa, são realizados atendimentos a hardwares e softwares em geral. Conforme
o supervisor da equipe, o parque de máquinas atendido pela equipe é de
aproximadamente 3000 estações de trabalho e mais 200 impressoras em rede e
locais. Na entrevista, foi relatado que os problemas mais frequentes são
relacionados a lentidão e travamento em sistemas operacionais, problemas em
estações, impressoras e demais periféricos, além disso também existem problemas
operacionais, causados por falta de conhecimento dos usuários.
Na equipe Windows, entrevistou-se o técnico mais experiente. Foi observado
que os atendimentos realizados são referentes a servidores internos, que podem ser
servidores de arquivo, maquinas destinada ao desenvolvimento de novos produtos
ou software, sites inoperantes por queda repentina do link de comunicação ou do
servidor e problemas em backups gerais (Banco de dados, arquivos, etc.). Segundo
o mesmo, esta equipe possui atendimentos muito variados e sem problemas
específicos, porém existe um que geralmente ocorre com mais frequência, que está
relacionado aos agentes de backup e monitoria, que perdem a conexão com o
servidor principal de controle dos agentes.
A última equipe que foi entrevistada, a equipe Linux, que como já foi dito
anteriormente é uma divisão interna dos funcionários do setor de Infraestrutura,
realiza atendimentos a servidores e estações de trabalho Linux. Estes são focados
em Correio eletrônico (Zimbra), servidores Proxy, de hospedagem e agentes de
backup e monitoria. Geralmente resolvem problemas em envio e recebimento de
mensagens, ajustes em servidores Proxy, restauração de dados, entre outras
demandas.
O Quadro 4 abaixo é um resumo consolidado do resultado individual obtido
com a aplicação da primeira etapa da entrevista.
40
Quadro 4: Dados coletados dos problemas mais frequentes na primeira etapa
Windows
Internas
Conectividade
Equipes Entrevistado Problema mais frequente
Queda ou interrupção de comunicação
Perda de pacotes em dados recebidos
Perda de conectividade
Roteador ou modem queimado ou com defeito
Conectado mas não navega, problema de DNS
Rede interna
Roteador queimado
Perda de conectividade Hub ou Switch queimado
outros reparos
Somente um micro ou quadrante da rede não comunica
Funcionário 1
(Cliente interno, funcionário)
Problemas do canal do provedor
Canal saturado, link carregado
Equipamento causando estouro de banda
Lentidão
Atualização de Antivírus ocupando a banda
Aplicação lentas
Infraestrutura de rede problemática
Teclado/mouse
Problemas nos periféricos ou operacionais
Vídeo
Vídeo fora de foco, pouco brilho ou queimado
Máquina (Computador)
Problemas de memória, HD, superaquecimento
Lentidão, travamento ocasionados por vírus, spywares,
hardwares defeituosos ou problemas operacionais
Softwares/Sistemas
operacionais
Erro de registro do Windows, dispositivos conflitantes,
Driver de Impressora corrompido
Funcionário 2
Falta de conhecimento na operação de equipamentos ou
Operacionais
Funcionário 3
softwares
Físicos: lubrificação, mal contato cabo paralelo, ajustes
mecânicos
Problemas em impressoras Atolamento de papel em impressoras, por má colocação ou
umidade no papel
Software: driver errado, compartilhamento de impressoras
Cabo de rede com defeito, Máquina fora do domínio, não
Rede
instalada a placa de rede, conflito de hardware
Funcionário 4
Agentes de Backup/TNG
Envio e recebimento de
mensagens
Linux
Descrição das causas do problema
Problema de performance
no servidor de
Hospedagem
Funcionário 5
Portal caindo com
frequência
Apontamento de DNS
Lentidão de internet
Falha de Conexão dos agentes de monitoria com os
servidores
Clientes não conseguem enviar e receber e-mail pelo
Zimbra
Servidor de Zope deveria ter sido desativado, a Peixe Bola
desistiu da tecnologia e parou de comprar atualizações
Servidores JBoss com erro de PermGem Space.
Muito tráfego de MP3, vídeo, conteúdos multimídia.
Sites DNS que apontam para servidores UNIX que não
passam pelo NGINX
Máquinas muito lentas e com pouco espaço ocasionando
paradas de serviço. Clientes internos: UUU, CCC
Fonte: Próprio autor
41
4.3.2 Análise de documentos e relatórios
Nesta fase foi observado o relatório de volume de atendimento mensal das
equipes de segundo nível. Deste foram extraídos os números referentes às equipes
entrevistadas na primeira etapa. Mais detalhadamente no Quadro 5 pode ser
observado o total de atendimentos realizados pelo setor que atende às demandas
de segundo nível.
Esta pesquisa analisou dados dos meses de abril e maio de 2013. Para isso,
levou-se em consideração o limite para o início do período de férias, fator que
influencia o volume de atendimentos, pois a partir de Junho a demanda de
atendimentos diminui.
Quadro 5: Total de atendimentos realizados no período.
Equipes
Abril de 2013
Windows
Maio de 13
Média
70
83
76,5
Linux
127
90
108,5
Conectividade
236
320
278
Interna
200
230
215
Total de ocorrências
633
723
678
Fonte: Próprio autor.
Pode-se observar no Quadro 5 que existem três equipes que possuem uma
demanda maior de atendimentos, dentre elas a equipe Interna, de Conectividade e
de Linux, que se somadas representam cerca de 80% do total de atendimentos de
segundo nível no período observado.
Para este estudo, foi escolhida a equipe de conectividade, pois foi levado em
consideração além da grande quantidade de chamados, a importância desta no
Gerenciamento de Problemas, pois atende demandas que podem representar maior
impacto nos serviços prestados pela Peixe Bola segundo o líder da equipe.
No próximo tópico, pode-se observar a análise dos chamados conforme a
área escolhidas nesta etapa.
42
4.3.3 O atual sistema de incidentes
Depois de realizada a primeira etapa de entrevistas para obter dos líderes de
equipe os problemas que mais ocorrem, e de analisados relatórios de atendimento
para observar quais destas equipes possuem um volume maior de atendimento, foi
possível estabelecer o foco da pesquisa. Este foco se baseou na escolha da equipe
de conectividade. As equipes no geral utilizam um sistema muito simples e imaturo
para controlar a abertura de chamados e incidentes, o sistema foi desenvolvido por
antigos técnicos das próprias equipes que já não fazem mais parte do quadro de
funcionários da empresa, o que deixa nulo ciclo evolutivo de melhorias e correções
desse sistema. Dentro do sistema foram analisados 120 atendimentos de cada mês
para a equipe de conectividade. Destes incidentes, foram extraídas informações
sobre o tipo de falha ou problema, a falha propriamente dita e a solução dada.
Depois disso foram levantados dados numéricos quantificando as informações
descritas nos incidentes. Cada incidente no sistema é preenchido em forma de texto
livre, desde sua geração por e-mail recebido até a conclusão no segundo nível de
atendimento.
Assim, ações realizadas são cadastradas através de assentamento, que
descrevem o problema, encaminhamentos e a solução do incidente, fator este que
dificultou o levantamento das informações. Hoje não existe um filtro que possibilite
quantificar ou qualificar as informações nele cadastradas. Além disso, cada
atendimento é transcrito conforme o entendimento e empenho do técnico, sem
qualquer padrão ou definição oficial. Muitas vezes faltam informações que
descrevam qual ação foi tomada ou qual real problema ou não conformidade estava
sendo reclamada no incidente.
De forma geral os incidentes são resolvidos, mas não existe um tratamento
adequado padrão para cada caso. As equipes técnicas em alguns casos não se
preocupam em tratar o problema, pensam somente em resolver o incidente, já
outros casos o problema até é conhecido, mas faltam ferramentas técnicas ou
gerenciais para resolvê-los.
Iniciando a fase extração das informações, em um primeiro momento, foram
observados somente os problemas ou falhas descritos nos incidentes, com o
objetivo de encontrar os cinco problemas que mais ocorreram no período. Depois de
identificados, foi realizada uma segunda leitura, porém com foco nestes incidentes
relacionados aos cinco que mais repetiram, para identificar as soluções dadas para
43
cada caso. Estas informações foram trabalhadas e transcritas de maneira que
facilitasse a quantificação das informações.
Nos tópicos que seguem, é possível identificar um resumo dos levantamentos
realizados com os atendimentos da equipe.
4.3.3.1 Área de atendimento à conectividade
Na análise dos atendimentos realizados pela equipe de conectividade,
observou-se que existe um ambiente mais controlado, com menos variações de
problemas, os técnicos possuem bastante experiência e realizam esses tipos de
atendimento há bastante tempo. Apesar destas vantagens, a equipe registra
algumas vezes de forma inadequada, pois faltam informações para esclarecem
quais medidas foram ou devem ser tomadas.
Nos incidentes analisados, identificaram-se problemas relacionados à
lentidão, de rede local, problemas operacionais e outros, mas os incidentes que mais
se repetiram foram a de falta de conectividade, acima de 60% dos casos. Por esse
motivo o item “sem conectividade” foi o escolhido para prosseguir nos estudos.
Quadro 6: Problemas identificados na amostra de atendimentos da equipe
Referências / Problemas
Abril 2013
%
Maio 2013
%
Média
%
Cable virtua fora do ar
1
1%
1
1%
1
0,8%
Conversor de fibra
1
1%
1
1%
1
0,8%
Modem não liga
4
3%
1
1%
2,5
2,0%
Não enxerga máquinas na rede
5
4%
1
1%
3
2,5%
Não envia mensagens
2
2%
1
1%
1,5
1,25%
Atualização de versão do FreeBSD
5
4%
2
2%
3,5
2,9%
Sem acesso a sistemas / serviços /
Servidor específico
10
3%
8
7%
9
7,5%
Sem acesso
5
4%
4
3%
4,5
3,75%
Instável / lentidão / perda de pacotes
24
20%
14
11%
19
15,8%
Sem conectividade
63
52%
87
72%
75
62,5%
120,00
100% (99,8%)
120
120
Fonte: Próprio autor.
Baseado nos resultados do Quadro 6 acima ficou claro que o problema mais
recorrente é o de perda de comunicação/conectividade. Assim sendo, a partir deste
44
foi verificado novamente o sistema para identificar quais soluções foram dadas para
o mesmo. Como em cada mês o número de incidentes sem conectividade foi
diferente, optou-se (vide Quadro 7) por utilizar percentuais ao invés de números, ou
seja, em abril de 2013 45% do total de 63 incidentes foram referentes a solução
“Atendida pela Empresa de fornecimento de internet” já o mesmo item no mês de
maio de 2013 representou 75% de 87 ocorrências.
Quadro 7: Soluções identificadas para a amostra analisada na equipe de conectividade
Soluções para problema "sem conectividade"
Abril 2013
Maio 2013 Média
Outros
13,6%
7,0%
10,3%
Reiniciar o modem / roteador / firewall / equipamentos
5,0%
2,0%
3,5%
Problema na estação / equipamentos /
Sistema do cliente / rede interna / Servidores
18,0%
4,0%
11%
Problema aleatório / não identificado
17,0%
13,0%
15%
45,0%
75,0%
60%
100%
100%
100% (99,8%)
Atendida
internet
pela
Empresa
de
fornecimento
de
Total
Fonte: Próprio autor
O Quadro 7 acima mostra que mais da metade dos problemas são
solucionados com intervenção da Empresa de fornecimento de internet, fator este
que demonstra certa dependência do fornecedor.
A média de 60% referente a
chamados atendidos pela Empresa de fornecimento de internet, sem contar os 15%
dos caso que o problema não é identificado, onde pode ter ocorrido manutenção da
Empresa de fornecimento de internet sem que a Peixe Bola saiba.
4.3.4 Análise das entrevistas: Segunda etapa
A segunda etapa de entrevistas teve como foco não só o líder das equipe,
mas também em alguns componentes dela. Tendo como base as informações
obtidas nas até o momento na pesquisa, perguntou-se aos técnicos a forma utilizada
para diagnosticar e resolver os problemas identificados como mais frequentes. A
pergunta aplicada pode ser observada no Apêndice A.
4.3.4.1 Equipe de conectividade
Baseado nos dados levantado nas etapas anteriores, foi realizada a segunda
fase de entrevistas, onde perguntou-se qual forma que o técnico utilizada para
diagnosticar e resolver problemas relacionado à sem conectividade. Para esta
45
equipe também foram escolhidos alguns integrantes da mesma mais o líder do
grupo para responder a questão.
O Quadro 8 abaixo ilustra os passos que cada um dos técnicos utiliza para
resolver o problema “sem conectividade”.
Quadro 8: Diagnóstico e solução para problemas de “sem conectividade”.
Sem conectividade
Técnico
Funcionário 1
Passo 1
Verifica dados do
chamado
Verificar informações
da ocorrência
Verificação da dimensão
do problema
Tenta pingar hosts
inacessíveis
Passo 2
Verificar
equipamento de
conectividade,
modem, hub, switch
Teste nos
equipamentos
Tenta executar testes
fora do proxy, direto na
internet
Reinicia os
equipamentos de
internet
Passo 3
Verifica máquina,
servidor, proxy,
DNS
Verificar canal de
comunicação
Testes de
Reinicia equipamentos de
conectividade o
conexão
Nagios
Passo 4
Testes nos
equipamentos, tenta
acessar a internet
de uma máquina
fora da rede.
Testes nos
equipamentos de
conectividade de
ponta, proxy, dns
Aciona troca de modem
queimado
Passo 5
Define problema e o Reinicia equipamentos
Aciona Equipe Interna
seu domínio
de conexão
Passo 6
Encaminhamento
para a Equipe de
Acionar empresa
Internas ou empresa fornecedora de
fornecedora de
internet
internet
Funcionário 2
Funcionário 3
–
Funcionário 4
Identificação do
problema
Encaminhamento a
empresa fornecedora
de internet
–
Fonte: Próprio autor.
As respostas transcritas no Quadro 8 mostram que a equipe de conectividade
possui um certo padrão de diagnóstico e resolução de problema. Nas respostas da
entrevista ficou claro que os técnicos fazem muito mais procedimentos do que
registram no sistema. Esta equipe por ter um conhecimento maior da função e por
estar formada a bastante tempo sem mudanças de pessoas, possui um domínio e
um controle maior do seu universo de trabalho.
Em consequência deste ambiente favorável, a equipe não atinge um nível
satisfatório de qualidade quando fazem o registro de seus atendimentos, pois não
transcrevem completamente seus procedimentos da forma que acontecem. Isso
pode ser notado de acordo com as respostas obtidas com a entrevista. Quando os
técnicos responderam a entrevista, foram bastante detalhistas com relação ao
46
trabalho desempenhado, descrevendo todos os passos para diagnosticar e resolver
o problema. Após observar o sistema de incidentes, é possível verificar que o
problema de forma geral é resolvido ou encaminhado, porém sem um padrão de
registros com os passos realizados para chegar à solução.
47
5 DISCUSSÃO
5.1
Critérios para interpretação dos achados do estudo de caso
5.1.1 Paralelo do modelo atual com as boas práticas do ITIL v3
Conforme os dados levantado no Capitulo 4, tópico 4.3, identificou-se
deficiências nos processos ligados ao diagnóstico e resolução de problemas, tanto
na parte de identificação, quanto nos procedimentos para chegar à solução e
registro durante o ciclo de vida do incidente.
A seguir será apresentada uma comparação entre a resolução de problemas
na Peixe Bola e as boas práticas de ITIL, seguida de propostas de melhoria.
5.1.2 ITIL v3 aplicado à resolução de problemas na Peixe bola
Na Peixe Bola, o diagnóstico e resolução de problemas não baseia-se em
metodologias
e
sim em padrões
empíricos
e
intuitivos,
formados
pelos
procedimentos e pela cultura organizacional, treinamentos e pela experiência e
empenho dos técnicos que compõem as equipes.
O conhecimento necessário e as etapas para diagnosticar e resolver os
problemas estão na cabeça das pessoas, algumas vezes são pesquisados na
internet, em outros casos existem documentos ou procedimentos escritos que
descrevam como deve ser resolvido o problema. Por exemplo, na equipe interna
com maior rotatividade, quando entra um novo estagiário, terceiro ou funcionário, é
repassado os procedimentos para o mesmo de forma oral e, na prática, quando este
possui alguma dúvida deve procurar o supervisor ou colega mais experiente para
resolver o problema. Além disso, o sistema de incidentes não possui recursos de
pesquisa que disponibilizem consultas para identificar situações semelhantes no
passado por tipo de problema.
Com base na realidade apresentada, é possível definir um modelo lógico e
genérico utilizado na Peixe Bola para diagnosticar e resolver problemas. Nas
entrevistas, identificou-se que alguns técnicos realizam até seis passos para chegar
a uma resolução. A Figura 12 apresenta três etapas principais, que abrangem e
resumem os passos realizados durante o tratamento dos incidentes. Todas as
respostas que ultrapassam esse três passos estão repetindo alguma etapa ou
realizando mais de uma vez o fluxo identificado.
48
Figura 12: Modelo de diagnóstico e resolução de problemas
No modelo apresentado na Figura 12, os retângulos são as ações dos
técnicos e as formas ovais representam procedimentos no sistema de incidentes. O
mesmo se inicia com a entrada do incidente na caixa da equipe de atendimento, em
seguida é feita a identificação do problema. Na seqüência o técnico registra o início
de atendimento e depois faz os testes e realiza a ação corretiva, ao final registra
encerrando ou encaminhando o incidente.
O Gerenciamento de Problemas no ITIL é dividido em duas etapas, o controle
de problemas e de erros. O primeiro trata do problema desde sua identificação
passando pela descoberta de sua causa raiz até o surgimento de um erro conhecido
ou solução de contorno, neste momento é aberta uma requisição de mudança
(RDM). Já o segundo, trabalha sobre o erro já identificado, realizando o
acompanhamento do mesmo até que seja solucionado definitivamente.
O levantamento realizado nesta pesquisa analisou mais especificamente a
primeira etapa do Gerenciamento de Problemas, pois teve como escopo a parte de
diagnóstico e resolução de problemas, que no ITIL é contemplada dentro do controle
de problemas.
Comparado o estudo realizado na Peixe Bola com o ITIL, é possível dizer que
intuitivamente os técnicos realizam as etapas propostas pelas boas práticas. O
problema está na falta de um método que norteie o registro e a resolução dos
problemas, para que as informações necessárias sejam utilizadas de forma mais
eficiente e por conseqüência trazendo mais informações para o Gerenciamento de
Incidente e melhorando o nível do serviço.
A causa disto está no sistema de incidentes que não disponibiliza recursos de
controle operacional e tático que gerem informações quantificadas a respeito dos
49
problemas existentes e resolvidos, e que possam incrementar a base de dados do
controle de problemas.
O Quadro 9 abaixo apresenta uma comparação entre as atividades do
Gerenciamento de Problemas e a e forma como estas estão sendo tratadas na
Peixe Bola.
Quadro 9: Comparação entre o Gerenciamento de Problemas pelo ITIL e a PEIXE BOLA
Gerenciamento de Problemas
Controle de Problemas
Atividade (ITIL)
Situação na Peixe Bola
Identificação e registro dos
problemas
Sistema sem suporte a registro ou identificação de
problemas: não existem meios de registrar
informações de forma que facilite a identificação de
problemas a partir de incidentes.
Classificação do problema
Investigação e diagnóstico
do problema
RDM e Resolução e
encerramento do problema
Categorização em estágio inicial (a cargo do projeto
de incidentes na Peixe Bola)
Não há qualquer recurso para identificação de
impacto, urgência e prioridade, essa função fica a
cargo da experiência dos profissionais
Falta de procedimentos e de documentações que
auxiliem no aprofundamento e padronização de
investigação e diagnóstico
RDM: já existe sistema para cadastramento de
RDM’s
Resolução e encerramento de problemas: Incidentes
e problemas possuem a mesma conotação no
sistema da Peixe Bola, não é feito diferenciação de
ambos.
Situação
!
!
Controle de Erros
Identificação e registro do
erro
Avaliação do erro
Registro da resolução de
erro
Erros conhecidos são identificados pela experiência
individual ou da equipe e são registrados nos
incidentes. Não existe procedimento nem forma de
armazenamento dessas informações
O erro é avaliado conforme a experiência do técnico.
É registrado no sistema dentro do incidente em texto
livre, sem possibilidade de buscar histórico
automaticamente.
- RDM: já existe sistema para cadastramento de
RDM’s
Fonte: Próprio autor
Diante do apresentado no Quadro 9 acima, temos a seguinte legenda:
– Implementado,
incompleto.
– Não implementado, ! – Implementado parcialmente ou
50
5.2
Proposição da solução e aplicação de boas práticas
Este trabalho sugere duas propostas, uma delas é a avaliação das
informações registradas nos incidentes, com o objetivo de estruturar os registros de
diagnósticos e resolução dos incidentes e poder separar o que é incidente do que é
problema, pois hoje são tratados da mesma forma. Com isso também será possível
auxiliar no processo de Gerenciamento de Problemas. A outra melhoria é o
alinhamento da Peixe Bola às etapas de controle de problemas e de erros do
Gerenciamento de Problemas com a utilização de uma ferramenta de apoio ao
mesmo.
5.2.1 Qualificação dos registros de incidentes
Com o objetivo de melhorar as informações registradas nos incidentes,
propõe-se criar etapas padronizadas de registro, que force o técnico a informar suas
ações conforme proposto pelo Gerenciamento de Problemas, dividindo-as em
identificação, testes e ações corretivas.
A Figura 13 apresenta a forma identificada nas entrevistas (conforme
apresentado anteriormente na Figura 11), com as adaptações necessárias para
adequar ao modelo proposto pelo ITIL e então termos uma proposta, incluindo
padrões para registros de todas as etapas realizadas e mais a categorização e
escalação para o Gerenciamento de Problemas.
Figura 13: Proposta de melhoria para o registro de incidentes na Peixe Bola
Fonte: Próprio autor
51
A Figura 13 acima apresenta o novo fluxo de trabalho proposto com base nos
levantamentos realizados.
Neste procurou-se manter as etapas identificadas na Figura 11, agregando
conceitos do ITIL. A diferença está nos quatro objetos em cor laranja, que
representam registros de informações no sistema. O primeiro é referentes a não
conformidade identificada, o segundo os testes e o terceiro as ações corretivas,
ligado a estes dois últimos estão as tarefas práticas que serão executadas pelos
técnicos, relativas a testes e ações tomadas.
Depois disso é feita a classificação, categorizando os incidentes e por fim o
mesmo é encerrado ou encaminhado. A inclusão desses registros servirá de base
não somente para o Gerenciamento de Incidentes que necessita de informações
gerenciais, mas também para o Gerenciamento de Problemas, em forma de uma
base de informação para auxiliar na descoberta das causas raízes e tratar os erros
conhecidos.
5.2.2 Proposta de alinhamento do Gerenciamento de Problemas à Peixe Bola
A segunda entrega da pesquisa baseou-se em todas as informações até
então levantadas, que serviram para identificar a forma atual de tratamento dos
problemas na Peixe Bola.
Como não foram identificados processos claros e definidos para o
Gerenciamento de Problemas, foi necessário mapear todas as atividades deste
processo comparando-as à realidade da Peixe Bola, conforme já foi apresentado no
tópico 4.2, na Figura 11. Depois de identificadas essas lacunas é possível sugerir
um modelo, baseado na forma de trabalho da Peixe Bola e alinhada às boas práticas
de ITIL. A seguir serão apresentadas três etapas de solução de problemas.
Hoje na Peixe Bola existem sistemas alinhados a três processos do ITIL, um
referente ao Gerenciamento de Mudanças chamado GMUD, este é responsável por
controlar e acompanhar todas as mudanças realizadas na Infraestrutura de TI da
empresa.
O outro é o sistema de Gerenciamento de Configuração chamado GCO, que
hoje é o cadastro oficial dos itens de configuração (IC`s). Ambos sistemas estão em
desenvolvimento e aumentando gradativamente sua base de informações.
52
Por último, o sistema de Incidentes, ferramenta já em um uso a alguns anos,
essa última evoluiu conforme as necessidades de mudança da organização, porem
possui várias restrições como já levantadas anteriormente.
O ITIL v3 descreve que algumas disciplinas possuem ligações e dependem
de informações entre elas, principalmente Incidentes, problemas, mudanças e
configuração. Para preencher as lacunas encontradas na pesquisa é necessário
criar em primeiro lugar um processo que interligue as disciplinas e possibilite a troca
de informações.
Pensando no cenário atual. Para haver este intercâmbio é necessário uma
ferramenta para tratamento das informações, sugerindo-se assim um sistema
específico de tratamento de problemas, conforme proposto, o OTRS, de forma que
se relacione com os demais sistemas existentes. A Figura 14 abaixo apresenta a
proposta de relação entre as ferramentas existentes e o OTRS, onde os quadros
cinzas representam as ferramentas existentes e o quadro azul ao centro representa
o OTRS.
Figura 14: Fluxo de proposta de relacionamento entre as ferramentas existentes e a proposta
para a ferramenta Gerenciamento de Problemas (OTRS)
Fonte: Próprio autor
53
A Figura 14 acima apresenta a interação entre as ferramentas. No caso do
RTP, que é a ferramenta de gerenciamento de incidentes, há uma troca de
informações entre Incidentes e Problemas, no caso do GMUD, que a é a ferramenta
de gerenciamento de mudanças, a ferramenta de problemas abre uma requisição de
Mudanças (RDM) para resolver um problema e recebem em troca o status da
mesma.
Já o GCO, que é a ferramenta de gerenciamento de configuração, envia
informações sobre os IC´s (itens de configuração) envolvidos no problema no
momento da abertura do registro de problema.
Para descrever mais detalhadamente esta ligação, criou-se um fluxo de
trabalho para o Gerenciamento de Problemas, sem descrever ferramentas e sim
processos do ITIL.
Este fluxo inicia com a Gestão de Incidentes e Configuração enviando
informações importantes para tratar os problemas, em seguida essas informações,
dentro do Gerenciamento de Problemas são encaminhas para o Controle de
Problemas, onde será descoberta a causa raiz do mesmo. Dentro deste é feita a
identificação do problema, baseado nas não conformidades repetidas entregues pelo
Gerenciamento de Incidentes, em seguida é feita a classificação do problema, com
base na categorização apresentada pelos Incidentes, confirmando o impacto,
urgência, a prioridade e definindo um status. Na sequência é realizada a
investigação e diagnóstico do problema, que futuramente será realizada pelas
equipes de atendimento, iniciando no nível dois até o que for necessário.
Depois disso é descoberta a causa raiz, onde se encerra as tarefas do
Controle de Problema, surge então o erro conhecido. Essas informações são
repassadas para Controle de Erros, onde o erro é registrado e identificado.
A etapa seguinte é a avaliação do erro, se este pode ser resolvido ou se será
mantida uma solução de contorno. Depois é registrada a solução do erro e
encaminhada para a execução através de um RDM, conduzida pelo Gerenciamento
de Mudanças. Quando a mudança é concluída, encaminha-se o status da mesma
para o controle de erros registrar em sua base de dados, assim então esta poderá
ser encerrada. A Figura 15 apresenta a descrição deste fluxo de trabalho
apresentado.
54
Figura 15: Modelo de tratamento de Problemas, interligado Incidentes, Configuração e Mudanças
Fonte: Próprio autor
55
Com base no fluxo apresentado na Figura 14 e na Figura 15 criou-se também
uma proposta de processo de trabalho descrevendo a forma sugerida de
funcionamento do Gerenciamento de Problemas na Peixe Bola. Foram apresentadas
no mesmo o envolvimento com as outras ferramentas mostradas na Figura 14,
detalhando os processos do Gerenciamento de Problemas, apresentando as etapas
de Controle de Problemas, Controle de Erros e suas dependências.
No tópico 5.3, será discutido como os sistemas apresentados na Figura 14
poderiam coexistir junto ao OTRS, que será proposto para o gerenciamento de
problemas.
A seguir é apresentada a etapa do processo a ser proposto e sua descrição:
Gerenciamento de Incidentes (RTP): Nesta etapa inicia o processo, nele
identifica-se os incidentes referentes a mesma não conformidade. São repassada
para a próxima etapa as informações de classificação e categoria.
Gerenciamento
de
Configuração
(GCO):
São
disponibilizadas
as
informações sobre os Itens de Configuração (IC´s) envolvidos.
Identificação do problema: Esta é a primeira etapa do Controle de
Problemas dentro do Gerenciamento de Problemas. Nela é identificada qual
problema está ocorrendo e é aberto um registro de problema, com base nas
informações dos incidentes e dos IC´s.
Classificação: É refeita a etapa de classificação e categorização dos
incidentes, focando as informações no problema, redefinindo o impacto, urgência, a
prioridade e definindo um status.
Investigação e Diagnóstico: São realizados pelos técnicos testes para
investigar e diagnosticar o problema. Neste momento, busca-se informações nos
histórico de problemas, em outros documentos, na internet ou a própria experiência
do técnico, depois são registrados os teste. Por fim pergunta-se se a causa raiz foi
encontrada.
Equipe especializada: Para o caso da pergunta realizada na etapa anterior
for negativa, o problema irá ser tratado por uma equipe especializada, até seja
resolvido. Quando são concluídos os testes e feitos os registros necessários,
retorna-se para a etapa anterior e pergunta-se novamente se a causa raiz foi
encontrada. Enquanto a resposta não for positiva esse ciclo permanece.
Resolução: Se a pergunta da etapa Investigação e Diagnóstico sobre a
causa raiz for positiva, significa que o problema transformou-se em erro conhecido e
56
o fluxo segue para esta fase perguntando a necessidade de um RDM, caso não seja
necessário é aplicada a ação corretiva, registrando e encerrando o problema.
Controle de Erros: Na fase anterior, se a resposta da pergunta sobre a
necessidade de uma RDM for positiva inicia esta etapa com a identificação e registro
do erro, em seguida é feita uma avaliação do mesmo, onde se avalia as variáveis do
contrato de serviço, classificação realizada na etapa de Controle de Problemas,
custos, etc. Depois é feito um registro da resolução do erro. Levando em
consideração estas variáveis, se decide a necessidade de abertura de uma RDM. Se
aberta esta será tratada pelo Gerenciamento de Mudanças, onde serão utilizadas as
informações de Problemas para resolver o erro conhecido.
Gerenciamento de Mudanças: Trata do gerenciamento da mudança através
da RDM aberta, disponibilizando ao final status sobre a situação do erro conhecido.
Conforme as etapas descritas, a Figura 16 apresenta o desenho do processo
de Gerenciamento de Problemas baseado no ITIL proposto para aplicação na PEIXE
BOLA.
57
Figura 16: Processo proposto para o tratamento de problemas baseado no Gerenciamento de Problemas do ITIL
Fonte: Próprio autor
58
Os resultados apresentados neste capítulo trazem um modelo de processo,
as ferramentas atuais existentes na organização e a proposta de implantação da
ferramenta para o Gerenciamento de Problemas interagindo com a realidade da
Peixe Bola.
Para o sucesso desta interação não basta somente desenvolver e implantar o
modelo de gerenciamento proposto e a ferramenta de gerenciamento de problemas,
é necessário também levar em consideração as pessoas, que serão os atores
principais dos processos e ferramentas. É necessário que a organização invista em
desenvolvimento cultural e tecnológico das pessoas, com o objetivo de melhorar o
processo e nível técnico da equipe. No tópico a seguir, será apresentado a proposta
de implantação da ferramenta OTRS para auxiliar o Gerenciamento de Problemas.
5.2.3 Proposta de implantação do OTRS para auxiliar o Gerenciamento de
Problemas
De acordo com o que foi levantado e analisado no capitulo 4, mais
precisamente no tópico 4.3.3, o sistema de gerenciamento de incidentes (RTP) que
e usado atualmente pelas equipes, não atende completamente as expectativas por
consequência de suas limitações de uso em geral. É um sistema simples e imaturo,
que não recebe nenhum tipo de atualização há algum tempo, pois o seu
desenvolvimento foi realizado por próprios técnicos do setor que também eram
programadores, mas hoje já não fazem mais parte do quadro de funcionários da
empresa.
Conforme explicado no cronograma para execução da pesquisa no capítulo 2,
durante o mês de Julho de 2013 foi realizado o estudo para a modelagem do
processo para gerenciamento de problemas e em seguida os esforços foram
voltados para a elaboração da proposta de implantação do OTRS.
Juntamente com a ferramenta de gerenciamento de Incidentes (RTP), existem
outras duas ferramentas que são utilizadas no gerenciamento de mudanças (GMUD)
e no gerenciamento de configuração (GCO), conforme mostra a Figura 14.
A ideia inicial dessa pesquisa foi absorver apenas o processo de
gerenciamento de problemas, entretanto pode ser considerada também a hipótese
do OTRS absorver os processos de gerenciamento de configuração, gerenciamento
de incidentes e o gerenciamento de mudança, dessa forma, centralizando todo o
conhecimento dentro do OTRS.
59
É possível classificar os tickets registrados no sistema, por exemplo, definir
todos os tipos de processos descritos nas boas práticas do ITIL, nesse caso
separando os tickets que são englobados pelo gerenciamento de problemas,
incidentes, configurações, mudanças, etc. Como já dito anteriormente, nesta
pesquisa será abordado apenas um dos tipos de processo, que é o de
gerenciamento de problemas, mas através dos resultados obtidos com o
gerenciamento de problemas, é possível ter visão do poder da ferramenta OTRS
que está sendo proposta e do valor que a mesma agrega ao negócio.
A ferramenta OTRS é muito mais que apenas um sistema de rastreio de
defeitos. Seus inúmeros recursos já discutidos no Capítulo 2, em conjunto com a
ampla conformidade às recomendações do ITIL, fizeram com que ele fosse
escolhido a ser o software que auxiliará as operações das equipes de infraestrutura
da empresa Peixe Bola.
O objetivo geral desse tópico é sugerir a adoção do OTRS para auxiliar o
trabalho daquele setor, para isso, será explanado sobre como a instalação poderá
ser feita, bem como o que poderia ser customizado para atender a ampla demanda
recebida pelo setor.
Sendo assim, o objetivo desse tópico não é ser mais um tutorial completo de
todos os passos necessários de como se utilizar o OTRS, mas sim mostrar que ele
poderia ser usado para atender e dar suporte ao Gerenciamento de Problemas, não
descartando a hipótese de que futuramente poderia ser um usado também para a
centralização de outros processos do ITIL, como já citado anteriormente.
5.2.3.1 Instalação do OTRS em um cenário de teste
O objetivo dessa sessão é mostrar de forma breve os passos necessários
para instalar a ferramenta OTRS em um ambiente de teste, o qual foi usado para
elaborar esta proposta de adoção, onde o objetivo é realizar testes de usabilidade e
de aderências às necessidades da empresa Peixe.
Para a instalação do OTRS, é necessário instalar na máquina um servidor
WEB (Apache, por exemplo), um sistema de banco de dados (MySQL, por exemplo),
um servidor de e-mail (Sendmail, por exemplo), a biblioteca da linguagem de
programação Perl. Neste exemplo, foi usado o Ubuntu Linux como sistema
operacional, mas também pode ser realizado utilizando outro sistema operacional.
60
Os passos intermediários para a instalação que foram apresentados acima não
serão abordados detalhadamente nessa sessão pois fogem do escopo inicial da
pesquisa.
O OTRS pode ser instalado via o gerenciador de pacotes utilizando o seguinte
comando de console: sudo apt-get install otrs, após essa instalação é necessário
instalar também algumas dependências para o funcionamento do sistema, essa
instalação pode ser feita através do comando de console mostrado no Quadro 10
abaixo:
Quadro 10: Comandos básicos para instalação do OTRS via console Linux
Comandos de console Linux para a instalação do OTRS
sudo apt-get install libencode-hanextra-perl libgd-text-perl libgd-graph-perl
libmail-imapclient-perl
libnet-dns-perl
libnet-smtp-tls-butmaintained-perl
libpdf-api2-perl
libtext-csv-xs-perl
libproc-daemon-perl libapache-dbiperl libdbd-mysql-perl libclass-dbi-mysql-perl sendmail sendmail-cf m4.
Fonte: Próprio autor
5.2.3.2 Configuração inicial do OTRS
Após a instalação do OTRS, é necessário realizar a configuração inicial do
mesmo através do próprio sistema.
A configuração pode ser realizada por meio de um navegador, acessando o
seguinte endereço: http://localhost/otrs/installer.pl, onde “localhost” é o endereço
do servidor onde o OTRS foi instalado. Ao acessar a página, a Figura 17 abaixo é
exibida:
61
Figura 17: Configuração inicial do OTRS
Fonte: Próprio autor
O processo de configuração é muito rápido e simples, é uma instalação NNF
(Next next Finish) padrão.
Existem 5 passos simples a serem seguidos para a configuração, que são:
Passo 1: Aceite da licença, Passo 2: Configuração do banco de dados, Passo 3:
Especificações gerais e configuração de e-mail, Passo 4: Registro, Passo 5:
Finalização da configuração.
Após seguir os 5 passos, é possível efetuar o login no sistema através do
endereço http://localhost/otrs/index.pl.
A Figura 18 abaixo mostra a tela de login do sistema OTRS.
62
Figura 18: Tela de login do OTRS
Fonte: Próprio autor
Logo após efetuar o login, é possível ver a página inicial do sistema, ainda
sem nenhuma configuração ou particularidade específica.
A Figura 19 abaixo mostra essa tela, incialmente exibindo o Painel de controle
da ferramenta.
Nesse ponto não é exibida nenhuma informação sobre os tickets,
pois é uma instalação nova.
63
Figura 19: Tela inicial do OTRS
Fonte: Próprio autor
64
5.2.3.3 Customização do OTRS
O OTRS é completamente personalizável de acordo com a necessidade do
negócio, sendo possível customizar as filas de atendimento de acordo com o tipo
dos tickets, outro exemplo é a possibilidade de customização do leiaute de todo o
sistema, alterando assim todo a parte visual. A tarefa de customização do OTRS se
baseia no modelo proposto no que foi discutido e levantado ao longo deste capitulo
e consiste em implementar no sistema a forma como são tratados os problemas
reportados. É necessário mapear por meio da forma de controle atual quais são os
dados relevantes que deveram ser armazenados pelo OTRS.
Essa tarefa exige um conhecimento mais apurado e avançado sobre a
ferramenta, mas toda esse tipo de customização é suportado pelo manual de
utilização do OTRS. Outra tarefa necessária é a criação de filas de atendimento no
OTRS para agrupar as demandas de cada um dos processos a serem gerenciados,
dentro das filas é possível ter grupos de atendimento que podem ficar responsáveis
por atendimentos de determinadas naturezas, por exemplo, uma fila de Problemas e
atendendo essa fila poder-se-ia ter um grupo de usuários agrupados chamada de
Grupo Conectividade ou Grupo de Internas.
Para a integração com os demais sistemas já utilizados, o OTRS disponibiliza
algumas integrações através de Serviços de Web (Web Services), sendo assim, é
possível consumir as informações do OTRS através dos outros sistemas.
5.2.3.4 Fila de abertura de chamados
Um recurso interessante do OTRS é a possibilidade de visualização dos
chamados por filas, pois é possível ver os chamados de maneira organizada e
agrupada.
Conforme já dito anteriormente, é possível criar várias filas de atendimento no
OTRS e associar usuários e grupo de usuários as mesmas, também é possível
subclassificar essas filas de modo que possa haver separação de chamados
(tickets) também pela subclassificação dessa fila. Por exemplo, caso existisse uma
fila chamada “Atendimento de 2º Nível”, seria possível subclassificar os chamados
dessa fila com várias subclassificações, que poderiam ser chamadas de
“Atendimento de 2º Nível: Internet”, “Atendimento de 2º Nível: Rede interna”,
“Atendimento de 2º Nível: Impressoras”, etc., e então os chamados poderiam ser
organizados com mais facilidade e coerência. A Figura 20 abaixo ilustra como seria
algumas filas de atendimento criadas no OTRS:
65
Figura 20: Exemplo de uma fila de atendimento e suas subclassificações
Fonte: Próprio autor
66
Como pode ser observado na Figura 20 apresentada acima, existe uma fila
criada no OTRS com o nome de “Segundo Nível”. Essa fila possui as
subclassificações: “Internet”, “Impressoras”, “Email”, “Rede interna”. A figura retrata
exatamente a fila “Segundo nível::Rede interna” (Nome da fila e o nome de sua
subclassificação atual), onde está selecionado o ticket “Ticket#: 2013050840000029
– sem acesso a servidores”.
5.2.3.5 Chamados (Tickets)
Os chamados são exibidos em suas respectivas filas conforme vão sendo
abertos, a Figura 20 mostra a fila de chamados “Segundo nível::Rede interna” e
destacado na cor laranja é exibido o chamado “Ticket#: 2013050840000029 – sem
acesso a servidores”. Ao selecionar esse chamado, o sistema á redirecionado para
outra tela onde é mostrado o detalhamento das informações do chamado. A Figura
21 mostra os dados do chamado “Ticket#: 2013050840000029 – sem acesso a
servidores”.
67
Figura 21: Detalhamento do chamado "Ticket#: 2013050840000029 – sem acesso a servidores"
Fonte: Próprio autor
68
5.2.3.5.1 Resposta aos chamados
Após detalhar o chamado “Ticket#: 2013050840000029 – sem acesso a
servidores” conforme apresentado nas sessões anteriores, a ação de responde-lo
com algum teor informativo ao usuário solicitante acontece por meio da
funcionalidade “—Responder--” que aparece na Figura 21 logo acima do
detalhamento do chamado. Essa funcionalidade é apresentada no formato de
“Combobox” clicável que, ao ser acionada, exibe alguma opções de resposta que
podem ser predefinidas. Essas respostas podem seguir algum script de atendimento
que atendem a algum padrão específico de resposta, sendo assim, poderíamos ter
mensagem de sucesso na solicitação ou de falha, não se limitado a apenas essas
duas opções.
A Figura 22 exibida na próxima página ilustra os dados de resposta de um
chamado, partindo do princípio que o seu atendimento tenha tido sucesso.
69
Figura 22: Respondendo a o chamado " Ticket#: 2013050840000029 – sem acesso a servidores "
Fonte: Próprio autor
70
Conforme pode ser observado na Figura 22 exibida acima, existe um
formulário a ser preenchido contendo o teor da mensagem a ser enviada ao
solicitante.
Nessa resposta é possível se anexar imagens ou arquivos que podem
complementar as informações de resposta do chamado.
5.2.3.5.2 Fechamento de chamados
Conforme explicado no tópico anterior, é possível responder aos chamados
usando alguns modelos predefinidos de resposta.
Dependendo do tipo de reposta do chamado, em outras palavras, se a
resposta do chamado for uma reposta final e definitiva e não necessitará de
nenhuma outra resposta ou feedback do usuário solicitante, é possível encerrar o
atendimento logo após realizar a resposta. Para isso, é necessário acionar o botão
“Fechar” que é exibido no detalhamento do chamado conforme mostra a Figura 21.
O botão Fechar fica localizado no menu superior da tela de detalhamento, logo
acima dos dados detalhados do chamado, fica logo ao lado dos botões Monitorar e
Modificar fila.
A Figura 23 exibida abaixo mostra o conteúdo da tela de fechamento do
chamado
71
Figura 23: Formulário de fechamento do chamado
Fonte: Próprio autor
72
A Figura 23 acima mostra o formulário de fechamento do chamado, possui
informações sobre o sucesso ou o não sucesso do atendimento, também possui a
possibilidade de anexos para enriquecer o detalhe das informações a respeito do
atendimento.
É possível também acessar o FAQ para se obter alguma outra informação
especifica na base de conhecimento.
5.2.3.5.3 O FAQ do OTRS
O FAQ é uma das grandes funcionalidades do OTRS, dispondo de uma
grande vantajosa tecnologia para indexação de conteúdo em relação aos tickets
abertos no sistema. Ela permite a construção de uma rica, poderosa e flexível base
de conhecimento que pode ser acessada facilmente tanto pelos clientes que abrem
os tickets quando pelos atendentes que os fecham.
Entre as vantagens na utilização do FAQ, é possível citar que o seu uso
flexível permite a fácil inserção de artigos dentro do tickets, ele pode ser
disponibilizado em múltiplos idiomas, tem suporte completo a linguagem HTML
(multimídia, tags HTML, iframe, etc), tem um controle de permissão flexível podendo
controlar o acesso por agentes, clientes e acesso público, possui uma pesquisa
poderosa, tem a interface customizavel, tem histórico para todos os artigos criados,
etc.
O uso do FAQ facilita, enriquece e agiliza o processo para a descoberta de
soluções para problemas conhecidos, ajuda a construir conhecimento acerca de
problemas de complexa resolução e que demanda muitas horas de manutenção e
estudo, sem contar que ele é fundamental para se conseguir a implementação do
processo para o gerenciamento do conhecimento.
73
6 CONCLUSÕES E TRABALHOS FUTUROS
6.1
Conclusões
A utilização das boas práticas de ITIL tem trazido às empresas melhorias
consideráveis em seus serviços de TI, porém estas por si só não trazem benefícios,
elas apenas orientam como devem ser definidos e direcionados os processos de TI,
é necessário também haver pessoas e ferramentas alinhadas. A harmonia entre
esses três fatores é fundamental para o sucesso das mudanças propostas pelo ITIL,
principalmente o fator humano, o mais imprevisível dos três. Por esse motivo é
importante o investimento em processos, ferramentas e principalmente nas pessoas.
Na etapa de coleta de dados, durante as duas etapas de entrevistas foi
observada a forma de trabalho, o raciocínio lógico dos técnicos que realizam os
atendimentos e os procedimentos envolvidos, também foram identificados os
processos de trabalho relacionados ao tema e por último foi analisado e criticado o
sistema utilizado para registrar incidentes. Como resultado destes levantamentos foi
possível avaliar e criticar os três fatores, já citados anteriormente, que influenciam as
mudanças nas organizações. Contanto com suas premissas e restrições foi possível
propor em melhorias e adaptações, baseado no ambiente organizacional e na forma
de trabalho da empresa.
O primeiro fator observado na pesquisa foi a falta de definição quanto à
diferença entre problemas e incidentes, pois todos são tratados na mesma forma,
tanto pelas pessoas como pela ferramenta de trabalho, a RTP, ferramenta utilizada
para controlar os incidentes, conforme já abordado no desenvolvimento desta
pesquisa. No sistema de registro de incidentes e problemas, é possível observar
falhas no processo de registro dos mesmos, onde não existe um tratamento
adequado
para
as
informações
neles registradas,
impossibilitando
futuros
levantamentos e consultas a informações de apoio a gestão e por consequência ao
Gerenciamento de Problemas.
Como não foram identificados processos claros e definidos para o
Gerenciamento de Problemas, foi necessário mapear todas as atividades deste
processo comparando-as à realidade da Peixe Bola, sendo assim, a última proposta
foi a criação de um processo de Gerenciamento de Problemas apoiado pelo uso do
OTRS, que se comunique com as ferramentas hoje existente, separando problemas
de incidentes.
74
O desenvolvimento desta pesquisa trouxe benefícios para a empresa
pesquisada, para o pesquisador e para os estudos do Gerenciamento de Problemas
do ITIL.
Para a empresa trouxe informações e análises da situação atual do
tratamento de problemas e também a proposição de um processo de trabalho para o
mesmo, podendo a partir desta monografia surgir a criação de um projeto específico
de Gerenciamento de Problemas.
Para o pesquisador foi possível colocar em prática e desenvolver os
conhecimentos em ITIL e governança de TI adquiridos durante o curso de Pós
Graduação e também nas pesquisas em livros, documentos, artigos e nas etapas de
coleta de dados. Para os estudos sobre o tema, proporcionou-o um modelo que
pode servir de base para as empresas que pretendem mapear o processo de
Gerenciamento de Problemas, apresentando a interação entre os demais processos
ITIL, desde o surgimento de um problema até a sua solução.
Com isto, os benefícios desta pesquisa, não se encerram somente com o fim
em si mesma, pois os conhecimentos adquiridos poderão ser aplicados em conjunto
com a utilização do OTRS para se obter um nível de gerenciamento de problemas
muito mais maduro e padronização, idealizado pelas boas práticas do ITIL, não
descartando a hipótese de utilizar o poder de gerenciamento do OTRS para os
outros processos do ITIL, que atualmente são feitos por outras ferramentas de
apoio.
6.2
Trabalhos Futuros
O processo de Gerenciamento de Problemas com um ferramenta existente é
apenas o primeiro passo, é possível avançar muito no sentido de melhorar o
gerenciamento desses serviços, sendo assim, uma aplicação que auxilie no
Gerenciamento de Problemas poderia ser considerada como um módulo dentro de
um Enteprise Resource Planning (ERP), que é um sistema que engloba uma grande
gama de soluções dentro de uma empresa, visando a sua organização de forma
completa, dessa forma será possível conseguir uma área de TI mais integrada ao
negócio, que presa pelo bom atendimento e entrega de serviços de qualidade aos
seus clientes, sejam eles internos ou externos, uniformemente.
75
7
REFERÊNCIAS E FONTES CONSULTADAS
ABNT - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. Apresentação de
relatórios técnico-científicos: NBR 10719. ABNT: Rio de Janeiro, 1989. 9 p.
ABNT - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. Gestão de
continuidade de negócios: Parte 1 - Código de Prática: ABNT NBR 159991:2007. Errata 1, de 01.02.2008. Rio de Janeiro, 2008.
ABNT - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. Informação e
documentação — Citações em documentos - Apresentação: ABNT NBR 10520.
ABNT: Rio de Janeiro, 2002. 7 p.
ABNT - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. Informação e
documentação — Livros e folhetos — Apresentação: ABNT NBR 6029. ABNT:
Rio de Janeiro, 2006. 14 p.
ABNT - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. Informação e
documentação — Referências - Elaboração: ABNT NBR 6023. ABNT: Rio de
Janeiro, 2002. 24 p.
ABNT - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. Informação e
documentação - Resumo - Apresentação: NBR 6028. ABNT: Rio de Janeiro,
2003. 2 p.
BEAL, Adriana; O sistema de informação como estratégia empresarial.
SP: Atlas, 2001.
CENTRO DE ESTUDOS SOBRE AS TECNOLOGIAS DA INFORMAÇÃO E DA
COMUNICAÇÃO - CETIC.br. Pesquisa sobre o uso das Tecnologias da
Informação e da Comunicação no Brasil 2008: TIC Domicílios e TIC Empresas
2008. Brasil, 2008. Disponível em: <http://www.cetic.br/tic/2008/index.htm>. Acesso
em: Outubro de 2010.
COLLINGWOOD, H.; A prova derradeira do valor das TI – Professor de Harvard
Revela Crescimento Real das Receitas.
Disponível: http://pt.scribd.com/doc/89683428/A-Prova-Derradeira-Do-Valor-Das-TI
Último acesso em Junho de 2013.
DESCARTES, R. DISCURSO DO MÉTODO: para bem conduzir a própria razão e
procurar a verdade nas ciências. São Paulo: Difel Difusão Européia do Livro,
1962. Disponível em: <http://www.consciencia.org/o-discurso-do-metodo-renedescartes>. Acesso em: Novembro de 2010.
FABRI, J. A.; L'ERARIO, A.; TRINDADE, A. L.; PESSÔA, M. S. P.; LAURINDO, F. J.
B. O Alinhamento Estratégico de Negócios e Tecnologia da Informação nos
Cursos de Computação, Administração e Engenharia de Produção.
Em XI CONGRESSO CIESC 2003- Congresso Ibero-Americano de educação
Superior em Comutação, 2003.
76
Disponível: http://lsm.dei.uc.pt/ribie/docfiles/txt20031212173410TCI20.pdf
Último acesso em Junho de 2013.
FERNANDES, Jorge Henrique Cabral. Protocolo de Estudo de Caso: Sistemas de
Informação de Missão Crítica em Organizações da Administração Pública
Federal: Sistemas, Informação e Comunicação. Programa de Formação de
Especialistas para a Elaboração da Metodologia Brasileira de Gestão de
Segurança da Informação e Comunicações - PFEMBGSIC. Curso de
Especialização em Gestão da Segurança da Informação e Comunicações:
2009/2011. Departamento de Ciências da Computação da Universidade de Brasília.
2010. 17 p.
FERNANDES, J. H. C. Metodologia de Pesquisas de Estudo de Caso no
Programa de Formação de Especialistas para o Desenvolvimento da Estratégia
e Metodologia Brasileira de Gestão de Segurança da Informação e
comunicações – PFEMBGSIC (Nota Técnica). Campus Universitário Darcy Ribeiro.
Instituto Central de Ciências, Fevereiro de 2010. 14 p.
FERNANDES, A. A.; ABREU V. F.; Implantando a governança de TI: da
estratégia à gestão dos processos e serviços (3a edição). RJ: Brasport, 2012.
GIL, ANTONIO CARLOS; Como elaborar projetos de pesquisa. (4ª edição). SP:
Atlas, 2006.
ITIL v3; Introduction to the ITIL Service Lifecycle. (1st edition). UK: OGC, 2007.
INFORM-IT; Foundations of ITIL V3. (1st edition). USA: Van Haren Publishing,
2007.
LOPEZ, André Ancona Porto. Diretrizes para o Desenvolvimento de Projetos de
Cunho Científico: GSIC050 (Notas de Aula). Curso de Especialização em Gestão
da Segurança da Informação e Comunicações: 2009/2011. Departamento de
Ciências da Computação da Universidade de Brasília. 2010. 24 p.
MAGALHAES, Ivan L.; PINHEIRO, Walfrido Brito. Gerenciamento de serviços de
TI na prática: uma abordagem com base na ITIL. RJ: Novatec, 2007.
O'BRIEN, James A.; Sistemas de Informação e as decisões gerenciais na era da
Internet. 3ª edição
SP: Saraiva, 2004.
OGC; Service Transition Book (ITIL). UK: The Stationery Office, 2007.
OGC; Service Operation Book (ITIL). UK: The Stationery Office, 2007.
OLIVEIRA, D.; Administração de processos: Conceitos, Metodologia, Práticas.
SP: Atlas, 2006.
OTRS, Admin Manual.; OTRS 3.2 Handbook. DE - Bad Homburg: OTRS AG, 2012.
Disponível: http://doc.otrs.org/3.2/en/html/
Último acesso em Julho de 2013.
77
PINHEIRO, W. B.; MAGALHÃES, I. L.; Gerenciamento de serviços de TI na
pratica, Uma Abordagem com base no ITIL. SP: Novatec, 2007.
RIBEIRO, A. L.; Resumo Acadêmico: uma tentativa de definição. In: Anais do IX
Congresso Nacional de Linguística e Filologia. Disponível:
http://www.filologia.org.br/ixcnlf/12/15.htm. Último acesso em Maio de 2011.
RICHARDSON, R. J.; Pesquisa Social: Métodos e Técnicas. SP: Atlas, 1999.
SALVADOR, Ângelo Domingos. Métodos e técnicas de pesquisa bibliográfica.
Porto Alegre: Sulina, 1978.
SANTOS, Izequias Estevam. Manual de Métodos e Técnicas de Pesquisa
Científica: TCC, Monografia, Dissertação, Tese. 5a Edição. Niterói - RJ: Impetus.
2007.
SANTIAGO JR., J. R. S.; Gestão do Conhecimento - A Chave para o Sucesso
Empresarial. (1a edição). SP: Novatec, 2004.
SANTOS, S. L.; LAURINDO, F. J.; Fatores de suporte ao aumento da
produtividade da Tecnologia da Informação. SP, Revista Gestão Industrial v01 n
03, 2005.
SILVA, Edilberto Magalhães. Avaliação da Governança de TI em um órgão
público federal: Nível de maturidade de processos e gerência de serviços de
TI. 2011. Monografia de Conclusão de Curso (Especialização) - Centro Nacional de
Educação a Distância do SENAC-RJ. Disponível em:
<http://www.edilms.eti.br/uploads/file/publicacoes/MONOGRAFIA_EdilbertoSilva_SE
NAC_240911-final-v4.pdf>. Acesso em: Maio de 2013
VARGAS, Lilia; MALDONADO, Gabriela (orgs). Guia Para a Apresentação de
Trabalhos Científicos. Programa de Pós-Graduação em Administração da Escola
de Administração da Universidade Federal do Rio Grande do Sul. Março de 2001.
Disponível: http://www.adm.ufrgs.br.
WIKIPEDIA; ITIL v3.
Disponível: http://pt.wikipedia.org/wiki/ITILv3
Último acesso em Junho de 2013.
YIN, R. K. Estudo de Caso: Planejamento e Métodos. 2. ed. Porto Alegre:
Bookman. 2001.
78
8
APÊNDICE A: PERGUNTAS APLICADAS NA PRIMEIRA E
SEGUNDA ETAPA DAS ENTREVISTAS
Quadro 11: Primeira etapa das entrevistas
Primeira Etapa de Entrevistas
Nome:
Setor:
Equipe:
Prezado colega.
Estou realizando o trabalho de conclusão do curso em Governança de TI no
SENAC. Escolhi com tema do trabalho o Gerenciamento de Problemas baseada
nas melhores práticas de ITIL. Com o objetivo de melhor entender a realidade da
Peixe Bola quanto aos problemas que mais se repetem pede-se:
Descrever quais são os problemas mais comuns que ocorrem no dia-a-dia
detalhando cada um com informações relevantes.
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
Fonte: Próprio autor
79
Quadro 12: Segunda etapa das entrevistas
Segunda Etapa de Entrevistas
Nome:
Setor:
Equipe:
Prezado colega.
Continuando o levantamento das informações para pesquisa do trabalho de
conclusão do curso em Governança de TI no SENAC. Neste momento perguntase qual a modelo lógico individual utilizado para identificar, diagnosticar e
resolver os cinco problemas mais frequentes identificados nos levantamentos
realizados até este momento.
Para equipe de Conectividade: Sem conectividade
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
Fonte: Próprio autor

Documentos relacionados