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