service desk via portal corporativo sensÍvel ao … · problema que ocasione o funcionamento...

Proceedings of the XII SIBGRAPI (October 1999) 101-104

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

12 e 13 de agosto de 2011

ISSN 1984-9354

VII CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 12 e 13 de agosto de 2011

102

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


103

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


104

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


105

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


106

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


107

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


108

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


109

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.


110

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:

(1)

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:

(2)


111

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.


112

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.


113

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


114

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.


115

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.


116

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


117

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.

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;

HTC Magic

Sistema Operacional Android Samsung Galaxy Europa

GT-15500

BlackBerry Bold Sistema Operacional

BlackBerry

iPhone 3GS


118

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.


119

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/ problema-

de-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.


120

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.

http://www.teleco.com.br/tutoriais/tutorialsla/default.asp

service desk via portal corporativo sensÍvel ao … · problema que ocasione o funcionamento...

Documents