MODELO PARA AVALIAÇÃO COMPARATIVA DE FERRAMENTAS OPEN SOURCE BASEADAS NA ITIL PARA GERENCIAMENTO DE INCIDENTES EM MICRO E PEQUENAS EMPRESAS

Transcrição

1 1 INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA CATARINENSE - CAMPUS CAMBORIÚ CURSO DE SISTEMAS DE INFORMAÇÃO (BACHARELADO) JANIO LUIZ ANTUNES MODELO PARA AVALIAÇÃO COMPARATIVA DE FERRAMENTAS OPEN SOURCE BASEADAS NA ITIL PARA GERENCIAMENTO DE INCIDENTES EM MICRO E PEQUENAS EMPRESAS CAMBORIÚ (SC) 2013

2 2 JANIO LUIZ ANTUNES MODELO PARA AVALIAÇÃO COMPARATIVA DE FERRAMENTAS OPEN SOURCE BASEADAS NA ITIL PARA GERENCIAMENTO DE INCIDENTES EM MICRO E PEQUENAS EMPRESAS Trabalho de Conclusão de Curso apresentado como requisito para a obtenção do título de Bacharel em Sistemas de Informação do Instituto Federal Catarinense Campus Camboriú. Orientador: Profº. Aujor Tadeu Cavalca Andrade Camboriú (SC), Novembro de 2013

3 3 JANIO LUIZ ANTUNES MODELO PARA AVALIAÇÃO COMPARATIVA DE FERRAMENTAS OPEN SOURCE BASEADAS NA ITIL PARA GERENCIAMENTO DE INCIDENTES EM MICRO E PEQUENAS EMPRESAS Trabalho de Conclusão de Curso apresentado como requisito para a obtenção do título de Bacharel em Sistemas de Informação do Instituto Federal Catarinense Campus Camboriú. Camboriú, 18 de Novembro de BANCA EXAMINADORA: Profº. Aujor Tadeu Cavalca Andrade, M.Sc. Orientador Profª. Cátia dos Reis Machado, Dra. Profº. Cristian Koliver, Dr.

4 4 Dedico este trabalho aos meus pais e a minha amada esposa.

5 5 AGRADECIMENTOS Agradeço a DEUS, criador dos céus e da Terra, por me dar sabedoria e forças para seguir na minha infindável caminhada; Aos meus pais por sempre me incentivarem a estudar e lutar, com honestidade, por um futuro e uma vida cada vez melhor; A minha amada esposa por estar ao meu lado, me apoiando e incentivando na minha busca por bons resultados, mesmo em momentos de dificuldades em que estive ausente devido às viagens a eventos ou pelas noites em que fiquei estudando e não dei a ela a devida atenção. Obrigado por ser tão paciente e compreensiva meu amor; Ao meu grande amigo de longa data, Luiz Carlos Berlim, por nunca dizer não aos meus pedidos de ajuda, mesmo quando ocupado, e por sempre ter tempo para um café; Ao meu colega de turma, e agora amigo, Marcel Vinicius Kohls, por sempre ter me ajudado nas disciplinas que tive dificuldade, e por seus sábios conselhos na hora do café; A minha colega e também amiga, Juliana C. G. Rohrbacher, por ter compartilhado o seu conhecimento e enriquecido nossos trabalhos acadêmicos; A todos os professores do curso de Sistemas de Informação que, ao longo destes quatro anos, repassaram seus conhecimentos e proporcionaram diversos aprendizados; A profª Sônia Regina Lamego Lino por sempre ter um tempo para me ouvir e me aconselhar nas minhas escolhas, além de me incentivar a seguir meus sonhos profissionais; Ao profº Aujor Tadeu Cavalca Andrade, pelas seis disciplinas ministradas, pela orientação no projeto de pesquisa, pela orientação neste trabalho de conclusão de curso e, em especial, por todas as palavras de apoio e incentivo, que fizeram com que eu não desistisse mesmo nos piores momentos. Agradeço, também, por acreditar no meu potencial e sempre ter me apoiado e incentivado a seguir a carreia que desejo; Por fim, a todos familiares, amigos, colegas e demais pessoas que de alguma forma contribuíram com ideias, criticas e sugestões.

6 6 Se o conhecimento pode criar problemas, não é através da ignorância que podemos solucioná-los. Isaac Asimov

7 7 RESUMO O processo de gerenciamento de incidente é responsável pelo tratamento e pela resolução de todos os incidentes observados nos serviços de TI, minimizando os impactos decorrentes do efeito sobre o nível de serviço ou, até mesmo, da indisponibilidade total. O registro dos incidentes geram informações que podem ser utilizadas em diversas análises como, por exemplo, a carga de serviço dos técnicos e os equipamentos que mais apresentam defeitos. As micro e pequenas empresas têm forças de trabalho menores, orçamentos reduzidos e ambientes de TI menos complexos que os das organizações de maior porte, mas precisam atender aos mesmos tipos de demanda das outras organizações e otimizar os níveis de serviços de TI. A utilização de ferramentas de gerenciamento de incidentes permite avaliar o suporte de infraestrutura de TI nestas empresas, propiciando a obtenção de ROI por meio do aumento de produtividade, proporcionando melhoras nos resultados para a empresa, sejam eles tangíveis ou intangíveis. O objetivo deste trabalho é criar um modelo para avaliar ferramentas open source de gerenciamento de incidentes baseadas na ITIL, destinadas à micro e pequenas empresas, fazendo com que estas empresas possam optar pelo melhor investimento para sua infraestrutura. Por meio do estudo sobre a importância das métricas de ferramentas de gerenciamento de incidentes, foi desenvolvido o modelo para auxiliar os gestores das empresas a escolherem a ferramenta que melhor se adapta as suas necessidades, reduzindo esforços e recursos aplicados nesta atividade. Palavras-chave: Ferramentas de Gerenciamento de Incidentes; ITIL; open source; Micro e pequenas empresas.

8 8 LISTA DE ILUSTRAÇÕES Figura 1 Processos da Operação de Serviço Figura 2 Visão da ferramenta GLPI em funcionamento Figura 3 Visão da aplicação Ocomon em funcionamento Figura 4 Visão da aplicação OTRS em funcionamento Figura 5 Visão da aplicação Quaizer em funcionamento Figura 6 Visão da ferramenta Trellis Desk em funcionamento Figura 7 Exemplo do fluxo das questões na pesquisa Figura 8 Tela de apresentação da pesquisa Figura 9 Elaboração do gabarito (etapa 1) Figura 10 Elaboração do gabarito (etapa 2) Figura 11 Elaboração do gabarito (etapa 3) Figura 12 Avaliação comparativa (etapa 1) Figura 13 Avaliação comparativa (etapa 2) Figura 14 Modelo de avaliação comparativa para FGI Figura 15 Apêndice E Fluxo das questões 01 a Figura 16 Apêndice E Fluxo das questões 19 a Figura 17 Apêndice E Fluxo das questões 34 a Figura 18 Apêndice F Tela de apresentação da pesquisa Figura 19 Apêndice F Tela de cadastro de dados e questão Figura 20 Apêndice F Questões 2 a Figura 21 Apêndice F Questões 5 a Figura 22 Apêndice F Questões 8 a Figura 23 Apêndice F Questões 12 a Figura 24 Apêndice F Questões 14 a Figura 25 Apêndice F Questões 17 a Figura 26 Apêndice F Questões 20 a Figura 27 Apêndice F Questões 23 a Figura 28 Apêndice F Questões 26 a Figura 29 Apêndice F Questões 30 a Figura 30 Apêndice F Questões 35 a Figura 31 Apêndice F Questão 39 e finalização da pesquisa

9 9 LISTA DE GRÁFICOS E QUADROS Gráfico 1 Estatísticas de acesso à pesquisa Quadro 1 Estrutura Organizacional e ITIL Quadro 2 Etapas do gerenciamento de incidentes e respectivos procedimentos Quadro 3 Classificação das MPE de acordo com o número de empregados Quadro 4 Categorias, Produtos e Problemas Quadro 5 Perfil x Nível x Categoria Quadro 6 Formato de apresentação das métricas Quadro 7 Exemplos de incidentes utilizados nos testes Quadro 8 Métricas da categoria interface presentes nas ferramentas Quadro 9 Exemplo de métricas presentes em todas as ferramentas Quadro 10 Exemplo de Métricas não presentes nas ferramentas Quadro 11 Apêndice A Quadro de categorias, produtos e problemas Quadro 12 Apêndice A Quadro de categorias, produtos e problemas (continuação) Quadro 13 Apêndice B Avaliação com base nas métricas Quadro 14 Apêndice B Avaliação com base nas métricas (continuação) Quadro 15 Apêndice B Avaliação com base nas métricas (continuação) Quadro 16 Apêndice B Avaliação com base nas métricas (continuação) Quadro 17 Apêndice C Métricas presentes em todas as FGI Quadro 18 Apêndice D Métricas não presentes nas FGI

10 10 LISTA DE TABELAS Tabela 1: Dados referentes ao perfil das empresas dos participantes da pesquisa Tabela 2: Integração com sistemas de diretórios Tabela 3: Atendimento de mais de uma empresa Tabela 4: Limitação de cadastro de clientes, usuários e técnicos Tabela 5: Métricas mais relevantes Tabela 6: Apêndice G Integração com sistemas de diretórios Tabela 7: Apêndice G Atendimento de mais de uma empresa Tabela 8: Apêndice G Limitação de cadastro de clientes, usuários e técnicos Tabela 9: Apêndice G Idioma da FGI Tabela 10: Apêndice G Idioma da FGI Tabela 11: Apêndice G Compatibilidade com browsers Tabela 12: Apêndice G Compatibilidade com dispositivos móveis Tabela 13: Apêndice G Personalização através de módulos Tabela 14: Apêndice G Gerenciamento de inventário Tabela 15: Apêndice G Limitação de chamados Tabela 16: Apêndice G Acessos simultâneos Tabela 17: Apêndice G Tipos de suporte Tabela 18: Apêndice G Relatórios Tabela 19: Apêndice G Dashboard Tabela 20: Apêndice G Pesquisas de satisfação Tabela 21: Apêndice G Tipo de chamado Tabela 22: Apêndice G Associações aos chamados Tabela 23: Apêndice G Autoatendimento Tabela 24: Apêndice G Registros de atendimento Tabela 25: Apêndice G Histórico completo Tabela 26: Apêndice G Feedback Tabela 27: Apêndice G Gerenciamento de SLA Tabela 28: Apêndice G Fluxos de aprovação configuráveis Tabela 29: Apêndice G Escalonamento de incidentes Tabela 30: Apêndice G Scripts de atendimento Tabela 31: Apêndice G Controle de prioridades de atendimento Tabela 32: Apêndice G Agendamento de abertura de chamados Tabela 33: Apêndice G Contabilização de despesas de atendimento Tabela 34: Apêndice G Campos adicionais Tabela 35: Apêndice G Confirmação de encerramento de chamados Tabela 36: Apêndice G Restrição de acesso aos chamados Tabela 37: Apêndice G Mensageria Tabela 38: Apêndice G Chamados como parte de projetos Tabela 39: Apêndice G Atendimento online através de chat Tabela 40: Apêndice G Gestão do conhecimento Tabela 41: Apêndice G Alimentar a base de conhecimento (GC) Tabela 42: Apêndice G Compatibilidade da FGI com a ITIL

11 Tabela 43: Apêndice H Categorização de relevância das métricas Tabela 44: Apêndice H Categorização de relevância das métricas (continuação) Tabela 45: Apêndice H Categorização de relevância das métricas (continuação) Tabela 46: Apêndice I Gabarito usado no modelo de avaliação de FGI Tabela 47: Apêndice I Gabarito usado no modelo de avaliação de FGI (continuação)

12 12 LISTA DE ABREVIATURAS E SIGLAS AD Active Directory AJAX Asynchronous Javascript and XML ANAC Agência Nacional de Aviação Civil ASP Active Server Pages BSD Berkeley Software Distribution CCTA Central Communications and Telecom Agency CMMI Capability Maturity Model COBIT Control Objectives for Information and related Technology EFQM European Foundation for Quality Management escm-sp esourcing Capability Model for Service Providers FAPESP Fundação de Amparo à Pesquisa do Estado de São Paulo FAQ Frequently Asked Questions FGI Ferramenta de Gerenciamento de Incidentes FTP File Transfer Protocol GB Giga Bytes GHz Giga Hertz GITIM Government Information Technology Infrastructure Management GLPI Gestion Libre de Parc Informatique GPL General Public License HD Hard Disk HDI Help Desk Institute HSBC Hong Kong and Shanghai Banking Corporation HTML HyperText Markup Language HTTP Hypertext Transfer Protocol IBGE Instituto Brasileiro de Geografia e Estatísticas IBM International Business Machines IFPA Instituto Federal do Pará IEC International Electrotechnical Commission ISO International Organization for Standardization ITIL Information Technology Infrastructure Library

13 13 LDAP MB MIT MS MTE MPE NASA OGC OTRS PCMG PERL PHP PMBOK RAIS RAM ROI RPM RSS SEBRAE SLA SP SPOC SQL TGZ TI TJES UEG ULBRA VM XML WWW Lightweight Directory Access Protocol Mega Bytes Massachusetts Institute of Technology Microsoft Ministério do Trabalho e Emprego Micro e Pequena Empresa National Aeronautics and Space Administration Office of Government Commerce Open source Ticket Request System Polícia Civil de Minas Gerais Practical Extraction And Report Language Hypertext Preprocessor Project Management Body of Knowledge Relação Anual de Informações Sociais Random Access Memory Return On Investment Red Hat Package Manager Really Simple Syndication Serviço Brasileiro de Apoio às Micro e Pequenas Empresas Service Level Agreement Service Pack Single Point of Contact Structured Query Language Tape Archive Gzipped File Tecnologia da Informação Tribunal de Justiça do Estado do Espirito Santo Universidade Estadual de Goiás Universidade Luterana do Brasil Virtual Machine extensible Markup Language World Wide Web

14 14 SUMÁRIO 1 INTRODUÇÃO Apresentação Descrição do problema Justificativa Objetivo geral Objetivos específicos Metodologia REVISÃO BIBLIOGRÁFICA ITIL Operação de Serviço Central de serviços Estrutura organizacional Níveis de suporte Gerenciamento de incidente Modelos de incidentes ou scripts de incidentes Escalonamento de incidentes Prioridade de incidentes Gravidade ou severidade de incidentes Software Open Source Micro e Pequenas Empresas DESCRIÇÃO CENÁRIO PARA REALIZAÇÃO DOS TESTES Definição do ambiente Base Categorias Base Perfis Preparação do ambiente FERRAMENTAS SELECIONADAS GLPI Gestion Libre de Parc Informatique Ocomon OTRS Open source Ticket Request System Quaizer Trellis Desk CONCEPÇÃO DO MODELO DE AVALIAÇÃO DE FGI Métricas Definição de métricas Seleção das métricas Comparativo entre as ferramentas Implantação das ferramentas Avaliação comparativa com base nas métricas Pesquisa para Avaliação das Métricas Definição da pesquisa Aplicação da pesquisa... 78

15 Tabulação e análise dos dados MODELO PARA AVALIAÇÃO COMPARATIVA DE FGI Elaboração do gabarito Avaliação comparativa Considerações sobre o modelo CONCLUSÃO TRABALHOS FUTUROS REFERÊNCIAS BIBLIOGRÁFICAS APÊNDICE A QUADRO DE CATEGORIAS, PRODUTOS E PROBLEMAS APÊNDICE B AVALIAÇÃO COM BASE NAS MÉTRICAS APÊNDICE C MÉTRICAS PRESENTES EM TODAS AS FGI APÊNDICE D MÉTRICAS NÃO PRESENTES NAS FGI APÊNDICE E FLUXO DE TODAS AS QUESTÕES DA PESQUISA APÊNDICE F QUESTÕES DA PESQUISA NO GOOGLE DOCS APÊNDICE G TABULAÇÃO E ANÁLISE DOS DADOS APÊNDICE H CATEGORIZAÇÃO DE RELEVÂNCIA DAS MÉTRICAS APÊNDICE I TABELA GABARITO

16 16 1 INTRODUÇÃO 1.1 Apresentação A crescente complexidade dos sistemas de informação utilizados pelas empresas, aliada à necessidade de rápida adaptação às demandas do negócio, gera dificuldades consideráveis para a gestão efetiva dos serviços e estrutura de Tecnologia da Informação. Tal fato indica, para as empresas, a necessidade de uma estrutura bem definida de processos e procedimentos, organizados em disciplinas, que orientam o uso dos recursos tecnológicos e humanos disponíveis, visando à qualidade dos serviços prestados e à promoção do alinhamento da TI ao negócio. A ITIL (Information Technology Infrastructure Library) consiste no modelo de gerenciamento de processos de TI (Tecnologia da informação), sendo uma referência reconhecida e recurso mais aceito mundialmente. Sua estrutura foi criada na Inglaterra pela OGC (Office of Government Commerce), antiga secretaria do comércio do governo inglês. É o conjunto de processos, normas e orientações que reúne as melhores práticas para se adotar no gerenciamento dos serviços de TI em uma organização. O gerenciamento de incidentes tem como foco principal restabelecer o serviço o mais rápido possível, minimizando o impacto negativo no negócio, podendo ser por meio de uma solução de contorno, fazendo com que o cliente volte a trabalhar de modo alternativo. Um incidente é definido como uma interrupção não planejada ou diminuição da qualidade de um serviço de TI.

17 17 É, também, uma tarefa da gerência de incidentes garantir que os melhores níveis de disponibilidade e de qualidade dos serviços sejam mantidos, conforme os acordos de nível de serviço. Assim, é importante que o gerenciamento de incidentes conheça e seja informado de quaisquer mudanças que ocorram na estrutura da empresa. Existem trabalhos com temas semelhantes a este, porém o principal foco dos outros autores é efetuar o levantamento de apenas uma ferramenta open source para gerenciamento de incidentes baseado na ITIL, aplicando em casos específicos, mas estes autores não realizam o comparativo entre as ferramentas de gerenciamento de incidentes (FGI) disponíveis no mercado para ver qual se adapta melhor às suas necessidades. O capítulo 2 deste trabalho apresenta a revisão bibliográfica, que aborda as definições dos conceitos utilizados, como a metodologia ITIL e outros conceitos provenientes desta biblioteca, além de outras definições. O capítulo 3 apresenta a descrição do cenário para a realização dos testes, abordando conceitos e descrevendo a preparação do ambiente. O quarto capítulo apresenta um levantamento de cinco FGI disponíveis para uso, sendo que todas são open source. Após a apresentação das características de cada FGI, o capítulo 5 apresenta as etapas para a concepção do modelo de avaliação de FGI, aonde serão definidas as métricas para a avaliação, que serão aplicadas em uma pesquisa e, após a tabulação dos dados, será realizado o comparativo entre as FGI. O capítulo 6 apresenta a descrição do modelo desenvolvido. O capítulo 7 apresenta a conclusão deste trabalho e o capítulo 8 apresentas as propostas para trabalhos futuros. 1.2 Descrição do problema As micro e pequenas empresas enfrentam problemas e desafios gerenciais de natureza diferente dos problemas das empresas maiores. Em geral, têm forças de trabalho menores, orçamentos reduzidos e ambientes de TI menos complexos que os das organizações de maior porte. Além disso, as micro e pequenas empresas precisam

18 18 atender aos mesmos tipos de demanda das outras organizações e otimizar os níveis de serviços, para atingir os objetivos comerciais, controlar custos e ajustar o departamento de TI às necessidades da empresa. É necessário, então, que estas empresas se adaptem a modelos de boas práticas de gestão, visando a melhoria na prestação de serviço de TI e obtendo o retorno sobre o investimento realizado com essa adequação. Esta adaptação favorece a utilização de FGI, pois sua utilização permite avaliar (qualificar e quantificar) o suporte de infraestrutura de TI, como o Service Desk. A avaliação do Service Desk propicia a obtenção de ROI (retorno de investimento) por meio do aumento de produtividade ou de melhoria de processo, em que ocorre a otimização dos investimentos, proporcionando melhoras nos resultados para a empresa, sejam eles tangíveis ou intangíveis. 1.3 Justificativa Conforme a 24ª Pesquisa Anual do Uso de TI, realizada por Meirelles (2013) da Fundação Getúlio Vargas, as empresas gastam e investem 7,2% do faturamento líquido em TI, valor que triplicou em 18 anos. É fundamental a utilização de metodologias e modelos para gerir tais investimentos em uma área estratégica para qualquer negócio. Quando uma empresa se adapta a um modelo de gerenciamento, ela obtém maior visibilidade no setor em que atua e também consegue um melhor acompanhamento da área de TI quando há o crescimento desta empresa. A migração de software proprietário para software open source em instituições públicas e empresas privadas, não é mais simplesmente um modismo, mas uma realidade há aproximadamente uma década. Como softwares open source não possuem custo de licença, é possível investir mais em serviços e treinamentos, e assim, garantir melhor o retorno dos investimentos em TI. Software proprietário, embora às vezes possa ser distribuído gratuitamente, não permite modificações em seu código para adaptar a uma necessidade específica.

19 19 Deve-se, então, sempre esperar o lançamento da próxima versão e torcer para que venha com melhorias significativas, o que nem sempre acontece. Já os softwares open source ou código aberto, por sua vez, são distribuídos gratuitamente e permitem a modificação do seu código original. Isto facilita, a quem desejar, agregar funcionalidades específicas que o software ainda não faz ou corrigir erros existentes, proporcionando economia às empresas devido ao fato de não ter que pagar os valores cobrados pelas licenças dos softwares proprietários que, para as micro e pequenas empresas, é um valor significativo de seu orçamento. Ao implementar a ITIL em uma organização, a área de TI não é mais vista como um departamento, mas sim como parte integrante do negócio. Conforme Palma (2009), podem ser citados como exemplos das vantagens da aplicação da ITIL: Benefícios para o Negócio: As práticas definidas pela ITIL refletem em processos de negócio eficientes, com maior garantia de qualidade, produtividade e crescimento, pois o gerenciamento efetivo dos serviços de tecnologia é considerado uma questão de sobrevivência da empresa; Benefícios Financeiros: Os objetivos do processo de gerenciamento de problemas são eliminar tendências de incidentes, diminuir custos de incidentes e prevenir incidentes futuros. Assim, é possível obter um maior retorno financeiro sob a utilização dos serviços de tecnologia além de justificar melhor os gastos em infraestrutura de TI. Benefícios de Inovação: A gestão de serviços de TI, quando bem aplicada, traz maior transparência e compreensão para a empresa, o que possibilita uma maior facilidade de mudar processos para obter melhorias. Benefícios para os profissionais: Os benefícios que podem ser obtidos pelos profissionais ao aplicar as boas praticas ITIL são: motivação (visão de que as coisas funcionam bem e de forma organizada), produtividade (garantia de que existem recursos

20 20 suficientes para execução de atividades) e transparência (possibilita o conhecimento do funcionamento de outros setores e o profissional é treinado, educado e conhece padrões que são rigorosamente seguidos). Considerando que a área de TI é essencial em uma estrutura organizacional, a ITIL propõe abranger a coordenação de todos os segmentos. A FGI sugere a medição de níveis de serviços e de metas, assim é possível saber o que se tem e o que é necessário melhorar, possibilitando à empresa obter o retomo sobre o investimento realizado na TI. Estudo realizado pelo MIT (Massachusetts Institute of Technology) com 250 empresas em 23 países revelou que as empresas com governança de TI, melhores do que a média, conseguem um retorno pelo menos 20% maior sobre seus bens do que as organizações com uma governança mais fraca (NEXT GENERATION CENTER, 2013). Gartner (2012 apud COMPUTERWORLD, 2012), declara que sem gestão adequada, as empresas não investirão em TI. Tecnologias, sozinhas, não geram resultados se não forem implementadas em conjunto com processos e estratégia. Por fim, a avaliação comparativa das FGI permite a escolha da que melhor atende as necessidades do negócio, além de propor a redução de gastos por meio do gerenciamento do conhecimento sobre os incidentes. No sentido do direcionamento correto de investimentos na área da TI para que se possa tratar o gerenciamento dos incidentes de maneira proativa, e não reativa como é feito pela maioria das empresas. 1.4 Objetivo geral O objetivo deste trabalho é criar um modelo para avaliar ferramentas open source de gerenciamento de incidentes baseadas na ITIL, destinadas à micro e pequenas empresas, que desejem adequar-se ao modelo das boas práticas de TI, fazendo com que estas empresas possam optar pelo melhor investimento e conhecimentos sobre os processos (fluxo informacional e financeiro).

21 Objetivos específicos Para este trabalho, têm-se como objetivos específicos: a) Definir as principais métricas a serem avaliadas nas FGI; b) Obter as FGI open source que estão disponíveis para uso comercial; c) Definir o ambiente e realizar os testes com as FGI selecionados; d) Criar o modelo de avaliação para FGI open source para gerenciamento de incidentes; e) Gerar base de conhecimento financeiro e informacional da organização. 1.6 Metodologia Este projeto está alinhado em três etapas: descrição da pesquisa e bibliografia; definição das FGI e métricas, e aplicação de pesquisa com gestores de TI; e avaliação das informações para o desenvolvimento do modelo, respectivamente. Na descrição da pesquisa é realizado todo o levantamento bibliográfico referente ao tema ITIL, envolvendo gerenciamento de incidentes e Central de Serviços e, também, a descrição de softwares open source e a definição de micro e pequenas empresas. Na segunda etapa, é realizado o levantamento das métricas para avaliação das FGI; a listagem do conjunto de FGI open source, sendo que sua utilização é baseada nos critérios previamente estabelecidos na primeira etapa e a criação do ambiente de testes para a instalação das FGI selecionadas. Em paralelo, ainda na segunda etapa, é realizada a pesquisa com os gestores de TI para identificar a relevância das métricas elencadas nesta etapa. Na terceira etapa, é realizada a criação do modelo de avaliação para FGI, definindo sua utilização com base nos estudos realizados nas etapas anteriores. Ao final deste trabalho, são apresentadas as conclusões e propostas para trabalhos futuros.

22 22 2 REVISÃO BIBLIOGRÁFICA Este capítulo apresenta a revisão bibliográfica realizada para fundamentação teórica deste trabalho. Na primeira seção deste capítulo, será apresentado o conceito de ITIL. A segunda seção aborda a definição de operação de serviço e a terceira seção apresenta a central de serviço. O gerenciamento de incidentes é apresentado na quarta seção. A definição de software open source é apresentada na quinta seção e a sexta seção apresenta a classificação de micro e pequenas empresas. 2.1 ITIL A biblioteca ITIL foi desenvolvida no final da década de 1980 pela CCTA (Central Communications and Telecom Agency), atual OGC, órgão responsável pela evolução e divulgação da ITIL. Seu desenvolvimento foi um esforço para disciplinar e permitir a comparação entre as propostas dos diversos proponentes e prestadores de serviço de TI para o governo britânico, que não estava satisfeito com o nível de qualidade dos serviços de TI prestados a ele (MAGALHÃES & PINHEIRO, 2007; MELENDEZ FILHO, 2001; LUNA, 2011). Em sua primeira versão, a ITIL era composta de aproximadamente 40 livros. Daí o fato de ser conhecida por biblioteca. Esta primeira versão era bastante diferente da versão atual, publicada em 2011 e apresentada no decorrer desta seção, e era conhecida como GITIM (Government Information Technology Infrastructure Management). Como a ITIL foi concebida como um padrão aberto e, sobretudo, pelo grande enfoque em qualidade, passou a ser adotada pelas organizações europeias

23 23 privadas, durante a década de Sua garantia pela definição de processos e a proposição das melhores práticas para o gerenciamento de serviços de TI, que viabilizavam a sua aderência a ISO 9000 e ao modelo de referencia EFQM (European Foundation for Quality Management), fez com que a ITIL passasse a ser adotada, também, pelos países da América do Norte, tornando-se o padrão da atualidade no seguimento de TI. Dentre os fatores motivadores pela adoção das práticas reunidas na ITIL, pode-se citar o incremento dos seguintes aspectos (MAGALHÃES e PINHEIRO, 2007): Custos de entrega e manutenção dos serviços de TI; Requerimentos da organização em relação à qualidade e ao custo/beneficio dos serviços de TI; Demanda em obter a medição do retorno dos investimentos em TI; Complexidade da Infraestrutura de TI; Ritmo de mudanças nos serviços de TI; Necessidades de disponibilidade dos serviços de TI; Aspectos relacionados com segurança. Entre 2000 e 2002, a biblioteca sofreu uma completa revisão e reformulação, sendo as práticas reunidas em oito volumes principais, também chamados de livros, conforme relação a seguir, passando a ser conhecida como a versão 2 da ITIL. Suporte aos Serviços (Service Support); Entrega de Serviços (Service Delivery); Planejamento e Implementação (Planning and Implemention); Gerenciamento de Aplicações (Applications Management); Gerenciamento da Segurança (Security Management); Gerenciamento da Infraestrutura de TI e Comunicações (Information and Communication Technology Infrastructure Management); Perspectiva do Negócio (Business Perpective);

24 24 Gerenciamento dos Ativos de Software (Software Asset Management); Mesmo que cada livro da biblioteca seja lido e implementado separadamente, a otimização ocorre quando cada processo é considerado como parte de um todo (ITSMF, 2008). Em maio de 2007, foi lançada a versão 3 da ITIL (denominada V3). Esta versão representa uma grande evolução em relação a versão 2, pois organiza os processos de gerenciamento de serviços em uma estrutura de ciclo de vida de serviço, além de trazer e enfatizar conceitos como integração da TI ao negócio e mensuração de valor ao negócio, demonstrando a maturidade que a disciplina de gerenciamento de serviços adquiriu ao longo do tempo (FERNANDES & ABREU, 2012). A ITIL V3 incorpora todo o conhecimento da versão anterior em cinco livros, que abordam o ciclo de vida do gerenciamento de serviços de TI (MELENDEZ FILHO, 2011): Estratégia de Serviços (Service Strategy); Desenho de Serviço (Service Design); Entrega de Serviços (Service Delivery); Operação de Serviços (Service Operation); Melhoria Contínua de Serviço (Continual Service Improvement) A ITIL fornece, também, uma base sólida para a convergência com outros padrões e modelos de gestão e governança, tais como ISO/IEC 20000, COBIT, CMMI, PMBOK, escm-sp, etc. Entre as extensões que a ITIL V3 traz em relação à versão anterior, estão estratégias de serviços para modelos de sourcing e de compartilhamento de serviços, abordagens de ROI (Return on investment) para serviços, práticas de desenho de serviços. Um sistema de gerenciamento de conhecimento sobre serviços e o gerenciamento de requisições. Em 2011 o OGC publicou uma atualização da ITIL V3, composta por mudanças relativamente leves, visando, sobretudo:

25 25 Corrigir alguns erros e inconsistências identificadas no texto, nas figuras e nos relacionamentos entre os cinco livros; Incorporar sugestões de melhorias e soluções de problemas apresentadas pela comunidade (usuários, fornecedores e instrutores), analisadas e recomendadas pelo Comitê de Controle de Mudanças e aprovadas pelo OGC, no sentido de aumentar a clareza, a consistência, a precisão e a completude; Revisar o livro de Estratégia de Serviço para tornar a explicação de alguns conceitos mais clara, concisa e acessível (FERNANDES e ABREU, 2012). As práticas da ITIL são compatíveis com várias modalidades de prestação de serviços de TI, tanto locais quanto remotas, que necessitem de uma forte abordagem de gestão. Não há uma predefinição dos processos que podem ser implementados dentro da TI, porém, é demonstrado por meio das melhores práticas o que pode ser utilizado para esta definição (MAGALHÃES e PINHEIRO, 2007). Pela ênfase dada aos aspectos tecnológicos e à sua abordagem de integração aos requisitos do negócio, Fernandes e Abreu (2012) afirmam que a ITIL tem sido bastante utilizada em projetos e operações contínuas envolvendo itens de infraestrutura, tais como manutenção de equipamentos, gerenciamento de redes, suporte à utilização de aplicações e outsourcing de processos de impressão, entre outros. 2.2 Operação de Serviço Neste livro da ITIL, está descrita a fase do ciclo de vida do gerenciamento de serviços que é responsável pelas atividades do dia a dia, orientando sobre como garantir a entrega e o suporte a serviços de forma eficiente e eficaz e detalhando os processos de gerenciamento de eventos, incidentes, problemas, acesso e de execução de requisições (FERNANDES e ABREU, 2012).

26 26 A Operação de Serviço é mais do que a execução repetitiva de um padrão de procedimentos ou atividades. Todas as funções, processos e atividades são definidos para possibilitar a entrega de serviços específicos de acordo com seus respectivos níveis de serviço. Um dos papéis chave da Operação de Serviço é gerenciar o potencial conflito de papéis entre as visões externas e internas relacionadas aos serviços, que é resultado de diversas variáveis, encontrando um balanceamento entre um conjunto de prioridades conflitantes. Segundo Fernandes e Abreu (2012), o estágio de Operação de Serviço é suportado por um conjunto de cinco processos de Gerenciamento de Serviços, que são: Gerenciamento de Eventos, Gerenciamento de Incidentes, Gerenciamento de Problemas, Cumprimento de Requisições e Gerenciamento de Acessos. A Figura 1 mostra como os processos da operação de serviço se relacionam. Conforme Mendonça (2011), como parte do ciclo de vida do serviço, o módulo de Operação de Serviço é responsável por executar e desempenhar processos que otimizem o custo e a qualidade dos serviços. Figura 1 Processos da Operação de Serviço Fonte: Fernandes e Abreu (2012). Como parte da organização, a Operação de Serviço é responsável por permitir que o negócio atinja os seus objetivos, conforme a estratégia que foi definida nos módulos anteriores. E por último, como parte da tecnologia, este módulo é

27 27 responsável pela manutenção efetiva das funcionalidades dos componentes de infraestrutura que suportam os serviços de TI. Isto é possível por meio do gerenciamento proativo de eventos no ambiente, problemas de infraestrutura, correção e prevenção de falhas e o suporte necessário para que tais condições recebam a devida importância e sejam tratadas conforme os processos estabelecidos, gerando valor ao negócio. Estes princípios ajudam a Operação de Serviço a atingir um equilíbrio entre todos os papéis pelos quais é responsável, focando no gerenciamento efetivo dos aspectos do dia-a-dia das operações de TI, enquanto mantém uma perspectiva de um contexto mais amplo, levando em consideração questões como melhoria contínua dos serviços, identificação proativa de problemas de infraestrutura e padrões de comportamento do ambiente produtivo. Todas as fases do ciclo de vida da ITIL geram valor para o negócio, mas é nesta fase onde o valor se realiza, pois a Operação de Serviço é responsável por entregar níveis de serviço para seus clientes e usuários, enquanto que, ao mesmo tempo, deve manter os custos e a utilização de recursos balanceados. O livro cobre tópicos como os princípios e o ciclo de vida da operação de serviços, fundamentos do processo, administração de aplicação, infraestrutura e operações, fatores de sucesso e controle e funções de processos. 2.3 Central de serviços A Central de Serviço não é um processo e sim uma função, aliás, essencial para o gerenciamento de serviços de TI. Função é um conceito lógico referente a pessoas e medidas automatizadas que executam um determinado processo, atividade ou uma comunicação entre eles. Ela é o primeiro contato dos usuários ao notarem imprevistos e visa responder rapidamente às questões, reclamações e problemas deles. Pode ser centralizada, local ou virtual, nas modalidades: Central de Atendimentos (Call Center): Foco no atendimento de grandes volumes de transações;

28 28 Central de Suporte (Help Desk): Foco no gerenciamento, coordenação e resolução de incidentes, mitigando perda de requisições e tempo de espera demasiado; Central de Serviços (Service Desk): Trata incidentes e demais processos de negócio, sendo ponto único de contato (Single Point of Contact SPOC). O SPOC é uma evolução do conceito de Central de Serviços. É a implementação de um ponto único de contato, o que eleva a qualidade e o controle dos serviços na empresa. A partir dele é possível também implementar o conceito de catálogo de serviços. A central de serviços é responsável, principalmente, pelo gerenciamento e comunicação de incidentes. Por meio dela são feitas as suas classificações, conforme será apresentado, nesta seção Estrutura organizacional Magalhães e Pinheiro (2007) definiram os seguintes fatores para a escolha do tamanho da central de serviços: Tamanho da organização; Grau de distribuição da estrutura organizacional; Nível de heterogeneidade da infraestrutura de TI. Baseando-se nestas informações, montaram um quadro como proposta de seleção da estrutura organizacional da central de serviços (Quadro 1). Quadro 1 Estrutura Organizacional e ITIL Tamanho da Organização Estrutura Organizacional Heterogeneidade da Infraestrutura de TI Arquitetura da central de serviços Pequena Centralizada Baixa Local Pequena Centralizada Elevada Local Pequena Distribuída Baixa Centralizada Pequena Distribuída Elevada Centralizada Grande Centralizada Baixa Local Grande Centralizada Elevada Centralizada Grande Distribuída Baixa Centralizada / Virtualizada Grande Distribuída Elevada Virtualizada Fonte: Magalhães e Pinheiro (2007).

29 29 Conforme apresentado no Quadro 1, existem três tipos principais de estruturas: Central de Serviços Local: Este tipo tem toda sua infraestrutura localizada no mesmo espaço físico dos usuários dos serviços de TI. Isso permite uma maior visibilidade dos acontecimentos; Central de Serviços Centralizada: Quando toda a sua infraestrutura estiver em um local físico diferente da localização dos usuários dos serviços de TI; Central de Serviços Virtualizada: Este tipo de arquitetura está distribuída geograficamente. As centrais de serviço ainda podem ser classificadas conforme o tipo de atendimento: Atendimento 24 horas: algumas organizações por possuírem sedes em várias partes do globo poderão ter o serviço de suporte disponibilizado 24 horas; Grupos especializados: Através de gravações telefônicas os grupos de incidentes serão informados e o usuário selecionará para que tipo deseja atendimento. A ligação redirecionará o usuário para o especialista no atendimento daquele incidente. Uma organização pode utilizar uma estrutura que seja resultada da combinação de mais de uma destas opções com o objetivo de satisfazer plenamente as necessidades do negócio Níveis de suporte Os níveis de suporte são camadas especializadas de técnicos que colaboram para resolver os incidentes enviados para a central de serviços. Uma organização deve assegurar que os funcionários sejam atendidos por um número suficiente de analistas e estes estejam sempre disponíveis conforme a demanda.

30 30 Para definição dos níveis é importante que sejam considerados alguns fatores (TAYLOR et al, 2007): Expectativas dos clientes e usuários; Número de clientes e usuários; Tipos de incidentes e requisições de serviços; O período de tempo necessário para suporte aos usuários (Zonas de tempo, jornada padrão de trabalho e requisitos solicitados fora do expediente); Tipos de comunicação com os usuários (Telefone, , salas de bate-papo); Entendimento dos processos e procedimentos do negócio. Todos estes itens devem ser cuidadosamente estudados antes de qualquer decisão da definição dos níveis. A organização deve definir que faixas de habilidades são necessárias para os níveis da central de serviços. A maioria dos departamentos de TI possui no máximo 3 níveis de suporte. O primeiro nível de suporte é constituído pelos analistas da central de serviços, que é responsável pela demanda dos incidentes e requisições de serviços. É o ponto único de contato com a TI (SPOC Single Point Of Contact). Tradicionalmente existem 3 estilos neste nível (COHEN, 2008): Solucionador: o perfil destes analistas é bastante desenvolvido em termos técnicos. O objetivo é que o incidente seja solucionado no momento do recebimento; Direcionador: a função deste analista é de simplesmente registrar o incidente de uma forma detalhada e encaminhar para o nível responsável; Solucionador + Direcionador: nesta combinação o analista registra o incidente e tenta resolver apenas com o auxílio da base de incidentes e scripts de análise.

31 31 O segundo nível de suporte pretende resolver os incidentes que não são resolvidos de forma remota. Os técnicos deste grupo intervêm nos incidentes que necessitam da presença física. Geralmente os incidentes resolvidos por este nível são problemas de hardware, infraestrutura de rede e de banco de dados. O terceiro nível de suporte é composto por desenvolvedores de software e fabricantes de hardware, especialistas externos e consultores. Os incidentes chegam a este nível quando o suporte local necessita de um auxílio externo para resolução do incidente. 2.4 Gerenciamento de incidente O processo de gerenciamento de incidente é apoiado pela Central de Serviços, sendo que este é o processo responsável pelo tratamento e pela resolução de todos os incidentes observados nos serviços de TI, minimizando os impactos decorrentes do efeito sobre o nível de serviço ou, até mesmo, da indisponibilidade total. Conforme afirmado por Magalhães e Pinheiro (2007), a resolução de um incidente o mais prontamente possível é o foco principal do Gerenciamento de Incidente, o que pode ser alcançado pela aplicação de uma solução de contorno (workaround). Ainda para Magalhães e Pinheiro (2007), os objetivos do processo de Gerenciamento de Incidente são: Resolver o incidente do modo mais rápido possível, ao menos dentro do tempo estabelecido pelo Acordo de Nível de Serviço celebrado com a área-cliente do serviço de TI; Minimizar a adversidade do impacto ocasionado pelo incidente sobre as operações do negócio; Manter a comunicação entre a área de TI e suas áreas usuárias sobre o estado do incidente (escalonamento, tempo estimado para a resolução, solução de contorno etc.);

32 32 Avaliar um incidente para determinar se é provável que volte a ocorrer ou se é um sintoma de um problema crônico. Se for isto, informar à equipe de Gerenciamento de Problema a respeito; Assegurar os melhores níveis de disponibilidade e de desempenho dos serviços de TI; Segundo Melendez Filho (2011), há dois métodos ou modos de implementação do processo de gerenciamento de incidentes, que são os seguintes: Modo receptivo: o usuário entra em contato com a Central de Serviço; Modo ativo: a Central de Serviço entra em contato com o usuário, oferecendo serviços como retorno de chamados de incidentes e realização de pesquisa de satisfação de usuários. O gerenciamento de incidentes contempla as falhas e interrupções reportadas pelo usuário (modo receptivo), a adoção de procedimentos rápidos de resolução recuperação, acompanhamento da solução até o fechamento do registro de incidente de serviço (ordem de serviço), que será efetivado com o aceite final do usuário. O Quadro 2, apresentado por Melendez Filho (2011), descreve detalhadamente o ciclo de vida do incidente, que vai desde o atendimento inicial do usuário até o fechamento da ordem de serviço. O registro dos incidentes, citado na etapa 8 do Quadro 2, conforme Cohen (2008), geram informações que podem ser utilizadas em diversas análises como, por exemplo, as apresentadas a seguir: Carga de serviço dos técnicos; Tipo de problemas corriqueiros; Período (dia, semana ou mês) com o maior fluxo de contatos e solicitações; Equipamentos que mais apresentam defeitos; Usuários com o maior nível de dificuldade no uso da tecnologia.

33 33 Quadro 2 Etapas do gerenciamento de incidentes e respectivos procedimentos Etapa ITIL Procedimentos Detalhados Identificação do usuáro, seu perfil e itens de configuração a ele 1. Identificação entregues. 2. Registro Entendimento da demanda e abertura de registro do contato. 3. Categorização Verificação do histórico de soluções adotadas e pendências. Determinação e registro da priorização da Ordem de Serviço, 4. Priorização conforme perfil, Itens de configuração e histórico de soluções adotadas. Diagnóstico das possíveis causas. 5. Diagnóstico Inicial Verificação se o usuário deseja participar do procedimento de recuperação do incidente. Caso negativo, vai para a etapa Investigação e Diagnóstico 7. Resolução e Recuperação 8. Fechamento Localização/verificação de possíveis soluções na base de conhecimento. Localização/verificação de possíveis informações e orientações no "diário de bordo". Orientação do usuário para solução de demanda ou solicitação para acesso à estação de trabalho do usuário. Tentativa de solução do incidente. Não solucionado o incidente, volta à etapa 5. Efetua o registro da solução do incidente ou do entendimento do incidente. Envio do registro para a equipe de telessuporte de 2º nível, para a equipe de field service ou para assistência técnica/garantia. Solicita e registraa avaliação da satisfação do usuário e encerra o contato/demanda. Registro final da demanda no sistema de gerenciamento de incidentes. Fonte: Melendez Filho (2011) Há, ainda, alguns outros conceitos relevantes que devem ser considerados e praticados dentro do escopo do gerenciamento de incidentes. Estes conceitos serão apresentados nas subseções a seguir Modelos de incidentes ou scripts de incidentes São scripts que os atendentes e analistas da Central de Serviço podem consultar, que contêm procedimentos a serem utilizados durante o ciclo de vida do incidente e que agilizam a identificação de ações a serem tomadas.

34 34 Estes scripts costumam ser dicas e truques que foram documentados por outros atendentes e analistas, após horas de investigação e de ações de resolução de incidentes já conhecidos porque se repetem (MELENDEZ FILHO, 2011) Escalonamento de incidentes Corresponde à passagem do incidente de um nível de atendimento para outro, com o objetivo de atender as metas de SLA, que são os direitos dos clientes aplicados às relações entre organizações, ou seja, são as garantias legais de níveis de desempenho dos serviços de TI oferecidos e de infraestrutura por parte de seus fornecedores (MAGALHÃES E PINHEIRO, 2007). O escalonamento pode ser funcional, que é quando o incidente é transferido para uma área que possui mais conhecimento técnico; ou pode ser hierárquico, onde o incidente é transferido para níveis hierárquicos superiores Prioridade de incidentes Com base em critérios que analisam o impacto do incidente em relação do negócio da organização, é definida a prioridade de atendimento para o incidente Gravidade ou severidade de incidentes São incidentes que, geralmente, são atendidos por equipes especificas. Estas equipes atuam em incidentes graves ou com alto grau de severidade, como aqueles que ocorrem com ativos de serviço considerados críticos, em que sua interrupção ou falha causam um maior impacto para a organização. 2.5 Software Open Source Todo software existe em duas formas: uma lida somente por computadores e outra que pode ser lida pelas pessoas. A forma que o computador lê é a forma que é executada por ele. Esta forma é chamada de código binário ou executável. A forma

35 35 que pode ser lida por humanos é chamada de código fonte. É assim que os programas são desenvolvidos e, através de um compilador, é que se gera o código binário ou executável (CHASSELL, 2013). Inicialmente, todo software era livre e qualquer programador tinha o direito legal de copiar, estudar, modificar e redistribuir os programas gerados. Entre os anos de 1968 e 1969, a IBM anunciou o unbundling (desagregação) de seus produtos, separando o software do hardware, e já haviam empresas que focavam no desenvolvimento de software (SABINO, 2011). A partir do final dos anos 70, tornouse possível proteger os programas de computador com a licença copyright e, também, obter a patente sobre algum algoritmo matemático existente (CHASSELL, 2013). A possibilidade de proteger os programas de computador por meio da licença copyright motivou os membros da cultura hacker americana a criar o termo software livre (free software), entre as décadas de 60 e 70. Segundo Rasch (2000), sua criação teve origem nos laboratórios de informática de algumas universidades, como Stanford, Berkeley, Carnegie Mellon e MIT. O movimento pelo open source foi iniciado no final dos anos 90, por algumas pessoas que admiravam os benefícios técnicos e econômicos do código fonte aberto e desenvolvimento aberto, sendo que pouco ou nada se importavam com os aspectos relativos à liberdade. Existe muito pouco software reconhecido pela iniciativa open source que não é simultaneamente software livre, e a sigla FOSS (Free and Open Source Software) é usada para especificar estes softwares (OPENSUSE, 2013). Para Augusto (2003), o ponto em comum entre as diversas licenças que atendem a definição Open Source é a negação de quaisquer garantias sobre o produto. A intenção é proteger o autor do software de qualquer obrigação ou passivo legal ligado aos programas. Uma vez que os programas normalmente são distribuídos sem custo, é razoável fixar esta ausência de garantias, pois o autor não obtém receitas com os programas a fim de custear seguros ou honorários legais. (AUGUSTO, 2003, pg. 13) Qualquer indivíduo pode tomar o programa como sua propriedade particular, retirar a indicação da autoria, tratá-lo como sua produção intelectual e relicenciá-lo (PERENS, 2013).

36 Micro e Pequenas Empresas A classificação para micro e pequenas empresas não segue um padrão único, havendo vários métodos para isto. De acordo com Longenecker et al (2007 apud NOGUEIRA, 2012), não há uma definição universalmente aceita, pois depende da finalidade a qual a empresa se destina. Para o SEBRAE (Serviço Brasileiro de Apoio às Micro e Pequenas Empresas), o número de funcionários é o critério utilizado para a classificação de empresas de comércio e de indústria, conforme apresentado no Quadro 3. Quadro 3 Classificação das MPE de acordo com o número de empregados. Setor Porte. Indústria Comércio e Serviços Micro empresas Até 19 Até 9 Empresas de pequeno porte De 20 a 99 De 10 a 49 Médias empresas De 100 a 499 De 50 a 99 Grandes empresas 500 ou mais 100 ou mais Fonte: Acesso em: 30 de maio de 2013 Nesta classificação, microempresas de comércio e serviços são aquelas que possuem até nove funcionários, e pequenas empresas da mesma categoria são as que possuem de dez a quarenta e nove funcionários. Este número sobe para até 19 funcionários nas microempresas e até 49 funcionários para pequenas empresas da categoria indústria. A lei complementar nº 123/2006 do Governo Federal que revoga a Lei do Simples Federal (Lei nº 9.317/96), que dá benefícios do ponto de vista tributário e fiscal, classificam as micro e pequenas empresas pelo faturamento bruto anual, sendo de até R$ ,00 (duzentos e quarenta mil reais) para microempresas e, acima desse valor, até R$ ,00 (dois milhões e quatrocentos mil reais) para empresas de pequeno porte. Já o Estatuto da Microempresa e da Empresa de Pequeno Porte (Lei nº 9.841/99), que estabelece incentivo através da simplificação de suas obrigações administrativas, previdenciárias e creditícias e pela eliminação ou redução destas por

37 37 meio de lei, define a classificação de micro e pequenas empresas conforme o Decreto nº 5.028/04: Microempresa é a pessoa jurídica com receita bruta anual igual ou inferior a R$ ,14. Empresa de pequeno porte é a que possui renda bruta anual de R$ ,15 a R$ ,00. Em 2009, as micro e pequenas empresas representavam 99,6% das empresas nacionais, e eram responsáveis por 77,6% dos postos de trabalho. Esses dados comprovam a força que elas possuem no mercado brasileiro (SEBRAE, 2009). As empresas de pequeno porte têm se mostrado propulsoras de empregos e crescimento econômico. Segundo dados da Relação Anual de Informações Sociais do Ministério do Trabalho e Emprego (RAIS/MTE), de 2000, 93% do total dos estabelecimentos empregadores do Brasil são constituídos por empresas de micro e pequeno porte (com até 100 empregados), e nos anos de 1999 e 2000 foram responsáveis por 96% dos empregos. As micro e pequenas empresas são as maiores geradoras de emprego e renda e contribuem para o desenvolvimento das regiões menos desenvolvidas. Dai a sua importância para o desenvolvimento econômico e social de um país. Segundo o SEBRAE (2006), no Brasil existem 5,1 milhões de empresas. Desse total, 98% são micro e pequenas empresa, responsáveis por 67% do pessoal ocupado no setor privado. Os pequenos negócios (formais e informais) respondem por mais de dois terços das ocupações do setor privado. O Instituto Brasileiro de Geografia e Estatísticas (IBGE) desenvolveu, em 2001, um amplo estudo sobre as principais características de gestão das micro e pequenas empresas brasileiras. Algumas características encontradas neste estudo são: Baixo volume de capital empregado; Contratação direta de mão-de-obra; Baixo emprego de tecnologias sofisticadas; Baixo investimento em inovação tecnológica.

38 38 Cavalcante (2010) aponta que umas das características marcantes é que as micro e pequenas empresas geralmente possuem gerencia e administração ligadas aos seus proprietários, sendo representadas individualmente ou por um grupo pequeno de pessoas.

39 39 3 DESCRIÇÃO CENÁRIO PARA REALIZAÇÃO DOS TESTES O objetivo de realizar testes das ferramentas de gerenciamento de incidentes é avaliar suas funcionalidades por igual, para que, ao final dos testes, seja possível obter a relação das características presentes em cada FGI. Segundo Vieira (2010), para a realização de testes é necessário oferecer um ambiente com infraestrutura similar ao de produção, com bases de dados reduzidas, descaracterizadas e íntegras, utilizando processos automáticos de carga e validação de informações. Os testes a serem realizados são de validação, que são executados em um ambiente preparado exclusivamente para as atividades de teste. Testes de validação, segundo Bartié (2002 apud MARINHO, 2009), são baseados no comportamento do software, segundo diversas condições que serão simuladas, para que sejam comparadas com as especificações produzidas pela área de negócios. Na fase de validação de software, devem ser utilizados vários métodos, para garantir que esta fase seja completa e eficaz, pois, segundo Cybis (2007), ela é bem sucedida quando o software funciona de uma maneira razoavelmente esperada pelo cliente. Os testes a serem realizados neste trabalho serão do tipo Caixa Preta, também conhecidos por testes funcionais e, para Maldonado (2009), são conhecidos por testes baseados em especificações, que são bastante utilizados nas fases de testes de sistemas e de aceite. Este tipo de testes analisa a interface, funções, desempenho, performance e dados do sistema (MARINHO, 2009). Segundo Sommerville (2007), no teste de caixa preta, o testador apresenta o caso de teste, ou seja, as entradas de dados para os testes no sistema e examina se a saída dos resultados dos testes são aquelas previstas, caso não seja, o teste detectou um problema com o software.

40 40 Esta seção apresenta a definição e a preparação do ambiente de teste, abordando detalhes como a elaboração das categorias de produtos a serem cadastradas nas FGI, a infraestrutura para sua implantação e modelos de chamados, com diferentes especificações, que servirão como guia para os testes. 3.1 Definição do ambiente A primeira etapa desta seção é desenvolver a base inicial com as informações para popular as FGI. Esta base será desenvolvida em duas etapas: 1. Categorias: base com as categorias, produtos e problemas que servirão para categorização dos incidentes de teste; 2. Perfis: base com perfis de atendentes e analistas que atuarão nos incidentes abertos. Depois de criadas, as bases serão cadastradas em todas as FGI a serem avaliadas neste trabalho, assim haverá o subsídio inicial para que os testes sejam realizados Base Categorias Para a criação da base categorias, será utilizada a estrutura de uma empresa real, em que concordou em fornecer a base de categorias da sua FGI, mas não terá seu nome divulgado por questões burocráticas. O Quadro 4 apresenta um exemplo de como será a classificação de categorias, produtos e problemas. Este quadro é apresentado integralmente no Apêndice A. A criação de categorias, produtos e problemas é importante, pois, ao trabalhar com uma FGI, é possível categorizar melhor os incidentes registrados.

41 41 Quadro 4 Categorias, Produtos e Problemas Categoria Produto Problema Configuração Instala,Move,Altera Equipamento Access Point Mal Funcionamento Equipamentos/Acess. Reset Instalar Estabilizador Mal funcionamento Ad/Rem backup de um servidor Atender auditoria Backup e restore Cancelamento de backup Infra Backup/Restore Movimentação de dados históricos Solicitação de restore Tape library Adic/Rem tape library Gerencia Router Configuração IP Solicitação de IP Fixo Configuração Infra WAN Enviar relatório de alto consumo Roteadores Solicitação relatório de consumo WAN inop troubleshooting Fonte: Desenvolvimento próprio (2013). Para Magalhães e Pinheiro (2007), a categorização permite um gerenciamento eficiente do ciclo de vida de serviço proposto na ITIL, permitindo: Localizar o incidente ao longo do seu ciclo de vida; Adicionar informação útil que possa auxiliar, informar ou assistir a equipe de suporte técnico, objetivando encontrar a solução permanente ou uma solução de contorno; Registrar informações para a formação de histórico para uso futuro; Colecionar informação sobre a quantidade de incidentes, eficiência na resolução, disponibilidade dos serviços de TI e análise de tendências para utilização pelos outros processos definidos na ITIL. Outros benefícios da categorização de incidentes, conforme Magalhães e Pinheiro (2007), são: melhor definição de impacto do incidente para o negócio, melhor gerencia de escalonamento de incidentes e relatórios gerenciais mais precisos.

42 Base Perfis A criação da base perfis consiste em definir os atendentes e analistas responsáveis pelo atendimento de primeiro, segundo e terceiro nível, conforme apresentado na seção É definida, também, a associação dos perfis criados como responsáveis pelo atendimento de categorias especificas criadas na seção O Quadro 5 apresenta os perfis a serem cadastrados nas FGI, associados às categorias em que serão responsáveis pelo atendimento. Quadro 5 Perfil x Nível x Categoria Perfil Nível de atendimento Categoria Suporte 1 1 Atendimento inicial e registro de incidentes Suporte 2 1 Atendimento inicial e registro de incidentes Suporte 3 1 Atendimento inicial e registro de incidentes Suporte 4 1 Atendimento inicial e registro de incidentes Suporte 5 1 Atendimento inicial e registro de incidentes Suporte 6 2 Equipamentos/Acess, Infra WAN Suporte 7 2 Infra Storage, Infra Servidores Suporte 8 2 Infra WAN, Infra Internet Suporte 9 2 Segurança da Informação, Telefonia Suporte 10 2 Infra Backup Restore, Infra Banco de Dados Suporte 11 3 Telefonia Suporte 12 3 Internet Suporte 13 3 Servidores Suporte 14 3 Antivírus Suporte 15 3 Manut. Hardware Fonte: Desenvolvimento próprio (2013). A próxima seção aborda a preparação do ambiente para a instalação das FGI e para a o preenchimento das bases de categorias e perfis. 3.2 Preparação do ambiente As FGI serão instaladas em servidores virtuais, de igual configuração, para a realização dos testes. O software de virtualização utilizado é o Oracle Virtual Box versão , que permite a instalação e utilização de um sistema operacional dentro

43 43 de outro, assim como seus respectivos softwares. O Virtual Box Possibilita o uso de dois ou mais computadores independentes, que compartilham fisicamente o mesmo hardware (VIRTUALBOX, 2013). O sistema operacional escolhido para estes servidores virtuais é o Debian. O Projeto Debian é uma associação de pessoas que têm como causa comum criar um sistema operacional livre. O sistema operacional é chamado Debian GNU/Linux, ou simplesmente Debian (DEBIAN, 2013). A versão utilizada é a netinst. Nesta versão o método de instalação do Debian requer uma conexão permanente à Internet durante a instalação. Comparado com outros métodos, este realiza o download de menos dados, já que o processo é adaptado às necessidades do utilizador. Para a instalação das FGI, é necessário fazer com que estes servidores sejam do tipo web, que, para Technet (2013), são computadores com software específico que permitem a aceitação de solicitações de computadores de clientes e retornam respostas a essas solicitações. Os servidores web permitem o compartilhamento de informações pela Internet ou por uma intranet ou extranet. Os softwares específicos para o funcionamento dos servidores web, utilizados neste trabalho, são: Apache HTTP Server (versão ): O servidor HTTP Apache é capaz de executar código em PHP, PERL, Shell Script e até em ASP e pode atuar como servidor FTP, HTTP, entre outros. Sua utilização mais conhecida é a que combina o Apache com a linguagem PHP e o banco de dados MySQL (ALECRIM, 2006). MySQL (versão ): Sistema gerenciador de banco de dados relacional, open source, usado na maioria das aplicações gratuitas para gerir suas bases de dados. O serviço utiliza a linguagem SQL, que é a linguagem mais popular para inserir, acessar e gerenciar o conteúdo armazenado num banco de dados (PISA, 2012). PHP (versão ): Linguagem de programação de ampla utilização, interpretada e interessante para o desenvolvimento de páginas web. Pode ser mesclada dentro do código HTML. A sintaxe

44 44 da linguagem PHP lembra C, Java e PERL, e é fácil de aprender. O objetivo principal da linguagem, é permitir que desenvolvedores escrevam páginas que podem ser geradas dinamicamente e rapidamente, mas é possível fazer muito mais do que isso com PHP (PHP, 2013). Os servidores virtuais serão instalados no mesmo equipamento físico, que possui as seguintes configurações: Processador: Intel Core i3 M350 2,27 GHz; Memória principal (RAM): 3GB; Memória secundária (HD): 500GB; Sistema Operacional: MS Windows 7 SP1 Home Basic 32 bits. Cada servidor virtual possuirá a mesma configuração: Processador: 1 Core; Memória principal (RAM): 384 MB; Memória secundária (HD): 8 GB; Sistema Operacional: Debian Após a instalação e configuração do ambiente citado nesta seção, os servidores virtuais estarão prontos para a instalação dos softwares de gerenciamento de incidentes.

45 45 4 FERRAMENTAS SELECIONADAS Este capítulo apresenta as FGI open source selecionados para serem submetidas à avaliação comparativa, que será realizada no ambiente proposto no capítulo 3 deste trabalho. A seleção dos softwares atendeu os seguintes critérios: Código aberto: A FGI é distribuída sobre a licença de código aberto (open source). Seu código pode ser alterado, customizado e melhorado para melhor atender as micro e pequenas empresas; Confiabilidade: As FGI devem possuir confiabilidade. Isto é quando a FGI é adotada por grandes instituições ou se é desenvolvida e mantido por empresas privadas que possuem outros produtos como fonte de renda; Conformidade: As FGI devem estar alinhadas com as melhores práticas contidas na biblioteca ITIL. Através destes três critérios, é possível garantir que as estejam de acordo com o propósito deste trabalho. 4.1 GLPI Gestion Libre de Parc Informatique O GLPI (Gestion Libre de Parc Informatique) é um sistema desenvolvido com o intuito de fornecer uma poderosa ferramenta para gerenciamento de TI e parques computacionais, tendo como principais funcionalidades o gerenciamento de centros de suporte e inventário de equipamentos de informática de forma integrada. Para Passamani (2010), GLPI é uma solução web open source completa para gestão de ativos e help desk. O mesmo gerencia todos os seus problemas de

46 46 inventário de ativos, hardwares, software e suporte ao usuário (help desk). Segundo Salles (2013), trata-se de um sistema totalmente livre licenciado pelos termos da licença pública geral, GPL (General Public License) V2, desenvolvido oficialmente na França e presente em mais de 24 países. O sistema foi especialmente projetado com o intuito de criar um banco de dados contendo todas as informações possíveis sobre a vida de cada componente de sua infraestrutura de TI. Com o GLPI é possível conhecer precisamente todo e qualquer manejo realizado sobre todos os itens da rede, incluindo hardware e software, os quais são automaticamente registrados e contabilizados no custo total de propriedade dos itens de configuração, gerando informações valiosas sobre o seu custo real aos administradores da empresa. O GLPI é utilizado por diversas instituições publicas e privadas. Algumas dessas instituições, que estão no Brasil, são apresentadas como utilizadoras desta FGI em seu site oficial (GLPI, 2013): Polícia Civil de Minas Gerais (PCMG); Universidade Luterana do Brasil (ULBRA); Tribunal de Justiça do Estado do Espirito Santo (TJES); Agência Nacional de Aviação Civil (ANAC). A Figura 2 apresenta uma visão da aplicação em funcionamento. Figura 2 Visão da ferramenta GLPI em funcionamento Fonte: Acesso em: 15 jul

47 47 A versão mais recente do GLPI é a que foi liberada em 12 de setembro de O download do código fonte está disponível apenas no formato TGZ (Tape Archive Gzipped File) e seu tamanho é de 9.3 MB. 4.2 Ocomon Ocomon é uma FGI em que é possível organizar e cadastrar um parque de ativos e utilizá-los associando estes aos usuários para abertura de chamados (BYEGMANN, 2009). Conforme apresentado em seu site oficial (RIBEIRO, 2013), O Ocomon surgiu em Março de 2002 como projeto pessoal do programador Franque Custódio, tendo como características iniciais o cadastro, acompanhamento, controle e consulta de ocorrências de suporte e tendo como primeiro usuário o Centro Universitário La Salle (UNILASALLE). A partir de então, o sistema foi assumido pelo Analista de Suporte Flávio Ribeiro que adotou a ferramenta e desde então a tem aperfeiçoado e implementado diversas características buscando atender a questões de ordem prática, operacional e gerencial de áreas de suporte técnico como help desk e service desk. (RIBEIRO, 2013). O Ocomon é utilizado por diversas instituições brasileiras, publicas e privadas. Algumas dessas instituições são apresentadas como utilizadoras desta FGI em seu site oficial (RIBEIRO, 2013): Instituto Federal do Pará (IFPA); Prefeitura Municipal de Gramado RS; Secretaria da Fazenda do Estado do Piauí; Secretaria de Saúde de Botucatu SP; Universidade Estadual de Goiás (UEG). O Ocomon possui uma interface web amigável, que utiliza as tecnologias PHP e MySQL. Implantando este sistema e treinando os usuários e o pessoal de TI, é possível realizar atividades como a visualização e interação com chamados, sem grandes dificuldades. A Figura 3 apresenta uma visão da aplicação em funcionamento.

48 48 Figura 3 Visão da aplicação Ocomon em funcionamento Fonte: Acesso em: 15 jul A versão mais recente do Ocomon é a 2.0RC6 que foi liberada em 11 de setembro de O download do código fonte está disponível nos formatos TGZ (Tape Archive Gzipped File) e ZIP, e seu tamanho é de 3.02 MB. 4.3 OTRS Open source Ticket Request System O OTRS, projeto em código aberto líder em Help Desk e IT Service Management, é um sistema que permite transparência e colaboração para o Service Desk e equipes de suporte ao cliente e usuário, incluindo implementações das melhores práticas de ITIL (LOPES, 2012). É utilizado por milhares de organizações, em todo o mundo, permitindo transparência e colaboração entre as equipes de suporte e os clientes (OP SERVICES, 2013). O OTRS é muito funcional para gerenciar call centers ou qualquer outra configuração de atendimento em equipe. É desenvolvido pelo OTRS Group, empresa alemã com filiais e parceiros em todos os continentes. O OTRS é utilizado por diversas instituições publicas e privadas. Em seu site oficial, é apresentada a lista de instituições utilizadoras, sendo algumas delas (OTRS, 2013): Fundação de Amparo à Pesquisa do Estado de São Paulo (FAPESP); International Business Machines (IBM);

49 49 National Aeronautics and Space Administration (NASA); Porsche Hungaria Kereskedelmi Kft. A Figura 4 apresenta uma visão da aplicação em funcionamento. Figura 4 Visão da aplicação OTRS em funcionamento Fonte: Acesso em: 15 jul A versão mais recente do OTRS é a que foi liberada em 07 de outubro de O download da instalação está disponível nos formatos RPM (Red Hat Package Manager) para instalação em sistemas Linux, EXE para as instalação em sistemas MS Windows. O código fonte pode ser baixado em formatos compactados (TGZ e ZIP) com o tamanho de MB. 4.4 Quaizer Para Chiari (2013), o Quaizer é uma combinação de módulos que podem ser configurados à vontade e livremente para atender as necessidades dos utilizadores. O Quaizer pode ser utilizado na gestão de atendimento, ou de serviços de TI ou em outras áreas similares, como suporte a clientes, Help Desk e Service Desk.

50 50 Extremamente atual e flexível, permite registro de incidentes (chamados) e requisições (pedidos), integração com base de conhecimento de pesquisa textual e outras funcionalidades (QUAIZER, 2013). O Quaizer é o produto open source da empresa Sial Software que, em seu site oficial, apresenta algumas características deste sistema (QUAIZER, 2013): "Sendo um produto avançado, baseado na tecnologia Drupal 7. Compatível com HTML 5, AJAX, RSS, temas visuais, modularizado, integrado com geração de gráficos do Google, single sign-on, personalização do layout de páginas, mais de 150 idiomas, milhares de módulos plug-and-play e uma série de outras tecnologias que se traduzem em alta produtividade para os analistas." (QUAIZER, 2013) A Figura 5 apresenta uma visão da aplicação em funcionamento. Figura 5 Visão da aplicação Quaizer em funcionamento Fonte: Acesso em: 15 jul A versão mais recente do Quaizer é a 1.1 que foi liberada em 06 de agosto de O download do código fonte está disponível nos formatos TGZ para instalação em sistemas Linux e ZIP para instalação em sistemas MS Windows, com o tamanho de MB.

51 Trellis Desk Trellis Desk é uma FGI open source de suporte por tickets. Com ele é possível implantar suporte online em sites sem custo, de forma simples, rápida e com um visual profissional (COSTA, 2013). Trellis Desk é uma solução de help desk poderosa e robusta para o seu negócio. Melhora o serviço de sua empresa, permitindo que seus clientes enviem rapidamente e facilmente tickets de suporte à sua equipe (ACCORD5, 2013). É muito útil para empresas que realizam atendimento ao cliente (suporte), devido o registro e acompanhamento de incidentes incluso nesta ferramenta e também por ser uma forma rápida de solucionar problemas. Seu funcionamento é baseado no envio de tickets para os departamentos do sistema, inclusive com níveis de prioridade e status do ticket. Em seu site oficial, é realizada a divulgação das instituições que utilizam esta FGI (ACCORD5, 2013): Intel Corporation; Hong Kong and Shanghai Banking Corporation (HSBC); United States Army. É possível, também, encontrar em diversos fóruns e blogs internacionais e nacionais, discussões e tutoriais sobre a instalação e manutenção do Trellis Desk. A Figura 6 apresenta uma visão da ferramenta em funcionamento.

52 52 Figura 6 Visão da ferramenta Trellis Desk em funcionamento Fonte: Acesso em: 15 jul A versão mais recente do Trellis Desk, na versão livre, é a O download do código fonte está disponível nos formatos ZIP para instalação em sistemas Linux e MS Windows, com o tamanho de 1.04 MB.

53 53 5 CONCEPÇÃO DO MODELO DE AVALIAÇÃO DE FGI Este capítulo apresenta as etapas para o desenvolvimento do modelo de avaliação proposto, na qual é necessário selecionar as métricas que serão avaliadas nas FGI, analisar em quais delas as métricas estão presentes e avaliar a importância das métricas para as empresas por meio da realização de uma pesquisa. A primeira seção deste capítulo apresenta as métricas selecionadas para este trabalho, a segunda seção apresenta o comparativo das FGI e a terceira seção apresenta a pesquisa realizada com os profissionais de TI, para identificar a importância das métricas nas organizações. 5.1 Métricas As métricas possuem um papel importante para a criação do modelo, pois, diante de um trade-off (implicação de uma decisão feita com completa compreensão tanto do lado bom, quanto do lado ruim de uma escolha em particular) em que é preciso decidir por uma das opções de FGI apresentadas, as métricas servirão como variáveis de entrada para que o modelo decida entre as FGI, selecionando uma e abrindo mão das demais. Esta seção apresentará a definição e a seleção das métricas a serem utilizadas para a avaliação de funcionalidades das FGI Definição de métricas Conforme Farris et al (2013), uma métrica é um sistema de mensuração que quantifica uma tendência, uma dinâmica ou uma característica. Praticamente em todas

54 54 as disciplinas, são utilizadas métricas para explicar fenômenos, diagnosticar causas, compartilhar descobertas e projetar os resultados de eventos futuros. Para Krieser (2010), métrica significa uma indicação quantitativa de algum item específico através de uma unidade de medida padronizada. Já para Ferrari (2013), uma métrica é uma definição operacional que descreve, em termos muito específicos, o que é alguma coisa e como ela é medida pelo processo de controle da qualidade. Cohen (2008) apresenta dois conjuntos básicos de métricas existentes: Quantitativo: As métricas do conjunto quantitativo baseiam-se em números, resultados e valores que podem servir como base para a tomada de decisão dentro das empresas, como a contratação ou demissão de funcionários e o investimento e corte de gastos em setores; Qualitativo: As métricas do conjunto qualitativo revelam um universo imperceptível aos números, podendo contrariar as métricas quantitativas em seus resultados. Mas, em outros casos, são métricas que não poderiam ser avaliadas quantitativamente, servindo, então, para expressar resultados que sejam de fácil compreensão. Para Minayo et al (2011), a pesquisa qualitativa responde a questões muito particulares. Ela se preocupa com um nível de realidade que não pode ser quantificado. Caetano (2012) apresenta os obstáculos para uma boa análise qualitativa: Ilusão do pesquisador em achar as conclusões transparentes (excessiva intimidade com o tema); Excesso de refinamento do método levando ao esquecimento do significado; Dificuldade de articular as conclusões a conhecimentos mais amplos. As métricas utilizadas nesta pesquisa serão do grupo quantitativo, pois o objetivo é quantificar as métricas através da quantidade de entrevistados que irão responder a pesquisa proposta na seção 5.3 deste trabalho.

55 Seleção das métricas As métricas selecionadas para este estudo originaram-se do conjunto de métricas das FGI mais utilizadas pelos centros de suporte das empresas participantes da Pesquisa de Melhores Práticas 2011/2012 da HDI Brasil (Help Desk Institute, 2012). Dentre as métricas apresentadas em cada FGI, foram elencadas as que são comuns entre elas, sendo desconsideradas as métricas que são particularidades e/ou diferenciais das ferramentas, já que a pesquisa, antes citada, lista ferramentas open source e proprietárias. Com o objetivo de agrupar as métricas para proporcionar um melhor entendimento sobre elas, foram criadas 14 categorias diferentes, baseando-se na experiência do autor com FGI durante o desenvolvimento de projeto de pesquisa com a mesma temática (ANTUNES e ANDRADE, 2013). As categorias criadas são: 1) Integração: Esta categoria trata da integração do com serviços de diretório para autenticação dos usuários da ferramenta de gerenciamento de incidentes; 2) Ambiente: Esta categoria identifica a atuação da empresa em relação aos seus clientes. Um cliente pode ser externo (outras empresas), podendo haver um (monoempresa) ou mais clientes (multiempresa); ou interno, que é quanto a central de suporte atua como um setor para atender outros setores da mesma empresa. O cliente é a entidade contratante dos serviços da central de suporte; 3) Cadastros: Esta categoria aborda a quantidade de cadastros que podem ser realizados na ferramenta de gerenciamento de incidentes; 4) Interface: Esta categoria identifica o tipo de interface que a ferramenta de gerenciamento de incidentes precisa ter para atender a necessidade da empresa; 5) Inventário: Esta categoria identifica o inventário de equipamentos e softwares da empresa; 6) Incidentes: Esta categoria aborda a quantidade de incidentes que podem ser registrados na ferramenta de gerenciamento de incidentes;

56 56 7) Acessos simultâneos: Esta categoria aborda a limitação de acessos simultâneos a ferramenta de gerenciamento de incidentes. Acesso simultâneo representa a quantidade de técnicos e usuários que podem efetuar acesso ao mesmo tempo; 8) Suporte: Esta categoria aborda a forma como a empresa utilizadora da ferramenta de gerenciamento de incidentes pode receber suporte da empresa desenvolvedora / fornecedora da ferramenta; 9) Relatórios: Esta categoria aborda a geração de relatórios pela ferramenta de gerenciamento de incidentes; 10) Dashboard: Esta categoria aborda o dashboard (painel de bordo) da ferramenta de gerenciamento de incidentes, que é utilizado para gerar um "painel de indicadores"; 11) Pesquisa de Satisfação: Esta categoria aborda o gerenciamento de pesquisa de satisfação dos usuários em relação aos atendimentos; 12) Atendimento: Esta categoria aborda diversas métricas relacionadas aos atendimentos dos usuários; 13) Gestão de conhecimento: Esta categoria aborda a funcionalidade de gestão do conhecimento da ferramenta de gerenciamento de incidentes; 14) ITIL: Esta categoria aborda a integração da ferramenta de gerenciamento de incidentes com as melhores práticas da biblioteca ITIL. As métricas são apresentadas no formato demonstrado no Quadro 6. Quadro 6 Formato de apresentação das métricas Nº. Categoria Métrica: Descrição. Pergunta principal. Pergunta adicional. Fonte: Desenvolvimento próprio (2013). Sendo que: Nº.: Valor sequencial para a métrica;

57 57 Categoria: Indica a categoria (apresentada anteriormente) na qual a métrica faz parte; Métrica: Nome da métrica; Descrição: Breve descrição sobre a métrica para facilitar o entendimento sobre ela; Pergunta principal: Pergunta sobre a métrica que pode ser objetiva (Sim e Não) ou discursiva; Pergunta adicional: Pergunta que possui relacionamento com uma pergunta principal. Utilizada nos casos em que é necessário descrever algo para complementar a resposta. As métricas selecionadas para avaliar as ferramentas de gerenciamento de incidentes estão enumeradas abaixo: Métricas da categoria 1 (Integração): 1. Integração Integração: A ferramenta de gerenciamento de incidentes deve permitir integração com serviços de diretório. Deve permitir integração com Serviços de Diretório? 2. Integração - Active Directory: É um serviço de diretório que armazena informações sobre objetos em rede de computadores e disponibiliza essas informações a usuários e administradores desta rede. É um software da Microsoft utilizado em ambientes Windows. Deve Permitir integração com AD (Windows)? 3. Integração OpenLDAP: OpenLDAP é o projeto que mantém uma implementação completa em Software Livre de um servidor de serviços de diretórios LDAP e ferramentas e bibliotecas auxiliares. O OpenLDAP está presente em todas as principais distribuições Linux e BSD (Berkeley Software Distribution). Deve permitir integração com OpenLDAP (Linux)? Métricas da categoria 2 (Ambiente):

58 58 4. Ambiente Multiempresa: Quando a central de suporte atende mais de uma empresa. A central de suporte atente mais de uma empresa? 5. Ambiente Monoempresa: Quando a central de suporte atende apenas uma empresa (podendo ser a sua própria empresa). A central de suporte atente uma única empresa? Métricas da categoria 3 (Cadastros): 6. Cadastros Limitação de cadastros de clientes: Há um limite para a quantidade máxima de clientes a serem cadastrados. Esta métrica só se aplica quando a central de suporte atua em um ambiente multiempresa. Pode possuir limite de cadastros de clientes? Quantos? 7. Cadastros Limitação de cadastros de usuários: Há um limite para a quantidade máxima de usuários a serem cadastrados. Usuário é quem receberá o serviço e o atendimento da central de suporte. São as pessoas autorizadas a abrir novos chamados. Pode possuir limite de cadastro de usuários? Quantos? 8. Cadastros Limitação de cadastros de técnicos: Há um limite para a quantidade máxima de técnicos a serem cadastrados. Técnico é quem atua no atendimento dos chamados, podendo ser de primeiro, segundo ou terceiro nível. Pode possuir limite de cadastro de técnicos? Quantos? Métricas da categoria 4 (Interface): 9. Interface Windows: A ferramenta de gerenciamento de incidentes deve possuir clients para serem instalados em equipamentos com Windows. Deve ser aplicativo para Windows? 10. Interface Multiplataforma (JAVA): A ferramenta de gerenciamento de incidentes deve possuir clients para serem instalados em equipamentos com Windows e/ou Linux. Deve ser aplicativo multiplataforma (JAVA)?

59 Interface Web: A ferramenta de gerenciamento de incidentes deve permitir acesso através de browsers, em qualquer sistema operacional. Deve ser aplicativo no formato web? 12. Interface Compatibilidade com browsers: A ferramenta de gerenciamento de incidentes deve possuir compatibilidade com os browsers utilizados pela empresa. Deve possuir compatibilidade com quais browsers? 13. Interface Mobile: A ferramenta de gerenciamento de incidentes deve possuir interface web compatível com dispositivos móveis. Deve possuir interface mobile? 14. Interface Idioma: A ferramenta de gerenciamento de incidentes deve estar em um idioma que seja compreensível pelos técnicos e usuários. Quais idiomas a interface deve possuir? 15. Interface Personalização através de suporte a complementos: A ferramenta de gerenciamento de incidentes deve permitir a personalização de sua interface através da instalação de módulos compatíveis com ela. Deve permitir a personalização da interface através de módulos? Métricas da categoria 5 (Inventário): 16. Inventário Gerenciamento de inventário: A ferramenta de gerenciamento de incidentes deve possuir gerenciamento de inventário. Deve possuir gerenciamento de inventário? 17. Inventário Alerta mudanças súbitas: A ferramenta de gerenciamento de incidentes gera alertas quando ocorrem mudanças súbitas no parque de máquinas. Deve possuir alerta de mudanças súbitas no inventário (detecção automática)? 18. Inventário Alertas sobre softwares proibidos instalados: A ferramenta de gerenciamento de incidentes gera alertas quando um software proibido for detectado no parque de máquinas. Deve possuir alerta sobre softwares proibidos?

60 Inventário Alertas sobre softwares obrigatórios não instalados: A ferramenta de gerenciamento de incidentes deve gerar alertas quando for detectado que um software obrigatório não está instalado no parque de máquinas. Deve possuir alerta sobre softwares obrigatórios não instalados? Métrica da categoria 6 (Incidentes): 20. Incidentes Limitação de quantidade de incidentes: Há um limite de chamados que pode ser registrado na ferramenta de gerenciamento de incidentes. Pode possuir limitação de incidentes? Quantos? Métricas da categoria 7 (Acessos simultâneos): 21. Acessos simultâneos Limitação de acessos simultâneos no ambiente Windows: Há um limite de acessos simultâneos que pode ser realizado na interface do ambiente Windows. Pode possuir limitação de acessos simultâneos no ambiente Windows? Quantos? 22. Acessos simultâneos Limitação de acessos simultâneos no ambiente Multiplataforma (JAVA): Há um limite de acessos simultâneos que pode ser realizado na interface do ambiente Multiplataforma (JAVA). Pode possuir limitação de acessos simultâneos no ambiente Multiplataforma (JAVA)? Quantos? 23. Acessos simultâneos Limitação de acessos simultâneos no ambiente web: Há um limite de acessos simultâneos que pode ser realizado na interface do ambiente web. Pode possuir limitação de acessos simultâneos no ambiente web? Quantos? Métricas da categoria 8 (Suporte): 24. Suporte Suporte via fóruns: O suporte é fornecido em fóruns com a participação de outros usuários, em que há a troca de experiências sobre a utilização da ferramenta e, também, o auxilio da comunidade quando houver dúvidas. Deve possuir suporte via fóruns

61 61 alimentados pela comunidade de usuários/desenvolvedores da ferramenta? 25. Suporte Suporte via tutoriais em Flash: O suporte é fornecido através de tutoriais em flash, fornecidos pela empresa desenvolvedora/fornecedora da ferramenta. Deve possuir suporte via tutoriais em Flash? 26. Suporte Suporte via FAQ's: O suporte é fornecido através de FAQ's (Frequently Asked Questions) localizadas no portal do desenvolvedor/fornecedor da ferramenta. Deve possuir Suporte - suporte via FAQ's (Frequently Asked Questions)? 27. Suporte Suporte via Wiki (manuais): O suporte é fornecido através de um portal Wiki, que contem manuais desenvolvidos pela empresa desenvolvedora/fornecedora da ferramenta e, também, por utilizadores que fazem parte da comunidade de usuários. Deve possuir suporte via portal Wiki com manuais desenvolvidos pelos usuários/desenvolvedores da ferramenta? 28. Suporte Suporte por telefone: O suporte é fornecido através de um canal de comunicação telefônico, podendo se nacional ou internacional, tarifado ou não. Deve possuir suporte via telefone com os desenvolvedores da ferramenta? 29. Suporte Suporte O suporte é fornecido através de um canal de comunicação via , podendo se nacional ou internacional, tarifado ou não. Deve possuir suporte via com os desenvolvedores da ferramenta? Métrica da categoria 9) Relatórios: 30. Relatórios Gerar relatórios: A ferramenta de gerenciamento de incidentes permite gerar relatórios gerenciais com informações básicas sobre os registros de atendimentos realizados durante determinado período. Deve permitir a geração de relatórios? Métrica da categoria 10 (Dashboard):

62 Dashboard Configurar dashboard: A ferramenta de gerenciamento de incidentes permite configurar um dashboard com informações dos registros de atendimentos realizados pelos técnicos. Deve possuir interface com dashboard configurável? Métricas da categoria 11 (Pesquisa de satisfação): 32. Pesquisa de Satisfação Pesquisa de satisfação: A ferramenta de gerenciamento de incidentes permite gerenciar pesquisas de satisfação. Deve possuir gerenciamento de pesquisas de satisfação? 33. Pesquisa de Satisfação Por chamado encerrado: Quando os chamados são encerrados, os usuários associados a ele recebem uma pesquisa de satisfação em relação ao atendimento recebido. Deve realizar pesquisas de satisfação por chamado encerrado? 34. Pesquisa de Satisfação Proativas: A ferramenta de gerenciamento de incidentes gera pesquisas de satisfação proativas, ou seja, o usuário pode receber as pesquisas mesmo que seu último chamado não seja recente, mas em alguma oportunidade ele recebeu atendimento e poderá, então, avaliar sua qualidade. Deve realizar pesquisas de satisfação proativas (sem chamado relacionado)? Métricas da categoria 12 (Atendimento): 35. Atendimento Incidentes: A ferramenta de gerenciamento de incidentes permite registrar chamados do tipo incidente. Um incidente é uma interrupção/falha inesperada ou redução na qualidade de um serviço de TI. Deve permitir a abertura de chamados do tipo incidentes? 36. Atendimento Solicitações de serviço: A ferramenta de gerenciamento de incidentes permite registrar chamados do tipo solicitação de serviço. Uma solicitação de serviço é qualquer solicitação, contato, pedido de informação ou dúvida para acessar um serviço de TI. Deve permitir a abertura de chamados do tipo solicitação de serviços?

63 Atendimento Abertura de chamados via web: A ferramenta de gerenciamento de incidentes deve permitir a abertura de chamados através de interface web. Deve permitir a abertura de chamados via web? 38. Atendimento Autosserviços para usuários finais: A interface web de abertura de chamados possui uma área de autosserviço para que os próprios usuários registrem seus chamados, sem a necessidade de intermediação da central de serviços durante a sua abertura. Deve permitir a abertura de chamados diretamente pelos usuários? 39. Atendimento Abertura de chamados via A ferramenta de gerenciamento de incidentes permite a abertura de chamados através do recebimento de s, enviados pelos usuários, sem a necessidade de intermediação da central de suporte durante sua abertura. Deve permitir a abertura de chamados via ? 40. Atendimento Registro de horas de atendimento: A ferramenta de gerenciamento de incidentes permite aos técnicos registrarem suas horas de atendimento diretamente nos chamados, para que seja possível quantificar o tempo que cada técnico gastou no atendimento. Deve permitir o registro de horas de atendimento dos atendentes/analistas? 41. Atendimento Registro de atividades de atendimento: A ferramenta de gerenciamento de incidentes permite aos técnicos registrarem as atividades realizadas no atendimento dos chamados, gerando um histórico que poderá ser utilizado para diversas finalidades. Deve permitir o registro de atividades de atendimento dos atendentes/analistas (histórico)? 42. Atendimento Feedback: A ferramenta de gerenciamento de incidentes fornece um feedback (podendo ser por ) ao usuário

64 64 quando o chamado relacionado a ele é encerrado. Deve permitir o feedback aos usuários após o encerramento dos chamados? 43. Atendimento Envio programado: O envio de feedbacks aos usuários é programado, podendo ser realizado em momentos que não impactem negativamente na infraestrutura da empresa, como por exemplo, no tráfego de s e consumo de banda de Internet em horário comercial. Deve permitir a programação de envio de feedbacks? 44. Atendimento Envio automático: O envio de feedbacks aos usuários é automático, ou seja, assim que o chamado é encerrado, o próprio sistema se encarrega de enviar o feedback. Deve permitir o envio automático de feedbacks? 45. Atendimento Envio periódico: O envio de feedbacks aos usuários é periódico, na qual os feedbacks referentes a determinado período de tempo são enviados de uma só vez. Deve realizar o envio periódico de feedbacks? 46. Atendimento Chamados por solicitante: A ferramenta de gerenciamento de incidentes associa solicitante (usuários) aos chamados. Deve permitir a abertura de chamados associados a um solicitante? 47. Atendimento Chamados por equipamento: A ferramenta de gerenciamento de incidentes associa equipamento (do inventário) aos chamados. Deve permitir a abertura de chamados associados a um equipamento? 48. Atendimento Chamados por produto: A ferramenta de gerenciamento de incidentes associa produtos (itens de uma categoria) aos chamados. Deve permitir a abertura de chamados associados a um produto? 49. Atendimento Histórico completo: A ferramenta de gerenciamento de incidentes gera o histórico completo dos chamados

65 65 atendidos. Deve registrar o histórico completo do atendimento dos chamados? 50. Atendimento Controle de SLA: A ferramenta de gerenciamento de incidentes possui configuração para controle de SLA (Service Level Agreement). Deve permitir a configuração de SLA? 51. Atendimento SLA por categoria: A ferramenta de gerenciamento de incidentes possui configuração para controle de SLA por categoria de atendimento. Deve permitir a configuração de SLA por categoria? 52. Atendimento SLA por departamento: A ferramenta de gerenciamento de incidentes possui configuração para controle de SLA por departamento atendido. Deve permitir a configuração de SLA por departamento? 53. Atendimento SLA por localidade: A ferramenta de gerenciamento de incidentes possui configuração para controle de SLA por localidade atendida. Deve permitir a configuração de SLA por localidade? 54. Atendimento Fluxos de aprovação configuráveis: A ferramenta de gerenciamento de incidentes possui fluxos de aprovação (autorizações, orçamentos, etc.) configuráveis. Deve permitir a configuração dos fluxos de aprovação? 55. Atendimento Escalonamento: A ferramenta de gerenciamento de incidentes possui a funcionalidade de escalonamento funcional ou hierárquico. Deve permitir o escalonamento de chamados? 56. Atendimento Definido por classificação de chamado: A ferramenta de gerenciamento de incidentes possui escalonamento configurável pela classificação dos chamados. Deve permitir o escalonamento de chamados conforme sua classificação? 57. Atendimento Definido pela localidade de atendimento: A ferramenta de gerenciamento de incidentes possui escalonamento

66 66 configurável pela localidade de atendimento. Deve permitir o escalonamento de chamados conforme sua localidade? 58. Atendimento Escalonamento automático de chamados para equipe seguinte ao expirar o prazo: A ferramenta de gerenciamento de incidentes possui escalonamento automático após a expiração de prazo configurado. Deve permitir o escalonamento automático de chamados para equipe seguinte ao expirar o prazo? 59. Atendimento Scripts (roteiros) de atendimento: A ferramenta de gerenciamento de incidentes possui scripts de atendimento configuráveis, para auxiliar os técnicos durante os atendimentos. Deve permitir a configuração de scripts de atendimento? 60. Atendimento Controle de prioridades de atendimento: A ferramenta de gerenciamento de incidentes possui configuração de controle de prioridade de atendimentos, podendo ser priorizado chamados de determinadas categorias, produtos, equipamentos ou usuários. Deve permitir o controle de prioridades de atendimento? 61. Atendimento Agendamento de abertura de chamados em lote: A ferramenta de gerenciamento de incidentes possui a funcionalidade de agendamento de abertura de chamados em lote, como por exemplo, agendamento de movimentação de equipamentos de um setor. Deve permitir o agendamento de abertura de chamados em lote? 62. Atendimento Contabilização de despesas de atendimento: A ferramenta de gerenciamento de incidentes possui a funcionalidade de contabilizar as despesas de atendimento, como por exemplo, o valor da hora x horas de atendimento de um técnico. Deve permitir a contabilização de despesas de atendimento? 63. Atendimento Confirmação de encerramento de chamados pelos solicitantes: A ferramenta de gerenciamento de incidentes possui a funcionalidade de confirmar com os solicitantes, o

67 67 encerramento do chamado. Isto evita que sejam encerrados chamados erroneamente. Deve permitir a confirmação de encerramento de chamados pelos solicitantes? 64. Atendimento Recurso de agendamento para criação periódica automática de chamados: A ferramenta de gerenciamento de incidentes possui a funcionalidade de agendamento para a criação de chamados periódicos, para atividades que devem ser executadas periodicamente. Deve possuir recurso de agendamento para criação periódica automática de chamados? 65. Atendimento Possibilidade de restrição de acesso a chamados por equipe: A ferramentas de gerenciamento de incidentes possui a funcionalidade de restringir os chamados de determinadas categorias somente para a equipe responsável pelo seu atendimento. Deve permitir a restrição de acesso a chamados por equipe? 66. Atendimento Configuração de Mensageria e envio de avisos por A ferramenta de gerenciamento de incidentes possui a funcionalidade de configuração de mensageria e envio de avisos por . Por exemplo, envio de aos usuários informando que determinado serviço está indisponível por estar havendo uma manutenção no sistema. Deve permitir a configuração de Mensageria e envio de avisos por ? 67. Atendimento Chamados agrupados como projeto: A ferramenta de gerenciamento de incidentes possui a funcionalidade de agrupar chamados como parte de projetos. Deve permitir a abertura de chamados agrupados como projeto? 68. Atendimento Atendimento online (chat): A ferramenta de gerenciamento de incidentes possui a funcionalidade de atendimento online, através de um chat. Deve permitir o atendimento online (chat)?

68 Atendimento Campos adicionais para chamados: A ferramenta de gerenciamento de incidentes permite a configuração de campos adicionais para chamados específicos. Deve possuir a funcionalidade de configurar campos adicionais para chamados específicos? Métricas da categoria 13 (Gestão do conhecimento): 70. Gestão de conhecimento Gestão do conhecimento: A ferramenta de gerenciamento de incidentes deve possuir gestão do conhecimento. Deve possuir gestão do conhecimento? 71. Gestão de conhecimento Base de conhecimento: A ferramenta de gerenciamento de incidentes possui a funcionalidade de criação de base de conhecimento, que são bases de dados ou conhecimento acumulados sobre um determinado assunto, gerando informações que podem ser utilizadas na solução de problemas futuros. Deve permitir a criação de base de conhecimento? 72. Gestão de conhecimento Base de documentos: A ferramenta de gerenciamento de incidentes possui a funcionalidade de criação de base de documentos, que permite inserir documentos específicos para consulta durante o atendimento dos chamados, como por exemplo, contratos de SLA. Deve permitia a criação de base de documentos? 73. Gestão de conhecimento Anexos: A ferramenta de gerenciamento de incidentes possui a funcionalidade de inserção de anexos aos chamados e a base de conhecimento, com a finalidade de orientar sobre informações especificas, como por exemplo, o print screen de uma mensagem de erro. Deve permitir a adição de anexos? 74. Gestão de conhecimento Busca textual: A ferramenta de gerenciamento de incidentes possui a funcionalidade de efetuar buscas textuais na base de conhecimento e de documentos, buscando por sentenças especificas. Deve permitir a busca textual na base de conhecimento?

69 Gestão de conhecimento Solução de chamados pode alimentar a base de conhecimento automaticamente: A ferramenta de gerenciamento de incidentes possui a funcionalidade de utilizar o histórico de atendimento de chamados para alimentar a base de conhecimento. Deve permitir que as soluções dos chamados alimentem a base de conhecimento automaticamente? Métricas da categoria 14 (ITIL): 76. ITIL Gerenciamento de Configuração: A ferramenta de gerenciamento de incidentes é compatível com o processo de gerenciamento de configuração da ITIL. Deve permitir o gerenciamento de configuração? 77. ITIL Gerenciamento de Mudanças: A ferramenta de gerenciamento de incidentes é compatível com o processo de gerenciamento de mudanças da ITIL. Deve permitir o gerenciamento de mudanças? 78. ITIL Gerenciamento de Problemas: A ferramenta de gerenciamento de incidentes é compatível com o processo de gerenciamento de problemas da ITIL. Deve permitir o gerenciamento de problemas? 79. ITIL Catálogo de Serviços: A ferramenta de gerenciamento de incidentes é compatível com o catálogo de serviços da ITIL. Deve permitir o gerenciamento de catálogo de serviços? As 79 métricas apresentadas são utilizadas, nas próximas seções deste capítulo, para realizar o comparativo entre as FGI e para identificar a sua importância para os profissionais de TI de empresas, através de uma pesquisa. 5.2 Comparativo entre as ferramentas Esta seção aborda a implantação das FGI nos servidores virtuais, apresentados na seção 3.2, na qual são apresentadas as considerações sobre a

70 70 implantação de cada uma, possibilitando ao leitor a compreensão sobre as características de instalação das FGI. Após a implantação, é realizada a avaliação comparativa das FGI com base nas métricas apresentadas na seção Implantação das ferramentas As FGI apresentadas no capítulo 4 foram implantadas nos servidores virtuais propostos na seção 3.2 deste trabalho. Apesar de todas as FGI serem open source, as características de instalação mudam entre elas. Mesmo que elas apresentem diferentes pacotes de instalação, conforme descrição realizada no capítulo 4, a fim de facilitar a instalação em ambientes específicos, a implantação realizada neste trabalho será com os códigos fonte descompactados nos servidores e, então, será realizado a configuração conforme as especificações de cada desenvolvedor. Abaixo, os comentários sobre a implantação das FGI são apresentados: GLPI Gestion Libre de Parc Informatique: A instalação do GLPI é simples e intuitiva, não sendo necessário seguir manual ou guia de instalação. Após a descompactação dos arquivos no diretório www do Apache, é realizado o acesso ao arquivo index.php através de qualquer browser. Durante o processo de configuração, o GLPI permite a seleção do idioma Português, que é um dos idiomas nativos desta ferramenta. É realizada a aceitação do contrato de software. Os dados de conexão com o banco de dados, como usuário, senha e nome da base de dados são definidos pela mesma interface gráfica do GLPI. Ao fim da instalação, o sistema avisa que, por questões de segurança, é necessário excluir o arquivo install.php do diretório install. Ocomon: A instalação do Ocomon é simples, mas exige a consulta ao arquivo LEIAME.txt localizado dentro do diretório da ferramenta. Após a descompactação dos arquivos no diretório www do Apache, é necessário importar o script SQL, por meio do prompt de comando, para a criação da base de dados, na qual este script cria o nome da

71 71 base, todas tabelas necessárias e um usuário especifico do Ocomon para a utilização do banco de dados. Após a criação da base dados, é possível acessar a interface gráfica de configuração através do arquivo index.php, na qual são realizadas as últimas configurações para o funcionamento do sistema. Por ser uma ferramenta brasileira, o Ocomon possui o Português como idioma nativo, mas há, também, o pacote com o idioma Espanhol da Colômbia disponível para download. Ao fim da instalação, o sistema avisa que, por questões de segurança, é necessário excluir o diretório install. Há um patch de correção no site oficial do Ocomon e, a única orientação em relação a ele, é que deve ser descompactado no diretório do Ocomon. OTRS Open source Ticket Request System: Por se tratar de uma ferramenta que foi desenvolvido em PERL, a instalação do OTRS é mais complexa em relação as outras ferramentas instaladas. Isto implica na necessidade de mais conhecimento de servidores, da parte do profissional que realiza a instalação, por conta das exigências de instalação desta ferramenta. A consulta ao manual de instalação oficial é necessária. Através do prompt de comando, os códigos fonte devem ser descompactados no diretório /opt/otrs do servidor. Antes de prosseguir com a instalação, há a necessidade de instalar os pacotes PERL do sistema operacional Debian. Ainda pelo prompt, o usuário e o grupo de usuários são criados e recebem as permissões necessárias para funcionarem. É realizada a preparação do arquivo de configuração do OTRS e a configuração do OTRS no diretório do Apache, antes de acessar o arquivo index.pl para acessar a interface gráfica de configuração. Através desta interface, é realizada a criação da base de dados. A finalização da configuração se dá pela configuração dos dados de acesso ao banco de dados no arquivo apache2-perl-startup.pl e, também, pela configuração da crontab. O OTRS possui o Português como idioma nativo.

72 72 Quaizer: A instalação do Quaizer é simples, mas é recomendada a leitura do guia de instalação disponível na página de downloads do site oficial. O Quaizer é desenvolvido com Drupal, mas o arquivo de instalação contem todos os pacotes necessários para seu funcionamento, não sendo necessário realizar o download de pacotes adicionais. Após a descompactação dos arquivos de instalação e dos scripts SQL no diretório www do Apache, é necessário importar os scripts SQL através do prompt de comando, para que a base de dados seja criada. Ao concluir a criação da base de dados, é realizado o acesso ao arquivo index.php através de qualquer browser. Este deveria ser a última etapa para a instalação do Quaizer, mas podem ocorrer alguns erros. Fato que motivou os desenvolvedores a publicar, junto ao guia de instalação, os erros comuns que podem ocorrer e quais as respectivas soluções. Esta iniciativa permite uma rápida solução por parte dos profissionais que realizarem a instalação do Quaizer. Por ser uma ferramenta brasileira, o Quaizer possui o Português como idioma nativo. Trellis Desk: A instalação do Trellis Desk é simples, não sendo necessário seguir manual ou guia de instalação. Após a descompactação dos arquivos no diretório www do Apache, é necessário acessar o arquivo index.php através de qualquer browser. A instalação orienta a criar uma base de dados através do prompt de comando. Assim que a base de dados for criada, é possível retornar à instalação e concluí-la. Esta ferramenta está disponível no idioma Inglês, mas há um pacote de idioma em Português, que é oferecido por meio da comunidade de utilizadores do Trellis Desk. O pacote de idioma em Português foi importado para a ferramenta, mas só funcionou após a exclusão do pacote de idioma em Inglês, mesmo que o idioma Português estivesse definido como padrão.

73 Avaliação comparativa com base nas métricas As FGI são submetidas a testes para identificar as métricas contidas neles. Além dos testes, são utilizadas as informações apresentadas pelos desenvolvedores, pois algumas métricas só poderiam ser identificadas através da instalação de serviços específicos como, por exemplo, o sistema operacional MS Windows Server com o serviço AD. Os testes práticos são definidos através de sequencias, que são exemplos de incidentes a serem implementados nas FGI, com o objetivo de utilizar e identificar os recursos disponíveis. O Quadro 7 apresenta alguns exemplos de incidentes utilizados nos testes. Quadro 7 Exemplos de incidentes utilizados nos testes Categoria Produto Problema Descrição N1 N2 Infra Storage Telefonia Storage Aparelho telefônico Adicionar disco Manutenção Infra WAN Roteadores Configuração Adicionar novo disco no storage AB Teclado do aparelho telefônico do setor C não funciona Roteador do 3º não aceita nosvas conexões Fonte: Desenvolvimento próprio (2013). Suporte 2 Suporte 5 Suporte 1 Suporte 7 Suporte 12 Suporte 8 A avaliação gerou uma tabela que identifica as métricas presentes em cada FGI. O Quadro 8 apresenta, como exemplo, as métricas da categoria interface que estão presentes nas FGI.

74 74 Quadro 8 Métricas da categoria interface presentes nas ferramentas Nº Categoria Interface GLPI Ocomon OTRS Quaizer Trellis Desk 9 Windows 10 Multiplataforma (JAVA) 11 Web X X X X X 12 Compatibilidade com browsers Chrome Firefox IE Outros Chrome Firefox IE Outros Chrome Firefox IE Outros Chrome Firefox IE Outros Chrome Firefox IE Outros 13 Mobile X X 14 Idioma Português Inglês Espanhol Outros Português Inglês Espanhol Português Inglês Espanhol Outros Português Inglês Espanhol Outros Inglês 15 Personalização, através de suporte a complementos X X X Fonte: Desenvolvimento próprio (2013). A quadro completo, gerado nesta etapa, é apresentado no Apêndice B. Através desta avaliação, foi constatado que diversas métricas estão presentes em todas as FGI de gerenciamento de incidentes, conforme exemplo apresentado no Quadro 9, e outras não estão presentes em nenhum deles. O Quadro 10 apresenta um exemplo de métricas que não estão presentes nas FGI. Quadro 9 Exemplo de métricas presentes em todas as ferramentas Nº Categoria Ambiente GLPI Ocomon OTRS Quaizer Trellis Desk 5 Monoempresa X X X X X Nº Categoria Interface GLPI Ocomon OTRS Quaizer Trellis Desk 11 Web X X X X X Nº Categoria Dashboard GLPI Ocomon OTRS Quaizer Trellis Desk 31 Configurar dashboard X X X X X Fonte: Desenvolvimento próprio (2013).

75 75 Quadro 10 Exemplo de Métricas não presentes nas ferramentas Nº Categoria Cadastros GLPI Ocomon OTRS Quaizer Trellis Desk Limitação de cadastros de 6 clientes Nº Categoria Interface GLPI Ocomon OTRS Quaizer Trellis Desk 9 Windows Nº Categoria Atendimento GLPI Ocomon OTRS Quaizer Trellis Desk 68 Atendimento online (chat) Fonte: Desenvolvimento próprio (2013). O quadro completo das métricas presentes em todas as FGI é apresentado no Apêndice C, e o quadro completo das métricas que não estão presentes nas FGI, é apresentado no Apêndice D. 5.3 Pesquisa para Avaliação das Métricas Para Belloni (2000 apud PAIVA, 2011), avaliação é um processo sistemático de análise de uma atividade, fatos ou coisas que permite compreender, de forma contextualizada, todas as suas dimensões, com vistas a estimular seu aperfeiçoamento. A pesquisa para avaliação das métricas tem como objetivo identificar quais métricas, dentre as apresentadas na seção 5.1.2, são mais relevantes para o mercado, pois será realizada com profissionais que atuam na área de suporte de serviços de TI. Esta seção apresenta a definição e a aplicação da pesquisa e, logo ao fim, seus resultados Definição da pesquisa Para formulação da pesquisa, as 79 métricas apresentadas na seção foram agrupadas em 39 questões, conforme suas categorias. A Figura 7 apresenta um exemplo do fluxo das questões na pesquisa, identificando as métricas abordadas em cada questão.

76 76 Figura 7 Exemplo do fluxo das questões na pesquisa Fonte: Desenvolvimento próprio (2013). O fluxo de todas as questões da pesquisa é apresentado no Apêndice E. Foi escolhida a plataforma Google Docs para aplicar a pesquisa, pois automatiza o processo de design da página, traz vários estilos de perguntas pré-construídos e não há nenhum custo para utilizá-la. A Figura 8 apresenta a tela de apresentação da pesquisa no Google Docs. As telas de todas as questões são apresentadas no Apêndice F.

77 77 Figura 8 Tela de apresentação da pesquisa Fonte: Desenvolvimento próprio (2013). Todas as questões criadas possuem um campo adicional, para que os participantes deixem comentários, se julgarem necessário. Os comentários podem ser sugestões de novos parâmetros para as métricas apresentadas ou a percepção pessoal do participante sobre a questão.

78 Aplicação da pesquisa A pesquisa, denominada 1ª Pesquisa de métricas para softwares de gerenciamento de incidentes 2013, foi iniciada no dia 23/09, sendo vinculada ao blog pessoal do autor (ANTUNES, 2013) e divulgada na rede social LinkedIn, que é considerada a maior rede social na Internet voltada para o mercado profissional. A divulgação foi realizada por meio dos seguintes grupos: CooperaTI - Profissionais Certificados em TI. Descrição do perfil do grupo: Um grupo para reunir os melhores em TI que possuem certificações e querem ter mais informações sobre outras provas, sem defender esta ou aquela plataforma ou tecnologia. O intuito do grupo é discutir o que há de melhor em oportunidades na carreira, tanto para que começa quanto para quem já está aí, para mostrar vantagens e desvantagens, se existirem, de algumas provas. A ideia é nos manter atualizados e em sintonia com o mercado, não só no agora, mas também poder saber as tendências de tecnologia que entrarão em demanda (LINKEDIN, 2013a); Governança de TI. Descrição do perfil do grupo: Este grupo é focado na troca de experiências nas áreas que compõem a Governança de TI, promovendo sinergia para o desenvolvimento de novas ideias, estratégias e oportunidades. (LINKEDIN, 2013b); HDI Brasil. Descrição do perfil do grupo: O HDI Brasil é representante do maior instituto do mundo para profissionais de Service Desk, Centros de Suporte e Centrais de Serviços. Com membros espalhado pelo planeta, o HDI fornece conteúdos, publicações, newsletters, pesquisa de melhores práticas, treinamentos e consultorias, além do maior evento da América Latina focado para essa indústria, realizado anualmente em São Paulo. O foco do HDI vai além da disseminação de melhores práticas em processos e procedimentos. O instituto integra essas duas

79 79 variáveis com o recurso mais importante que há na sua empresa: os recursos humanos. A satisfação do profissional de suporte é a razão de viver do HDI, pois sabemos que só assim os serviços prestados aos clientes serão eficientes. (LINKEDIN, 2013c); ITSM na Prática. Descrição do perfil do grupo: O grupo ITSM na Prática foi criado para discutir toda a teoria que é proposta nas práticas e frameworks de gerenciamentos de serviços, como ITIL, CobiT, ISO20000, TOGAF, PRINCE2, e-scm, entre outros. Este grupo é indicado para o público interessado em governança e gestão de serviços de TI em uma abordagem prática e operacional. (LINKEDIN, 2013d); TI Especialistas Brasil. Descrição do perfil do grupo: O grupo é um espaço onde profissionais da área de tecnologia da informação podem compartilhar conhecimento e experiências, onde as empresas podem buscar oportunidades de negócio e onde podem ser encontrados talentos. (LINKEDIN, 2013e). No dia 08/10/2013, a pesquisa foi encerrada e foi possível obter os seguintes números: 142 acessos à postagem de divulgação da pesquisa no blog pessoal do autor; 56 acessos ao formulário da pesquisa na plataforma Google Docs; 17 participantes que chegaram ao fim da pesquisa. O Gráfico 1 apresenta as estatísticas de acesso à pesquisa. A etapa de realização da pesquisa apresentou algumas dificuldades na coleta dos resultados, que se justifica no baixo índice de participantes que concluíram a pesquisa em relação ao total de participantes que a iniciaram. Devido a configuração do formulário de pesquisa, não foi possível obter o feedback dos participantes que desistiram para entender o motivo da desistência.

80 80 Gráfico 1 Estatísticas de acesso à pesquisa Fonte: Desenvolvimento próprio (2013). Estima-se que tal fato seja devido a quantidade de questões e ao tamanho das questões, o que exigia um tempo de aproximadamente 30 minutos para responder o questionário por completo. A Tabela 1 apresenta os dados referentes ao perfil das empresas dos participantes da pesquisa.