SERVICE DESK VIA PORTAL CORPORATIVO SENSÍVEL AO CONTEXTO - UMA PROPOSTA PARA MELHORIA NOS SERVIÇOS DE ATENDIMENTO A INCIDENTES DE TI

Proceedings of the XII SIBGRAPI (October 1999) 101-104 ISSN 1984-9354 SERVICE DESK VIA PORTAL CORPORATIVO SENSÍVEL AO CONTEXTO - UMA PROPOSTA PARA MELHORIA NOS SERVIÇOS DE ATENDIMENTO A INCIDENTES DE TI Jaziel Souza Lôbo (Instituto Federal de Sergipe/Universidade Federal de Santa Maria) Érico Marcelo Hoff do Amaral (Instituto Federal Sul-Rio-Grandense/Universidade Federal de Santa Maria) Sandra Dutra Piovesan (Universidade Federal de Santa Maria) Roseclea Duarte Medina (Universidade Federal de Santa Maria) Resumo A diversidade de hardware e software aliada as atuais exigências dos usuários torna o atendimento do service desk mais complexo e cria uma nova demanda: a alocação de recursos humanos que apresentem o perfil adequado para resolução dos difeerentes tipos de problemas. Este trabalho apresenta a adaptação de uma ferramenta de service desk envolvendo características da computação sensível ao contexto de localização, temporal e de expertise do técnico. Como principais resultados, obteve-se um sistema de service desk sensível ao contexto que otimiza as chamadas de suporte pela expertise e a localização geográfica do técnico, que utiliza neste experimento uma variedade de dispositivos móveis. Palavras-chaves: Gerência de Incidentes, Governança de TI, Computação Ubiqua, Incidentes

1. Introdução As organizações modernas estão se tornando cada vez mais dependentes da Tecnologia da Informação (TI), o que torna imprescindível a implementação de um gerenciamento efetivo da TI para que os altos investimentos realizados no setor possam agregar valor às empresas [Ferreira 2010]. Este panorama exige que as organização sejam mais criativas na resolução de seus problemas, tornando clara a necessidade de melhorar seus procedimentos de negócio para obter uma maior qualidade agregada aos produtos e a satisfação de seu público-alvo. Segundo [Magalhães e Pinheiro 2007] 88% dos executivos da área financeira afirmam que a eficiênia operacional dos atuais serviços de TI é muito mais preocupante que o atendimento a novas necessidades. Para [Cusick e Ma 2010], o impacto sobre as receitas está diretamente relacionado com a disponibilidade dos sistemas, o que pode ser comprovado com fatos como o prejuízo de 10 milhões de dólares que a empresa Symantec obteve após uma falha em seu sistema de vendas [IDG Now 2011]; ou o da empresa ebay que perdeu entre US$ 3 e 5 milhões em receitas e declínio de 26% no valor das ações após uma indisponibilidade de 22 horas por falha no sistema [Magalhães e Pinheiro 2007]. Dessa forma quando surge um problema que ocasione o funcionamento anormal dos serviços de TI, espera-se que o usuário tenha uma resposta rápida e clara da equipe de suporte a fim de minimizar os prejuízos que podem ser causados. A equipe responsável por resolver os problemas de TI, foi inicialmente denominada Help Desk [Cavalari e Costa 2005], mas devido a sua importância e a novos serviços agregados à sua área de atuação, passou a ser chamada de Service Desk ou Central de Serviços [Jäntti e Kalliokoski 2010]. Segundo [Zahedi, Rahimov e Soleymani 2008] o tempo é um parâmetro considerado importante para o help desk de forma que os técnicos desta atividade, justamente por limitações de tempo para resolver os mais variados tipos de problemas, muitas vezes se referem ao help desk como hell desk dando uma conotação de trabalho do inferno. Para [Magalhães e Pinheiro 2007] um dos fatores essenciais para o sucesso de um service desk é a alocação de recursos humanos que tenham o perfil adequado para resolução dos diferentes tipos de problemas. Um service desk cujos técnicos trabalhem sem planejamento algum, atendendo as chamadas desordenadamente, ou ainda cujos técnicos sejam alocados a 102

chamadas que eles não tenham a expertise (experiência e prática) para a solução do problema, pode ocasionar: para o técnico a perda de tempo pelo deslocamento desnecessário; para o usuário a ociosidade devido à falta de solução do incidente no primeiro atendimento; e para a empresa prejuízos contabilizados pela parada dos serviços. Desta forma torna-se necessário que o sistema que dá apoio a central de serviços ajude a minimizar as ocorrências de técnicos atendendo a chamadas que eles não possam solucionar por não ter a expertise necessária e que ainda ajude a otimizar o tempo perdido com tais deslocamentos. Um dos campos de estudo da computação que pode ser utilizado para adaptar um sistema de service desk em função das tarefas do usuário é a Computação Ubíqua através de uma das suas principais áreas de pesquisa, a computação ciente ou sensível ao contexto [Loureiro et al. 2009]. Este trabalho apresenta a adaptação de uma ferramenta de service desk desenvolvida por um programa de Pós-Graduação na Universidade Federal de Santa Maria (UFSM). As adequações envolvem características da computação sensível ao contexto de localização, temporal e de expertise do técnico. Como principais resultados, obteve-se um sistema de service desk sensível ao contexto (sdvpc-sc), que possibilita o seu acesso por meio de dispositivos móveis, com a otimização das chamadas através da expertise e a localização geográfica do técnico. Para validação, foram inseridos dados simulados de forma que fosse possível testar o comportamento e funcionamento do sistema. Os testes foram realizados no campus da UFSM com aparelhos do tipo smartphones que possuíam GPS integrado. Este artigo está organizado da seguinte forma: na seção 2 são apresentados conhecimentos sobre aspectos gerenciais e tecnológicos necessários para o entendimento desta pesquisa; Na seção 3 discutem-se os trabalhos relacionados. Na seção 4 é apresentada a proposta do projeto, e as alterações realizadas na ferramenta de service desk. Os Experimentos e a discussão sobre os testes são apresentados na seção 5 e na seção 6 são apresentadas as conclusões. 2. Aspectos Gerenciais e Tecnológicos Esta seção apresenta uma breve revisão sobre os principais aspectos gerenciais e tecnológicos que nortearam o projeto do sdvpc-sc. No contexto deste estudo o entendimento da área gerencial, identificação de incidentes e o conhecimento técnico em computação foram requisitos fundamentais para o êxito da pesquisa. 2.1. Gerência de Incidentes 103

Incidente segundo [Bom 2006] é qualquer evento que não faz parte do funcionamento normal de um serviço que causa, ou pode causar, a sua interrupção ou uma redução da qualidade. Em nível gerencial, incidente é qualquer acontecimento que altere os níveis de serviço estipulados nos acordos de nível de serviço (SLA), ou ainda qualquer acontecimento que não faça parte da operação normal dos sistemas e ambientes estabelecidos [OGC 2001]. A Gerência de incidentes está descrita na biblioteca de infra-estutura ITIL (Information Technology Infraestructure Library) desenvolvida pelo CCTA (Central Computer and Telecommunications Agency) atualmente OGC (Office of Government Commerce), no final dos anos 80. Esta biblioteca foi criada a partir de uma necessidade do governo britânico, para implementar uma abordagem de melhores práticas, para gerenciar a utilização eficiente e responsável dos recursos de TI, aplicáveis a organizações com necessidades técnicas e de negócio distintas [Fernandes; Abreu 2008]. Quando se fala em boas práticas refere-se a resultados significativos que atendam a melhoria da TI, isto é, operações de empresas e aprimoramento de níveis de serviços. A função da Gerência de Incidentes é a resolução mais rápida possível destes erros, retomando o estado de funcionamento das soluções de TI para os níveis acordados, ou níveis normais de operação [Macfarlane; Rudd 2005]. Este é um dos processos mais reativos, pois entrará em atuação a partir dos incidentes levantados por usuários ou ferramentas de monitoramento. Entretanto este processo é vital para manter a agilidade dos serviços de TI. O tratamento de incidentes deve ser um serviço oferecido no âmbito da organização, e a produção e entrega desses serviços exige um nível adequado de interação entre o cliente e o provedor. A identificação da qualidade do serviço prestado pode ser estabelecida por parte do cliente, avaliando aspectos técnicos e de interação. A qualidade técnica está calcada basicamente em fatores tecnológicos, enquanto a qualidade de interação é totalmente dependente da percepção do cliente, o que muitas vezes é imprevisível e subjetiva. Para que este processo de prestação de serviços ocorra corretamente, é necessário a definição de um conjunto claro de compromissos entre as duas partes envolvidas. Esta forma de agir é extremamente importante para a área de TI, ao ponto que esta é vista dentro da organização como um provedor de serviços. A tendência é que isso seja baseado em um contrato que descreva explicitamente os produtos (bens ou serviços a serem contratados) e os índices a serem atingidos para o cumprimento do conjunto de compromissos acordados. Esse contrato tem sido representado por um instrumento denominado SLA (Service Level Agreement). Segundo [Tude 2003], SLA é um documento formal, negociado entre as partes, na 104

contratação de um serviço de TI ou telecomunicações, a fim de definir os níveis de serviços fornecido pela prestadora com base nos requisitos que o usuário possui e as necessidades reais da organização. 2.2. Computação Ubíqua Ciente de Contexto Em 1991 o termo Computação Ubíqua foi definido pelo cientista Mark Weiser como um paradigma que possibilitaria a integração e comunicação de diversos dispositivos e recursos (software e hardware) em um ambiente real que possibilitaria ao usuário realizar atividades sem a consciência da utilização desses dispositivos e recursos computacionais [Weiser 1991; Satyanarayanan 2001]. Outros paradigmas surgiram como a Computação Pervasiva (Pervasive Computing) que previa o acesso as informações e recursos computacionais pelo usuário em qualquer local (anywhere), a qualquer hora (anytime) e utilizando qualquer dispositivo (any device). Atualmente os termos Computação Pervasiva e Computação Ubíqua são usados como sinônimos por muitos pesquisadores e assim será considerado neste texto. Uma das principais áreas de pesquisa da computação ubíqua é a computação ciente ou sensível ao contexto (Context-Aware Computing) na qual se pretende obter entradas, os chamados contextos, que são informações atuais do usuário, contextualizando o ambiente onde ele se encontra e o dispositivo computacional utilizado [Loureiro et al. 2009]. Para [Dey 2001] contexto é qualquer informação que pode ser utilizada para caracterizar a situação de uma entidade, onde esta entidade pode ser uma pessoa, um lugar ou um objeto que seja considerado relevante para a interação entre um usuário e uma aplicação, incluindo o usuário e a própria aplicação. Segundo o autor, um sistema é ciente de contexto se ele usa contexto para fornecer informações e/ou serviços relevantes para o usuário, onde a relevância dependa da tarefa do usuário. De acordo com [Satyanarayanan 2001], um sistema de computação pervasiva que se esforça para ser minimamente invasivo tem que ser sensível ao contexto e ter ciência do estado e arredores de seu usuário para, com base nessas informações, modificar o seu comportamento. Um componente fundamental da computação ubíqua é o contexto de localização (location awareness) que utiliza um sistema de posicionamento para obter a localização do usuário [Akgul e Pahlavan 2009]. Para [Loureiro et al. 2009] um sistema de posicionamento é uma ferramenta usada para determinar e registrar a localização de um objeto na superfície da Terra. A primeira tentativa séria para localização iniciou-se com um projeto militar dos EUA 105

e deu origem ao Global Positioning System (GPS) ou Sistema de Posicionamento Global. O GPS que é o primeiro sistema de posicionamento a oferecer dados de localização de alta precisão para qualquer ponto do planeta, em qualquer tempo, atualmente é utilizado por inúmeras aplicações, sendo encontrado dentro de carros, barcos, aviões, máquinas agrícolas, etc. [NASA 2010; TRIMBLE 2010; Akgul e Pahlavan 2009]. Um receptor de GPS após detectar o sinal de três ou mais satélites pode calcular sua localização com erro de poucos metros [Dittmer 2005]. Com a tentativa de agregar serviços e modelos de negócios para dispositivos ubíquos em rede, o World Wide Web Consortium (W3C) instituiu, em março de 2007, o grupo de trabalho Ubiquitous Web Applications que definiu uma API de Geolocalização. Esta API que fará parte da HTML 5 possui uma interface de alto nível para as informações de localização (latitude e longitude) e oferece suporte para navegadores móveis e aplicações LBS (Serviços Baseados em Localização) [W3CGeo 2008; Vaughan-Nichols 2010]. Apesar da HTML 5 ainda ser um projeto e não um padrão recomendado pelo W3C, os principais navegadores do mercado já estão dando apoio e suportando a API de Geolocalização Peji, Peji e ovi 2010]. 3. Trabalhos Relacionados As pesquisas por trabalhos relacionados mostraram que muitos autores abordam aspectos de como melhorar o controle da gestão dos incidentes ou abordam aspectos de como melhor implementar a Information Technology Infrastructure Library (ITIL). Até onde se pesquisou não foram localizados estudos com abordagens sobre a otimização da equipe de trabalho para reduzir o custo com diagnósticos por técnicos que não possuam a expertise ideal para o incidente relatado. A seguir alguns dos trabalhos pesquisados. No trabalho de [Zahedi, Rahimov e Soleymani 2008] foi porposto um help desk que simula um centro de suporte técnico através de um site web, no qual o visitante faz perguntas e recebe conselhos automaticamente. Já no trabalho de [Jäntti 2009] foi explorado quais são os requisitos básicos funcionais para um sistema de gerenciamento de incidentes. [Bartolini, Stefanelli e Tortonesi 2009] apresentam o software HANNIBAL, uma ferramenta de apoio à decisão para análise do impacto empresarial e a melhoria do processo de gerenciamento de incidentes. No trablaho de [Marcu et al. 2009] é proposto um método para correlacionar chamadas abertas pelo usuário com chamadas abertas automaticamente por sistemas de 106

monitoramento de forma a evitar perda de tempo com diagnósticos para incidentes de um mesmo problema. Os trabalhos de [Cusick e Ma 2010] e [Pereira e Silva 2010] abordam qual é a melhor forma para a implementação dos processos da bilbioteca ITIL - Information Technology Infrastructure Library. Existem alguns softwares no mercado que incorporam mecanismos similares à expertise que é utilizada neste trabalho, de forma que o usuário ao relatar o seu incidente, opta por um dos setores ou departamento para fazer o direcionamento da chamada para atendimento. Outra funcionalidade também disponibilizada é a determinação da prioridade do incidente. Ambas as funcionalidades são encontradas, por exemplo, nos softwares Trellis Desk [ACCORD5 2011] e OcoMon [Ocomon 2010] e são informadas pelo usuário que reporta o incidente. Esta inserção de dados pelo usuário pode gerar dois problemas: O primeiro ligado à prioridade, pois o sistema poderá ser inundado com chamadas de prioridade críticas daqueles usuários que acreditam ser o seu problema o mais importante a ser resolvido; e o segundo está ligado ao direcionamento da chamada, pois nem sempre o usuário tem o real conhecimento do problema ou quais são os problemas que todos os setores estão aptos a resolver. Outro software analisado, o Spiceworks [Spiceworks 2011], permite que o direcionamento da chamada seja feito para um técnico específico, sendo também o usuário o responsável por esta informação. Esta funcionalidade também está presente nos outros softwares e, se mal utilizada, pode ocasionar a concentração de chamadas para um técnico em detrimento de outros que possam ficar totalmente ociosos, além de que chamadas podem ser direcionadas para técnicos que não possuam a expertise necessária para resolvê-la. 4. sdvp-sc Service Desk Via Portal Corporativo Sensível ao Contexto Os atuais smartphones e celulares com grande capacidade computacional possuem além das funcionalidades originais como a comunicação via telefonia celular, diversas outras funcionalidades e interfaces agregadas como, por exemplo, GPS, rádio e TV e câmeras fotográficas digitais que abrem espaço para a modelagem de aplicações para a computação ubíqua [Loureiro et al. 2009]. Este trabalho propõe adaptar, para este tipo de ambiente, um sistema de service desk que possa minimizar as ocorrências de um segundo atendimento para uma mesma chamada que não foi encerrada por falta de expertise (conhecimento e prática) do técnico que realizou o primeiro atendimento. Além dessas características, este sistema deve reduzir a perda de tempo com deslocamentos desnecessários e possibilitar o seu acesso de 107

qualquer lugar a qualquer hora e com qualquer dispositivo. O sistema de service desk adaptado foi apresentado no trabalho de [Amaral 2010], que integrou um sistema de service desk a um portal corporativo para a realização da gestão de incidentes e direitos de acesso do usuário (autenticação, autorização, auditoria) com coleta de dados para apoio à decisão, baseado em técnicas estatísticas multivariadas. O trabalho explorou a quantificação dos dados coletados, com a utilização de uma seqüencia de processos desde a definição dos perfis de usuários, categorização dos eventos e utilização de uma matriz de priorização para possibilitar o estudo estatístico multivariado da amostra dos dados reportados ao sistema. 4.1. Tarefa 1 - Identificação do Contexto O trabalho proposto trata da adequação de um Service Desk para fornecer serviços relevantes aos técnicos de suporte através da identificação de um contexto qualquer. O sistema é composto por um conjunto finito de técnicos definido como com ; expertises definida por com ; prédios definidos por onde ; perfis definido por e prioridades definida por. O sistema está dividido em duas tarefas principais: Tarefa 1 responsável por identificar um contexto e Tarefa 2 responsável por adaptar o sistema para o contexto. O contexto é definido no momento em que um técnico faz o acesso ao sistema e é composto por dados da localização geográfica (latitude e longitude) e perfil do técnico e o horário do acesso ao sistema. 4.1.1. Obtendo a Localização Geográfica do Técnico A proposta do W3C com a API de Geolocalização é que um site ao ser visitado possa receber as coordenadas (latitude e longitude) do dispositivo que o está acessando, sem que nenhuma aplicação cliente seja instalada neste dispositivo. Por questões de segurança, é necessário que o usuário ao acessar o site autorize o compartilhamento da sua informação. Este mecanismo foi implementado no service desk de forma que quando um técnico se autentica no sistema, é executado o script Javascript: navigator.geolocation.getcurrentposition(position), que 108

retorna uma objeto de posicionamento através da função position. Durante este processo erros podem acontecer como: Permissão Negada, quando não é compartilhada a localização; Posição Indisponível, quando os satélites de GPS não puderam ser alcançados ou quando algo semelhante ocorreu; e ainda o erro de tempo esgotado na tentativa de se obter a posição. 4.1.2. Horário de Acesso O horário de acesso ao sistema é utilizado para verificar se o técnico está no período de expediente, ou seja, se ele está acessando o sistema no seu turno de trabalho. O contexto temporal aqui inserido visa permitir a distribuição das equipes de suporte por turno para atender escalas de plantão 24x7, como funciona a maioria das equipes de TI. 4.1.3. Perfil do Técnico Baseado na divisão que ocorre na Central de Atendimentos ao Usuário (CAU) da UFSM, os técnicos são mapeados em quatro perfis: Técnico Classificador, Técnico de Atendimento, Técnico que Classifica e Atende e Administrador. O Técnico Classificador é aquele técnico que terá permissão para classificar as chamadas (tickets) através da definição da prioridade e da expertise necessária para solucionar o problema relatado. O Técnico de Atendimento terá permissão apenas para visualizar e atender os tickets que previamente foram classificados. O Técnico que Classifica e Atende acumula as permissões dos dois papeis anteriores e, portanto, pode realizar atendimentos e classificar chamados. O último técnico é aquele que possui perfil de administrador. 4.1.4. Acesso Interno ou Externo É possível determinar se um técnico terá acesso ao sistema quando estiver fora do prédio da central de serviços (ambiente externo) ou se ele somente terá acesso nas imediações do prédio (ambiente interno). A localização interna ou externa do técnico é dada pelo cálculo da distância, em km, entre o técnico e o prédio da central de serviços. Para este trabalho considerou-se que a uma distância de até 300m ( ), que é aproximadamente a distancia entre um prédio e outro no campus, o sistema irá considerar que o técnico está no chamado ambiente interno. Caso contrário é considerado que o técnico está em ambiente externo. 109

4.1.5. Cálculo da distância entre e Ao ser reportado um incidente, o usuário deverá informar qual o prédio e sala que o problema ocorreu. Os prédios devem ser previamente cadastrados com as suas respectivas coordenadas. O cálculo da distância entre um técnico e um prédio é utilizado tanto para verificar se o técnico está em ambiente interno ou externo, quanto para ordenar a relação de chamadas que o técnico irá atender. Conhecendo-se os pontos formados pelas coordenadas de e, aplicam-se as fórmulas da trigonometria esférica para calcular a distância, em graus, formada pelos arcos de circunferência entre esses pontos e desses pontos em relação ao ponto A (Figura 1) [Silva e Sucena 2009]. Figura 1. Arcos considerados para o cálculo da distância entre dois pontos por meio da trigonometria esférica Para o cálculo da distância serão utilizadas três equações. A primeira equação é dada pela expressão: Onde, a = Arco BC formado pela diferença da longitudes das duas coordenadas b = Arco AC que é igual a 90 latitude do prédio do suporte c = Arco AB que é igual a 90 latitude do técnico de atendimento Os valores das coordenadas na equação (1) devem ser informados em valores decimais e os valores recebidos ao invocar o método W3C Geolocation estão em graus, minutos e segundos, necessitando-se de uma conversão. Encontrado o valor do cos(a) na equação 1, aplica-se a equação 2 que calcula o arco cosseno do valor encontrado: (1) (2) 110

Ao contrário do que ocorre na equação 1, o valor encontrado na equação 2, em radianos, representa o arco formado entre o técnico e prédio e deve ser convertido para graus para que seja aplicado na equação 3. Após obter-se o valor do arco em graus, para calcular o valor em km, que representa a distância, deve-se aplicar uma regra de três entre este valor e o valor do arco completo da circunferência da Terra. Sabendo-se que o raio da Terra é de 6.371 km, o. Obtido o valor do arco completo da terra, aplica-se a equação 3 para calcular a distância em quilômetros dos dois pontos: (3) 4.1.6. Algoritmo da Tarefa 1 O Algoritmo 1 abaixo representa a execução para a tarefa 1 e se subdivide em três sub-tarefas, que são emexpediente, nolocal e distância, detalhadas a seguir: Algoritmo 1 1. 2. ; 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 111

13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. ; 32. 33. 34. 35. 36. 37. ; 38. 39. 40. 41. 42. 43. 44. 112

45. 46. ; ; ; ; ; 47. ;$ 48. ; 49. ; 50. 51. 52. ; 53. ; 4.2. Tarefa 2 - Aplicação do Contexto Ao serem definidos os perfis dos técnicos, definiram-se também os contextos que deveriam ser aplicados para cada um deles. É através da Tarefa 2 que o sistema irá sugerir as ações que o usuário poderá realizar. 4.2.1. Contexto para o Técnico de Classificação O técnico classificador é aquele técnico que têm permissão apenas para classificar os tickets. Dessa forma o sistema deve permitir o seu acesso apenas para visualizar as chamadas que foram reportadas, mas que ainda não foram classificadas. Além dessa permissão, o sistema reagirá diferente se o técnico não estiver dentro do seu horário de expediente ou caso alguma empresa considere relevante que este técnico não deva acessar o sistema de fora do prédio da central de serviço e o defina sem permissão para acesso externo. A Figura 2 mostra as ações do sistema diante deste contexto. Figura 2 Contexto para o Técnico Classificador 113

Conforme Figura 2, o sistema irá liberar ou não o acesso mediante informações obtidas na autenticação do técnico. De acordo com o contexto, o técnico terá seu acesso negado se estiver fora do seu horário de expediente ou se estiver fora da central de serviços e não tiver o acesso externo permitido. Para os demais caso o sistema deverá apresentar ao técnico a interface para classificar os tickets em aberto. 4.2.2. Contexto para o Técnico de Atendimento O Técnico de Atendimento é aquele técnico que vai a campo resolver os incidentes e por padrão possui o acesso externo liberado. Ao realizar a autenticação no sistema o técnico deverá receber uma lista das próximas chamadas que deve atender. Para compor a ordem da lista o sistema deverá levar em consideração três aspectos: expertise, prioridade e localização. Para a expertise o sistema deverá exibir apenas aquelas chamadas abertas que têm relação direta com as expertises que o técnico está apto a resolver. O próximo fator a prioridade faz com que as chamadas de nível mais crítico devem ter prioridade em relação às outras. O terceiro e último critério de ordenação é a localização onde, chamadas de mesma prioridade devem ser ordenadas de acordo com a menor distância entre o técnico e o prédio que elas devem ser atendidas. Diferente do que acontece com o técnico de classificação, mesmo fora do horário de expediente o técnico com perfil para atendimento poderá acessar o sistema, desde que seja para finalizar um ticket ou para informar o andamento da chamada e colocá-la em disponibilidade para outro técnico, o que está sendo chamado de troca de turno. Está peculiaridade foi criada pois existem casos em que o técnico embora não tenham concluído o atendimento, para cumprir o Acordo de Nível de Serviço (ANS), ou em inglês Service Level Agreement (SLA), acordado precisa ultrapassar o seu horário de expediente. Está condição de acesso só é permitida se o técnico estiver com alguma chamada em atendimento. Caso contrário o seu acesso ao sistema será negado. A Figura 3 mostra o comportamento do sistema diante para o contexto do técnico de atendimento. 114

Figura 3 - Contexto para o Técnico de Atendimento 4.2.3. Contexto para o Técnico Classificador e de Atendimento O Técnico Classificador e de Atendimento é aquele técnico que tanto pode classificar quanto realizar atendimento de chamadas, acumulando assim as duas funcionalidades dos perfis anteriores. A Figura 4 mostra o comportamento diante deste contexto. Figura 4 - Contexto para o Técnico Classificador e de Atendimento Na identificação do contexto o sistema irá sugerir, com base na localização do técnico, a interface que deverá ser utilizada. Quando for identificado que o técnico está fora do prédio da central de serviços, automaticamente o sistema exibirá a relação de chamadas para atendimento, sugerindo que se ele está em ambiente externo e provavelmente estará consultando novas chamadas para atendimento. Caso o técnico esteja no prédio da central de serviços, o sistema o direcionará para a tela de classificação de chamadas. Ainda que o sistema sugira uma funcionalidade, a qualquer momento o técnico poderá alternar entre as duas opções. 115

4.2.4. Contexto para o Técnico Administrador O técnico que possui perfil de administrador poderá visualizar todas as chamadas classificadas ou não, as que estão em atendimento e as já finalizadas. Além de visualizar, o administrado pode classificar as chamadas e cadastrar os prédios e suas localizações. Estas possibilidades são mostradas graficamente na Figura 5. Para este contexto, o sistema inicialmente deverá exibir a tela com as chamadas não atendidas e disponibilizar as demais opções. Figura 5 - Contexto para o Técnico Administrador 5. Experimentos e Resultados O sdvpc-sc foi desenvolvido com o framework Django [Django 2010], que utiliza a linguagem de programação Python [Python 2010]. A implementação ocorreu no Eclipse [Eclipse 2010], através da instalação do plugin Pydev [Pydev 2010] que integra a linguagem de programação Python e o framework Django no ambiente de desenvolvimento Eclipse. Para persistência dos dados utilizou-se o banco de dados MySQL [Oracle 2010] e como servidor web o Apache HTTP Server [Apache 2010].Para a realização dos testes cadastrou-se um conjunto de expertises, prédios e técnicos com perfil para classificação, atendimentos, classificação e atendimento e com perfil de administrador. Cadastrou-se também uma massa de dados com incidentes para os diferentes prédios e com diferentes prioridades e expertise. Para [Moreira et al. 2009] sistemas de comunicação em geral, e para sistemas sem fio, em particular, a experiência mostra que os resultados de simulação nem sempre correspondem aos obtidos em implementações reais, pois a simulação normalmente baseia-se em modelos simplificados, que não consideram aspectos importantes que surgem ao se implementar a proposta em um ambiente real. Para este trabalho ainda que se tenham utilizados dados de simulação, a validação do sistema ocorreu em um ambiente real e com aparelhos reais do tipo smartphones que possuíam GPS integrado e sendo realizados no campus da UFSM em Santa Maria (RS) pelo período de 45 dias. Inicialmente os testes concentraram-se em consolidar o 116

mecanismo de obtenção da localização do técnico através do dispositivo móvel. A Figura 6 apresenta telas capturadas nesta fase inicial de testes. HTC Magic Sistema Operacional Android Samsung Galaxy Europa GT-15500 BlackBerry Bold Sistema Operacional BlackBerry iphone 3GS Figura 6. Solicitação de permissão para acessar a localização do dispositivo Na figura podem ser vistos vários dispositivos que estão exibindo a mensagem que solicita autorização do usuário para acessar a sua localização. Os testes comprovaram que o método W3C Geolocation é eficaz e que efetivamente funciona em vários dispositivos. A segunda bateria de testes objetivou validar a fórmula de cálculo da distância entre o técnico e os prédios com chamadas para atendimento. Nesta fase criou-se paralelamente uma aplicação com apenas duas funcionalidades: cadastrar prédios com suas coordenadas e realizar um comparativo entre os prédios cadastrados. O cadastro de prédios invocava a API W3C Geolocation e o comparativo utilizava a fórmula da trigonometria esférica para exibir os prédios cadastrados ordenados de acordo com a distância entre eles e um prédio utilizado como referência. Os testes mostraram que a fórmula utilizada sempre apresentava os prédios na ordem correta de distância, da menor para a maior. A fase final serviu para validar o funcionamento e comportamento do sistema. Nesta última fase agregaram-se às funcionalidades da classificação, atendimento e administração. Por meio da funcionalidade de administração foi possível cadastrar os prédios e acompanhar as ocorrências das chamadas reportadas no sistema. Na classificação, os técnicos registravam a prioridade e expertise necessária para cada ticket. Com relação ao atendimento, os tickets eram apresentados aos técnicos de acordo com a sua expertise e ordenados de acordo com a prioridade e a menor distância entre o prédio para atendimento e a localização do técnico; 117

6. Conclusão A demora no diagnóstico de incidentes tem gerado altos prejuízos às organizações e um dos fatores que tem gerado essa demora é a reincidência do atendimento que é provocada pela alocação de técnicos que não possuem a expertise correta para a solução do incidente relatado. Para solução deste problema foram incluídas características de computação ubíqua na adaptação de um sistema de service desk. Os testes mostraram que utilizar um contexto que considere a expertise e a localização do técnico minimiza a reincidência do atendimento provocada pela alocação indevida do técnico. Outra capacidade incorporada ao sistema é a possibilidade de direcionar automaticamente o técnico para atender chamadas mais próximas geograficamente, reduzindo o tempo em deslocamentos desnecessários que eram feitos pelo técnico que saia de um prédio A para um prédio B e depois era informado que havia outro chamado no prédio A. A implementação da sensibilidade ao contexto, para a redução de deslocamentos desnecessários deu maior agilidade no atendimento, o que possibilita que tanto a empresa ganhe por ter um menor tempo de inatividade, quanto por reduzir o tempo do diagnóstico dos incidentes. Comparando-o com outros sistemas similares disponíveis no mercado, observa-se que as aplicações que possuem algum mecanismo para direcionar as chamadas acionadas pelo próprio usuário, apresentam vários problemas, justamente pelo desconhecimento técnico de suporte de tais usuários. Outra característica presente nestes softwares é a atribuição da prioridade da chamada que também é realizada pelo usuário. Neste caso, pelo mesmo motivo de falta de conhecimento técnico ou ainda por ter interesse na resolução imediata do seu problema, os usuários poderão classificar as suas chamadas sempre com as prioridades mais altas o que pode impactar no desempenho do setor de TI. No caso do sdvpc-sc, é o técnico da central de serviços que possui o perfil de classificador que tem a responsabilidade por determinar a prioridade e a expertise necessária para a resolução do problema relatado. As características como ordenação da chamada de acordo com a localização do técnico e a definição da jornada de trabalho do técnico para definição de escalas que estão presentes no sdvpc-sc não foram encontradas nos softwares estudados. Considerando-se do ponto de vista da implementação, os testes demonstraram que o sistema é tecnicamente viável e que as adaptações realizadas neste trabalho podem ser facilmente implementadas em diferentes tipos de sistemas da mesma categoria. 118

Referências ACCORD5 (2011) ACCORD5 - Trellis Desk., http://www.accord5.com/trellis. Akgul, F. O., Pahlavan, K. (2009) Location awareness for everyday smart computing, In ICT '09 - International Conference on Telecommunications, p. 2-7. Amaral, E. M. H. D. (2010) Gerência pró-ativa de incidentes de segurança através da quantificação de dados e da utilização de métodos estatísticos multivariados, p. 137, Dissertação, UFSM. Apache. (2010) The Apache HTTP Server Project., (http://httpd.apache.org/). Bartolini, C., Stefanelli, C. e Tortonesi M. (2009) Business-impact analysis and simulation of critical incidents in IT service management, In: Integrated Network Management, 2009. IM '09. IFIP/IEEE International Symposium on, p. 9-16. Bom, J. V. Fundamento do gerenciamento de Serviços em TI Baseado no ITIL. itsmf, Van Haren Publishing, 2006. Cavalari, G O. T. e Costa, H. A. X. (2005), Revista Eletrônica de Sistemas de Informação. Modelagem e Desenvolvimento de um Sistema Help-Desk para a Prefeitura Municipal de Lavras - MG. Cusick, J. J. e Ma. G. (2010) Creating an ITIL inspired Incident Management approach: Roots, response, and results., In: Network Operations and Management Symposium Workshops (NOMS Wksps), 2010 IEEE/IFIP, p. 142-148. Dey, A. K. (2001) Understanding and Using Context. In: Personal Ubiquitous Comput, p. 4-7. Dittmer, J. (2005) Solving the GPS Urban Canyon Problem. Frost and Sullivan. http://www.frost.com/prod/servlet/market-insight-top.pag?docid=43176366 Django (2010) Django Software Foundation. The Django framework. http://www.djangoproject.com/ Eclipse (2010) Eclipse - The Eclipse Foundation open source community website., http://www.eclipse.org/ Fernandes, A. A. e ABREU, V. F. Implantando a Governança de TI da Estratégia à gestão dos Processos e Serviços. 2º Edição, Brasport Editora, 2008. Ferreira, R. V. (2010) Impacto dos Investimentos em Tecnologia da Informação na Geração de Valor da Firma: Estudo Multicaso com Empresas de Panificação do Estado de Minas Gerais, p. 195, Dissertação, UFPA. IDG Now (2011) Problema de ativação em antivírus gera prejuízo de US$ 10 milhões à Symantec. Site da IDG Now. http://idgnow.uol.com.br/seguranca/2010/10/28/ problemade-ativacao-gera-prejuizo-de-us-10-milhoes-a-symantec/. Jäntti, M. (2009) Defining Requirements for an Incident Management System: A Case Study. In: ICONS '09 - Fourth International Conference on Systems, p. 184-189. Jäntti, M. e Kalliokoski, J. (2010) Identifying Knowledge Management Challenges in a Service Desk: A Case Study. In: eknow '10 - Second International Conference on Information, Process, and Knowledge Management, p. 100-105. Loureiro, A. A. F., et al. (2009) Computação Ubíqua Ciente de Contexto: Desafios e Tendências, In: Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos., p. 99-149. Macfarlane, Ivor e Rudd, Colin IT Service Management. New Millenium Editora, São Paulo, 2005. 119

Magalhães, I. L. e Pinheiro, W. B.( 2007) Gerenciamento de Serviços de TI na Prática: Uma abordagem com base na ITIL. São Paulo: Novatec. Marcu, P., et al. (2009) Towards an optimized model of incident ticket correlation. In: Integrated Network Management, 2009. IM '09. IFIP/IEEE International Symposium on, p. 569-576. Moreira, M. D. D., et al. (2009) Internet do Futuro: Um Novo Horizonte, In: Simpósio Brasileiro de redes de Computadores-SBRC., p. 02-59. NASA (2010) GPS Applications Exchange, National Aeronautics and Space Administration, http://gpshome.ssc.nasa.gov/content.aspx?s=gps Ocomon (2010) OcoMon - Monitor de Ocorrências e Inventário de equipamentos de informática, http://ocomonphp.sourceforge.net/. OGC Office Of Government Commerce. ITIL for Service Delivery, 1º Edição Stationery Office BO, 2001. Oracle (2010) MySQL - The world's most popular open source database, http://www.mysql.com. Peji, B., Peji, A. e ovi, Z. (2010). Uses of W3C's Geolocation API, In:11th International Symposium On Computational Intelligence and Informatics (CINTI), p. 319-322. Pereira, R. e Silva, M. M. (2010). ITIL maturity model. In: Information Systems and Technologies (CISTI), 2010 5th Iberian Conference on, p. 1-6. Pydev (2010), http://pydev.org/. Python (2010) Python Software Foundation, http://www.python.org/ Satyanarayanan, M. (2001) Pervasive computing: vision and challenges, In: IEEE Personal Communications, p. 10-17. Silva, V. L. D. e Sucena, M. P. (2009) Localização de Facilidades: estudo de caso aplicado a escolha adequada de aeroporto para a minimização dos custos logísticos de distribuição de produtos farmacológicos.. Spiceworks (2011) Spiceworks Free Network Management Software, http://www.spiceworks.com/. Trimble (2010) Trimble GPS Tutorial, http://www.trimble.com/gps/index.shtml. Tude, Eduardo. Service Level Agreement (SLA). Tutorial publicado no site telec.com.br em 07/07/2003. Disponível em http://www.teleco.com.br/tutoriais/tutorialsla/default.asp. Vaughan-Nichols, S. J. (2010) Will HTML 5 Restandardize the Web? Computer, p. 13-15. W3CGeo (2008) W3C Geolocation Working Group. http://www.w3.org/2008/ geolocation/. Weiser, M. (1991) The Computer for the 21st Century. http://www.cim.mcgill.ca/~jer /courses/hci/ref/weiser_reprint.pdf. Zahedi, M., Rahimov, H.e Soleymani, F. (2008) A Two-Level Automatic Help Desk Based on a New Statistical Approach. In: Third International Conference On Internet And Web Applications And Services., p. 530-534. 120