service desk via portal corporativo sensÍvel ao … · problema que ocasione o funcionamento...
Post on 23-Nov-2018
214 Views
Preview:
TRANSCRIPT
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
VII CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 12 e 13 de agosto de 2011
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
VII CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 12 e 13 de agosto de 2011
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
VII CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 12 e 13 de agosto de 2011
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
VII CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 12 e 13 de agosto de 2011
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
VII CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 12 e 13 de agosto de 2011
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
VII CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 12 e 13 de agosto de 2011
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
VII CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 12 e 13 de agosto de 2011
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.
VII CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 12 e 13 de agosto de 2011
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)
VII CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 12 e 13 de agosto de 2011
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.
VII CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 12 e 13 de agosto de 2011
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.
VII CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 12 e 13 de agosto de 2011
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
VII CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 12 e 13 de agosto de 2011
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.
VII CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 12 e 13 de agosto de 2011
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.
VII CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 12 e 13 de agosto de 2011
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
VII CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 12 e 13 de agosto de 2011
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
VII CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 12 e 13 de agosto de 2011
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.
VII CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 12 e 13 de agosto de 2011
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.
VII CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 12 e 13 de agosto de 2011
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.
top related