Avaliação e Implantação de um Sistema de Abertura de Chamados para a Universidade Federal do Pampa - PDF
Avaliação e Implantação de um Sistema de Abertura de Chamados para a Universidade Federal do Pampa
Download "Avaliação e Implantação de um Sistema de Abertura de Chamados para a Universidade Federal do Pampa"
Ana do Carmo Lencastre Gentil
1 Avaliação e Implantação de um Sistema de Abertura de Chamados para a Universidade Federal do Pampa Amarílio Motta Floriano 1, Márcio Vinissius Fernandes Furtado 1, Patric da Silva Ribeiro 1, Sergio Antonio Martini Bortolin Junior 1, Alex Adair Vargas Cardoso 1, Yusef Mahatma Henchenski Gidrão 1, Diego Luís Kreutz 1, 2 Introdução 1 Núcleo de Tecnologia da Informação e Comunicação - NTIC 2 Grupo de Pesquisa de Sistemas de Informação - PGSI Universidade Federal do Pampa - UNIPAMPA Resumo. O presente trabalho apresenta a avaliação de soluções de software para o controle de chamados de suporte e a adaptação e implantação do sistema escolhido para atender a demanda da UNIPAMPA. O objetivo do projeto é otimizar o processo de suporte técnico na instituição, através de um sistema informatizado de abertura, acompanhamento e gerenciamento de chamados de suporte. A partir dos critérios definidos, e utilizados no processo de avaliação dos sistemas, foi escolhido o sistema de chamados Ocomon, de código-fonte aberto. Numa segunda fase, o sistema sofreu ajustes no código e adaptações ao escopo do serviço de suporte da universidade. Entre os resultados do trabalho podem ser citados a integração com domínios de usuários institucionais e a personalização e simplificação das interfaces de abertura de chamados. A UNIPAMPA é uma universidade pública fundada em 2006 com o objetivo de fortalecer a Região Sul do estado do Rio Grande do Sul (RS). Sediada em Bagé, a universidade possui 10 campi descentralizados, espalhados pelas cidades do Sul do RS, contando atualmente com aproximadamente 461 técnico-administrativos, 398 professores e 7 mil alunos. Devido a essa grande estrutura multicampi, que se encontra hoje em fase de implantação/ampliação, o uso da estrutura de informática torna-se fundamental para comunicação e agilização de processos, ocasionando, contudo, um elevado índice de atendimentos pela área de suporte de informática. Nas unidades, a instituição conta com um técnico e um analista de TIC. Além deles, há uma equipe central, online, de suporte. Originalmente, a instituição trabalhava com um formulário online ( s enviados aos técnicos da unidade centralizadora do suporte). Porém, esse sistema é pouco eficiente sob vários aspectos, como controle e acompanhamento dos chamados, relatórios dos principais tipos de ocorrências, relatórios estatísticos gerenciais, identificação de gargalos e previsão de potenciais SLAs (acordos de níveis de serviço), volume de atendimento, tempo médio de resposta e solução, entre outras coisas. O próprio usuário final ficava sem acompanhamento do andamento (status) do atendimento, gerando eventuais replicações desnecessárias de chamados. Isso levou a equipe de TIC a avaliar novas alternativas, mais eficazes, como os sistemas especificamente projetados e organizados para o atendimento de chamados. O cenário demandava a avaliação, implementação, personalização e adaptação de uma solução informatizada que atendesse o processo de atendimento de chamados, organizando o trabalho dos técnicos e possibilitando o controle efetivo e o conseqüente melhoramento do processo. Neste sentido, o primeiro passo foi iniciar uma pesquisa e avaliação de soluções existentes no mercado, a partir da definição de critérios para o atendimento das especificidades do processo de suporte técnico na UNIPAMPA. O segundo passo foi personalizar, adaptar e implantar a solução escolhida. O processo como um todo é apresentado nas próximas seções, abordando a
2 metodologia utilizada, as adaptações e personalizações realizadas no sistema escolhido, os resultados e a conclusão. Metodologia A pesquisa desenvolvida pode ser classificada, quanto a sua natureza, como pesquisa aplicada, pois sua finalidade objetiva gerar conhecimentos para aplicação prática dirigida à solução de problemas específicos. Ela está direcionada à definição, adaptação e implantação de um Sistema de Abertura de Chamados para gerenciar as solicitações de usuários de todos os campi da UNIPAMPA. O processo de avaliar, definir, adaptar e implantar um sistema de abertura de chamados na UNIPAMPA teve 7 fases: 1) pesquisa e avaliação das aplicações disponíveis; 2) confrontamento das soluções pesquisadas segundo um conjunto de características obrigatórias/necessárias; 3) testes práticos com usuários finais nos sistemas pré-selecionados na segunda etapa; 4) adaptação do ambiente ao escopo do suporte da instituição; 5) implementação do cadastro e controle de usuários integrado; 6) implantação; 7) testes com usuários das diversas áreas de suporte e depuração dos erros no código do sistema. Na primeira fase de pesquisa e avaliação das aplicações disponíveis, o método de avaliação foi composto de etapas empíricas e analíticas. O resultado de cada etapa foi utilizado na próxima como base para continuidade do processo progressivo de avaliação, retro-alimentação e redução gradativa do conjunto de sistemas. Inicialmente, foi realizada uma busca por sistemas de chamados disponíveis e capazes de resolver o problema apresentado. Não houve, num primeiro instante, nenhum tipo de preocupação com plataforma, linguagem, características ou parâmetros diversos que pudessem desclassificar algum sistema. A única preferência foi dada às soluções livres, gratuitas, mas sem excluir eventuais soluções comerciais. O estudo resultou num conjunto de 12 sistemas: 1) GLPI (http://www.glpi-project.org/), 2) WebChamado (http://webchamado.sourceforge.net/), 3) OneOrZero (http://www.oneorzero.com/), 4) OcoMon (http://ocomonphp.sourceforge.net/), 5) SysAid Free (http://www.ilient.com/free-helpdesk-software.htm), 6) SysAid Full (http://www.ilient.com/), 7) WebHelpDesk (http://www.webhelpdesk.com/), 8) HelpDeskPilot (http://www.helpdeskpilot.com/), 9) Trac (http://trac.edgewall.org/), 10) Redmine (http://www.redmine.org/), 11) Jtrac (http://jtrac.info/) e 12) HelpCenter Live (http://www.helpcenterlive.com/). Na primeira fase foram levados em consideração critérios como suporte a LDAP, notificações automáticas por , workflows, relatórios gerenciais e operacionais e documentação disponível. O relatório completo com todos os critérios utilizados, em qualquer uma das fases do processo de avaliação, pode ser obtido através do contato Os critérios utilizados para avaliação inicial dos sistemas de chamados resultaram em uma pré-seleção. Esta foi baseada no atendimento de algumas características estabelecidas como mínimas, como as apresentadas na tabela 1. Características qualitativas, como relatórios e documentação, foram mensuradas em uma escala de valores de 0 (inexistente) a 5 (muito bons, completos). Considerando pelo menos dois dois parâmetros qualitativos, pode-se observar que as maiores pontuações firam entre o GLPI, o WebChamado, o OcoMon e o HelpCenter Live. Contudo, este último foi automaticamente descartado pelo fato de não ter suporte a workflows.
3 Tabela 1 - Sistemas e algumas caracterísitcas avaliadas Software Licença Suporte LDAP nativo Tradução PT_BR Possui notificações automáticas por Capacidade de definir Workflows? Relatórios atendem necessidades Documentação Código Documentação Usuário GLPI GNU/GPL Possui Possui Possui Possui WebChamado GNU/GPL Não P Possui Possui Possui OneOrZero Comercial Possui Parcialmente Possui Possui OcoMon GNU/GPL Possui Possui Possui Possui Licence Agreement SysAid Free Possui Parcialmente Possui Possui próprio Licence Agreement SysAid Full Possui Parcialmente Possui Possui próprio WebHelpDesk Comercial Possui Não P Possui Não P HelpDeskPilot Comercial Não P Parcialmente Possui Não P Trac BSD modified Possui Parcialmente Possui Possui Redmine GNU/GPL Possui Possui Possui Possui Jtrac Apache License 2.0 Possui Possui Possui Possui HelpCenter Gratuito Não P Parcialmente Possui Não P Live A seleção baseou-se no atendimento total dos critérios básicos, ou seja, foram desclassificados todos os sistemas que não atendem a todos os critérios com caracterização textual na tabela 1 e que não atendem minimamente (pontuação igual ou superior a 3) os critérios qualitativos (com excessão da documentação do código), com ponderações numéricas. Segundo os critérios adotados, apenas 3 sistemas atenderam a todas as exigências, o GLPI, o Ocomon e o Redmine. A segunda etapa caracterizou-se pela definição das funcionalidades e características obrigatórias para o sistema permanecer na lista de potenciais candidatos a implantação. Nesta fase foram definidos os seguintes critérios: ergonomia de interface, notificação automática por (abertura, acompanhamento e encerramento), legibilidade e estrutura do código. Estes critérios foram avaliados apenas nos três sistemas pré-selecionados, o GLPI, o Ocomon e o Redmine. Ergonomia é a qualidade da adaptação de um dispositivo a seu operador e à tarefa que ele realiza (Cybis, Betiol & Faust, 2007). Nenhuma das aplicações avaliadas apresentou uma adaptação insatisfatória aos requisitos de interface entre o operador e as tarefas que este deveria executar no sistema. Com relação as questões de gerenciamento e operacionalização, foram consideradas características e recursos como: abertura de chamados por local/unidade de atendimento; controle de inventário e vínculo do chamado com o equipamento; busca rápida de informações referentes ao equipamento no momento da abertura do chamado; notificação por na abertura e fechamento de chamado; acompanhamento do andamento do processo de atendimento das ocorrências; controle de horas trabalhadas; notificações, por , de alteração de status do chamado; controle de dependências para o andamento do chamado; base de conhecimento integrada; relatórios envolvendo: controle de tempo de atendimento para cada serviço, percentual de chamados atendidos e resolvidos dentro do tempo estipulado, reincidência de chamados por equipamento, autenticação de usuários via LDAP, controle do tipos de problemas; possibilidade de postagem de arquivos; personalização das telas; repositório com a descrição de soluções; configuração de filtros de consultas; campos customizáveis disponibilizados automaticamente nas consultas. Todos os três sistemas avaliados atenderam satisfatóriamente a todos os recursos e características consideradas na segunda fase. Na terceira etapa foram efetuados testes com usuários finais para finalizar o processo de definição de qual sistema adotar. Nesta etapa, dez usuários finais abriram quatro chamados nos três sistemas e depois preencheram questionários online com o seu parecer quanto às questões envolvendo: estrutura dos menus, clareza das informações, agradabilidade visual das telas, grau de satisfação com o sistema e sugestões. Segundo a autora Oliveira (2001),... a facilidade de uso em um sistema podem ser considerados como os fatores determinantes para a utilização ou não de um
4 serviço de informação. Sendo assim, requer constante feedback para que esses serviços possam ser planejados e atendam as necessidades presentes e continuadas dos seus usuários. Dixon (2001) afirma: A aplicação de questionários pode ser realizada de forma presencial ou on-line, apresentando as seguintes vantagens: rapidez na coleta dos dados, uso de grandes amostras, menor custo de administração e processamento e taxas de retorno mais altas. Cada questão procurou captar as percepções do usuário sobre importantes aspectos da interface e das funcionalidades do sistema, permitindo ao avaliador atribuir a cada item uma nota com valores inteiros, de 1 a 5. Efetuou-se a média dos valores contidos nas respostas de cada questão e, a seguir, o somatório destas médias, agrupadas pelos tópicos interface e funcionalidade, obtendo-se um índice que refletia a aceitação dos sistemas por parte dos usuários finais. Em ambos os casos, o sistema Ocomon obteve uma pontuação acima dos demais, ficando o software GLPI em segundo lugar. É interessante observar que para a equipe técnica a definição do sistema pelos usuários foi uma surpresa, visto que o Ocomon estava para eles como a opção tecnicamente menos interessante. Somando-se os índices parciais, o Ocomon ficou em primeiro lugar de aceitação, com 64 pontos, seguido pelo GLPI, com 48,67 pontos, e Redmine, com apenas 31 pontos, conforme a figura 1. Figura 1 - Avaliação dos sistemas por usuários finais Diante desses dados, optou-se pela customização, adaptação e implantação do Ocomon. Este foi o único sistema a passar para a próxima fase. A quarta etapa consistiu na adaptação do sistema ao escopo do suporte da UNIPAMPA através da elaboração de detalhes da interface e da definição inicial de áreas e problemas de suporte na instituição. Nesta fase foram também realizadas adaptações nos fluxos do sistema, definindo técnicos para cada área de atendimento e os campos que seriam necessários e obrigatórios no formulário de abertura de chamados. A quinta etapa consistiu na implementação da criação e autenticação dos usuários no Ocomom. O sistema, teoricamente, possiua suporte a LDAP. Contudo, a implementação (o código) precisou de revisão, adaptação e reformulação, conforme descrito na próxima seção. A sexta etapa refere-se à implantação do sistema, com a instalação do mesmo em um servidor de produção. Para tanto foi utilizada uma máquina virtual com Ubuntu Linux 9.10, Apache e PHP O serviço MySQL versão foi instalado em um servidor físico separado, de plataforma similar à anterior. A sétima etapa consiste num processo contínuo de testes, configuração e adequação do sistema para melhor atender as demandas da instituição. Esta etapa iniciou-se em fevereiro de 2010 e está servindo de base para ajustes finais no sistema. Este processo consiste em uso prático, aplicado, do sistema para o atendimento de chamados do campus Alegrete e na depuração e melhoramento do código do sistema.
5 Implantação do Sistema de Abertura de Chamados Após a definição do software a ser adotado, o Ocomon, foi realizada a adaptação da interface e a definição das informações necessárias para o contexto da instituição, assim como o mapeamento inicial das áreas que integrariam o sistema. Uma das primeiras coisas a serem implementadas no sistema foi a função de autenticação necessária para adaptar o modo de integração do sistema com o LDAP, modificando o fluxo original da aplicação. Por padrão de instalação, o sistema verificava se o usuário está cadastrado no banco de dados do Ocomon e no LDAP (sendo que a parte do LDAP sequer funcionava). Em caso positivo, o acesso ao sistema é liberado. Na adaptação realizada, conforme podemos visualizar na figura 2, inicialmente é verificado se o usuário existe na base do Ocomon. Em caso afirmativo, libera-se o acesso ao sistema, utilizando autenticação LDAP. Caso contrário, o diretório LDAP é consultado (busca de informações acerca do usuário tentando acessar o sistema). Quando o usuário é encontrado no LDAP, a base do Ocomon é automaticamente atualizada com as informações básicas do usuário. Isso inclui o cadastro do usuário e a aplicação das permissões essenciais, possibilitando ao usuário a abertura de chamados. No caso de o usuário pertencer a alguma área de atendimento (suporte, ele deverá informar ao operador do sistema para que este possa atribuir as devidas permissões àquele usuário. Quando o usuário já estiver cadastrado na base do Ocomon, porém com a senha diferente do LDAP, a senha será automaticamente atualizada no banco de dados do Ocomon. Este procedimento foi adotado para manter alguns mecanismos de verificação e controle do Ocomon bem como um maior nível de independência do sistema no caso de eventuais falhas do serviço LDAP. Figura 2 - Fluxograma do sistema de autenticação adaptado Para tornar o processo de abertura de chamados o mais simples possível ao usuário final, foram adicionados filtros em alguns pontos da interface do sistema. A estrutura da interface também foi levemente modificada. O principal objetivo foi deixar a interface mais limpa, enxuta e simples. Na interface de chamados, foram desabilitados os campos unidade e local, considerados desnecessários no processo, pois a unidade seria uma informação já relacionada à área e o local, ao equipamento ou usuário, o que reduziu ainda mais a quantidade de dados que o usuário necessitaria informar. O sistema encontra-se disponível no link: Após o login, a tela do Sistema de Abertura de Chamados da UNIPAMPA, num primeiro momento, apresenta as ocorrências agendadas no sistema e aquelas pendentes para o usuário. Na barra lateral da esquerda existe a opção Abrir Chamado (figura 3), onde o usuário fornece as informações necessárias para abrir um chamado, tais como: área responsável, tipo e descrição do
6 problema, local, número do equipamento (se tiver), a opção para o usuário poder anexar um arquivo (que pode ser a tela o problema que está ocorrendo, por exemplo). A opção Meus Chamados lista todas as ocorrências abertas pelo usuário. Figura 3 - Tela de Abertura de Chamado Ao enviar o chamado, o responsável da área recebe um e o usuário uma cópia do chamado aberto. O usuário pode, por meio do sistema, acompanhar todo o processo de atendimento do chamado até o fechamento, quando ele novamente é comunicado, também via . Após terminada a abertura do chamado, este aparecerá em Ocorrências e, a cada vez que logar no sistema, havendo algum chamado em aberto, aparecerá para acompanhamento. O responsável pela área pode direcionar o chamado a qualquer um dos seus técnicos (figura 4), de acordo com o tipo de problema. Figura 4 - Fluxograma de abertura e atendimento de chamados O usuário pode, a qualquer momento, acessar o sistema para verificar o status do seu chamado. Tanto o técnico como o solicitante têm informações na tela sobre seus chamados em aberto: seu status (em atendimento, aguardando atendimento, finalizado), tempo válido, tempo de resposta e tempo de solução. É interessante ressaltar que os dois últimos itens (tempo de resposta e
7 tempo de solução) são pré-definidos pelo administrador do sistema, podendo ser configurado um tempo padrão de reposta de 30 minutos, por exemplo, e tempos aleatórios de solução (definidos por problema). Para todos os tempos (SLAs) existem indicadores coloridos. Quando o tempo de resposta está abaixo do tempo pré-estabelecido (SLA) ele fica na cor verde, se ele ultrapassar este tempo a cor do indicador passa para vermelho, indicando situação de atenção. O mesmo vale para o tempo de solução. Estes recursos possibilitam uma clara e imediata visualização das prioridades e prazos de trabalho, ao passo que o usuário também poderia certificar-se de que seria atendido, com previsão e acompanhamento de sua ocorrência. Um dos recursos administrativos mais importantes é o módulo de relatórios, através do qual é possível cruzar informações dos atendimentos, como: problemas por área de atendimento, locais mais atendidos, tempo de atendimento aos chamados, relatórios de chamados por equipamentos, quantidade de chamados por área, chamados por categoria de problemas, etc. Resultados obtidos A experiência com a autenticação de usuários através de serviço LDAP forçou a equipe de desenvolvedores a conhecer melhor o código-fonte do Ocomon e a buscar e adquirir conhecimento sobre a implementação de soluções de autenticação sobre este tipo de serviço. O LDAP acabou se mostrando interessante como diretório de usuários centralizado, principalmente em função da facilidade de manutenção e consulta à sua estrutura hierárquica, em forma de árvore. O mapeamento inicial das áreas e problemas de suporte, feito pela equipe de analistas, pôde ser refinado através de conversas com os administradores do NTIC e reuniões com o diretor no núcleo, que determinou sua configuração final (figura 5), questão crucial para a organização do sistema e das próprias equipes de suporte. O mapeamento de áreas e problemas foi feito de forma deixar as interfaces do sistema de chamados o mais simples e enxutas possível para os usuários finais, o que foi atingido de maneira satisfatória. Figura 5 - Mapeamento do das áreas de suporte através do software Cayra Através da adaptação do Ocomon aos processos de atendimento da UNIPAMPA, foi possível centralizar, em uma única interface, o gerenciamento e controle do suporte aos sistemas de informação em uso na universidade, atendendo às necessidades dos usuários de várias áreas técnicas. Para testar o sistema, foram abertos, entre 11 de fevereiro de 2010 a 14 de abril de 2010, aproximadamente 274 chamados. Dos chamados abertos no sistema, 65 deles passaram por todo o fluxo do processo, até o encerramento ou cancelamento e 46 estão percorrendo o processo (em
8 aberto). Os demais foram excluídos do sistema (utilizados apenas para testes pontuais). Até o presente momento, 29 usuários reais já participaram da avaliação e validação do sistema. O sistema está nas fases finais de depuração, testes com os usuários finais e em estágio avançado de consolidação, apresentando melhorias advindas de adequações técnicas e formalização dos setores e processos de atendimento. Esta ferramenta torna possível a abertura de chamados, o acompanhamento online, a avaliação do tempo de atendimento, permitindo a identificação de fraquezas e potencialidades do suporte técnico. Após o período final de testes, restrito a um conjunto reduzido de usuários finais, o sistema será amplamente divulgado em todos os campi da UNIPAMPA. Fato este que deverá ocorrer em breve. Nessa nova fase, de uso intensivo do sistema, um dos objetivos é avaliar o impacto de seu uso nas diferentes unidades da instituição. Conclusão Este trabalho mostrou que os instrumentos de pesquisa e avaliação foram válidos e vitais para a escolha de um sistema de chamados adequado as necessidades da instituição e de relativo agrado aos usuários finais. Diante do grande conjunto de sistemas existentes, com a finalidade gerenciar chamados, foi possível encontrar a solução mais adequada para o problema na instituição. Os próprios usuários, que participaram do processo de avaliação, maturação e testes do sistema, manifestaram-se favoravelmente a esse importante ferramenta de gestão de demandas de suporte. Esse é um ponto muito importante na definição de qualquer sistema. A partir da adaptação do sistema, o mesmo tem se mostrado qualificado para atender as demandas de suporte técnico da instituição, resolvendo os problemas da sobrecarga de mensagens, sem nenhum controle específico. Outro aspecto impactante é o fato de o sistema promover uma maior transparência para o usuário sobre todo o processo de atendimento dos chamados. Entre os trabalhos futuros podem ser incluídos: 1) melhorias com vistas à acessibilidade do sistema; 2) melhorias, em termos de simplicidade e eficiência, com vistas ao gerenciamento dos responsáveis pelo suporte (hoje, o administrador do sistema precisa acessar o sistema, identificar o responsável de cada área e definir o respectivo perfil do usuário); 3) incrementos na parte de relatórios gerenciais; e 4) inclusão de notificações gerenciais mensais automáticas. Referências Bibliográficas CAYRA. Versão Softonic International S.L., Disponível em: Acesso em: 7 de abril de CYBIS, Walter; BETIOL, Adriana Holtz; FAUST, Richard. Ergonomia e Usabilidade: Conhecimentos, Métodos e Aplicações. São Paulo: Novatec, DIXON, J. Evaluation tools for flexible delivery (workshop version). Melbourne: TAFE frontiers, GLPI. (2010). The GLPI project. Disponível em: Acesso em: 22 mar OLIVEIRA, Elaine Rosangela de. (2001). Avaliação Ergonômica de Interfaces da Scielo Scientific Electronic Library Online. Disponível em: Acesso em: 20 mar REDMINE. (2010). Disponível em: Acesso em: 25 mar RIBEIRO, Flávio. (2010). O Ocomon. Disponível em: Acesso em: 25 mar
ANEXO V ARTIGOS PUBLICADOS
ANEXO V ARTIGOS PUBLICADOS 1 SUMÁRIO ARTIGOS PUBLICADOS... 3 EVENTO 1 - IV WORKSHOP DE TECNOLOGIA DA INFORMAÇÃO DAS INSTITUIÇÕES FEDERAIS DE ENSINO SUPERIOR DO BRASIL... 4 a) Artigo 1 - Estudo para a migração