SISTEMA SERVICE DESK
Taiana Rosales de Oliveira [email protected]
Anderson Ricardo Yanzer Cabral [email protected]
Universidade Luterana do Brasil (Ulbra) – Curso de Sistemas de Informação – Câmpus Guaíba
BR 116 KM 299 N° 5724, – CEP 92500-000 – Guaíba – RS
1
INTRODUÇÃO
Este artigo apresenta um sistema desenvolvido para atender uma multinacional que atua no
ramo de atividade metal-mecânico, sendo que seu foco está no fornecimento de produtos no
segmento de transporte vertical. Os principais produtos da empresa são elevadores, escadas e
esteiras rolantes, passarelas para aeroportos (túnel entre o terminal de passageiros e aeronaves) e
armazéns automatizados. A companhia dispõe dos serviços de modernização de equipamentos
instalados e manutenção preventiva e corretiva de seus produtos.
A empresa conta com um parque industrial, localizado em Guaíba/RS, com terreno de
110.000m² e área coberta de aproximadamente 40.000m². O escritório central, denominado Matriz,
está localizado juntamente com o parque industrial e possui doze Filiais, às quais a companhia
denomina de Unidades de Negócio em todo o Brasil e ainda mais 500 postos de atendimento e
assistência técnica.
A empresa possui a necessidade de dispor de uma ferramenta que seja capaz de mapear os
chamados feitos para o suporte e desenvolvimento da área de Tecnologia da Informação, a fim de
melhorar o controle destes serviços e melhor atender seus usuários da matriz e das filiais.
Buscando atender esta necessidade, a empresa comprou duas ferramentas, o ITS1 em
2004/01 e o Qualitor2 em 2004/02, mas as duas ferramentas tratam-se de pacotes fechados, sendo
que qualquer melhoria que viesse a ser solicitada dependia de um novo investimento, e o tempo de
resposta para atendimento destas solicitações pelos desenvolvedores era longo, o que tornava
inviável a customização dos sistemas.
Alguns dos problemas que ocorreram durante o processo de aquisição das ferramentas:
- espaço curto de tempo para validação das funcionalidades e população das tabelas;
1
http://www.e-partner.com.br
2
http://www.constat.com.br
- falta de tempo da equipe de TI para validação devido a tarefas rotineiras;
- ilustravam um universo de possibilidades que no momento não se tinha como testar,
devido ao fato de não ter dados reais populados nas tabelas no espaço de tempo despendido para
validação;
- não possuía agilidade na implementação de melhorias como: alteração de telas; geração de
relatórios integrados e remodelação de processos de atendimento.
As ferramentas não atenderam a expectativa da área de TI pelos seguintes motivos:
a) não possuem interfaces simples com as quais os usuários possam interagir;
b) não estão nos padrões de layout exigido pela empresa;
c) não se adequam aos processos de atendimento da área de desenvolvimento e suporte;
d) não possibilitam à gerência do setor a emissão de relatórios para tomada de decisão.
Após apresentar o problema levanta-se o seguinte questionamento: como suprir a carência da
empresa de forma que se tenha um processo de atendimento a chamados, para desenvolvimento e
suporte, automatizados, beneficiando a área de TI, a empresa e seus usuários?
Diante deste questionamento, a proposta foi projetar e implantar uma solução denominada
Service Desk, que tem como objetivo: automatizar o processo de atendimento a incidentes dos
usuários; controlar as tarefas dos funcionários; criar um ponto único de controle; emitir relatórios
possibilitando melhorias do setor e da empresa; melhorar o grau de satisfação dos usuários e
disponibilizar subsídios para tomada de decisão gerencial.
Este artigo será apresentado, como descrito a seguir: Na seção 2 relata-se a situação
problemática identificada na empresa e o cenário atual da empresa. Na seção 3 será apresentado o
referencial teórico. Na seção 4, será apresentada a solução proposta. A seção 5 apresenta as
considerações finais referentes aos resultados obtidos junto ao projeto. Em seguida serão
apresentadas as referências bibliográficas utilizadas.
2
SITUAÇÃO PROBLEMÁTICA
A gerência do setor de TI da empresa não possui uma ferramenta para controlar as atividades
dos funcionários de desenvolvimento e suporte. Atualmente a abertura de chamados e o
atendimento dos mesmos são realizados via telefone, e-mail e acesso remoto.
A Figura 1 mostra a tela do correio eletrônico - outlook onde é realizado o acompanhamento
das tarefas de um dos funcionários da área de suporte. O funcionário executa seu controle
direcionando as mensagens para pastas particulares que estão subdivididas pelas unidades da
empresa, dando o atendimento quando possível. Este atendimento pode ser realizado: via VNC, in
loco, por e-mail ou telefone, sendo que muitas vezes o atendimento é direto pelo contato telefônico
ou in loco, e estes não ficam registrados.
Figura 1 – Tela do Correio Eletrônico
Os analistas e programadores realizam seu controle através de planilhas em Excel ou por email.
A Figura 2 mostra uma planilha elaborada no Excel para o controle individual de um analista
de desenvolvimento, sendo que nesta planilha o analista controla suas pendências, atividades diárias
e cobrança de testes.
Figura 2 – Tela do Correio Eletrônico
Como a abertura e o atendimento são realizados da forma descrita acima, atualmente, para se
obter informações sobre o atendimento realizado e a qualidade dos mesmos o gerente do setor de TI
tem que solicitar relatórios a sua equipe, que os elabora de forma manual, o que demanda tempo e
dedicação. O gerente de TI com base nestes relatórios realiza suas conclusões, sendo estes, alguns
dos principais pontos percebidos pelo gerente: os clientes possuem baixa confiança e pouca
percepção da TI e sentem a necessidade de dispor um ponto único para acompanhamento de seus
chamados.
Diante desta questão e tendo no contexto a incompatibilidade das ferramentas adquiridas
(Qualitor e ITS), ficou evidenciado que seria necessário o desenvolvimento de um sistema
proprietário, totalmente customizado aos processos de atendimento pela área de TI. Sendo assim,
este sistema de informação se tornará uma importante fonte de informações ao tomador de decisão
do setor de TI.
3
REFERENCIAL TEÓRICO
Para elaboração deste trabalho foram pesquisados os conceitos de: SI – Sistemas de
Informação, PU – Processo Unificado, UML – Unified Modeling Language, MER – Modelo
Entidade Relacionamento, DD – Dicionário de Dados e SLA – Service Level Agreement. Os
conceitos de ITIL – Information Technology Infrastucture Library e SLA – Service Level
Agreement serão apresentados abaixo buscando dar subsídios para o entendimento deste artigo.
3.1
ITIL - Information Technology Infrastucture Library
O ITIL é uma biblioteca composta por sete livros que apresentam uma visão consistente e
holística de serviços da Tecnologia da Informação, baseada em processos Ilumna (2004). É um
modelo de referência para gerenciamento de processos de TI. O conjunto de melhores práticas foi
desenvolvido no final dos anos 80 pelo Office of Governance Commerce (OGC) órgão do governo
inglês.
Segundo Academy (2003, p. 32), “... a ITIL descreve os contornos de como organizar o
Gerenciamento de Serviços. Os modelos mostram os objetivos, atividades gerais, entradas e saídas
dos vários processos, que podem ser incorporados nas organizações de TI. A ITIL não determina,
severamente, cada ação a ser executada no dia-a-dia porque existem algumas coisas que poderão ser
diferentes de uma organização para outra...”.
Para o desenvolvimento deste trabalho serão utilizadas as melhores práticas proposta nos
tópicos 5: Gestão de Incidentes e 6: Service Desk do livro Service Suport, pois, a empresa está
iniciando o trabalho de modelagem de seus processos conforme as melhores práticas propostas pelo
ITIL.
A empresa tomando como base um padrão a fim de seguí-lo e remodelá-la no que for
necessário para implementar o processo já tratado por outras empresas, torna seu processo de
implementação mais ágil, eficiente e o retorno após sua implantação será mais rápido, dependendo
apenas da população da base de dados com os registros e a implementação dos relatórios
necessários para tomada de decisão.
3.2
SLA - Service Level Agreement
Conforme Sturm, Morris e Jander (2001), um SLA – Acordo de Níveis de Serviço define
quais os níveis de serviço são considerados aceitáveis pelos usuários e podem ser fornecidos pelos
prestadores de serviço, atuando como proteção junto às expectativas. Existe uma característica
básica da natureza humana de querer sempre mais e melhor. Mais especificamente, um SLA bem
redigido definirá não apenas as expectativas, mas também um conjunto de indicadores aceitáveis e
mutuamente acordados de qualidade de serviços.
Para HILES, um SLA é um acordo entre o provedor de serviços e seus clientes, que
estabelece a qualidade mínima de serviço que a empresa necessita.
Tendo-se estabelecido um SLA, é necessário obter dados sobre a qualidade real ou nível de
serviço fornecido. Para isso, os gerentes precisam utilizar ferramentas para monitorar o desempenho
do serviço prestado. Essas ferramentas de monitoração compreendem software ou hardware, que
recuperam dados sobre o estado dos componentes básicos orientando o serviço. Esses dados são
armazenados em um banco de dados para referência futura ou são interpretados e introduzidos em
relatórios.
Segundo Academy (2003) se os departamentos de TI das organizações pretendem
demonstrar a área de negócios, um compromisso com a provisão de serviços orientados ao cliente, o
gerenciamento do nível de serviços é essencial.
Para a empresa os controles dos SLA’s serão definidos a fim de padronizar e identificar os
pontos fracos do atendimento, melhorando gradualmente a qualidade do serviço de TI, através de
monitoração e redefinição dos acordos, gerando relatórios, estimulando assim ações de erradicação
de serviços mal prestados. Em um primeiro momento os SLA’s serão internos, ou seja, do terceiro
tipo descrito, o setor de TI da empresa os definirá e conforme a necessidade podem ser alterados.
4
SOLUÇÃO PROPOSTA
Tendo em vista que as organizações estão cada vez mais voltadas para o fornecimento de
serviços de qualidade, e considerando o retorno obtido através da aplicação de normas e
procedimentos, a proposta deste trabalho foi projetar e implantar Gerenciamento de Serviços através
de um sistema de atendimento a incidentes de suporte e desenvolvimento denominado Service Desk
para o setor de TI da empresa, baseado nas melhores práticas propostas pelo ITIL. Abaixo será
descrita a forma como foi concebida a ferramenta.
Segundo Larman (2000) o desenvolvimento de uma aplicação necessita de uma descrição do
problema e dos seus requisitos. Para identificar o que o problema e o que o sistema precisa fazer,
deve-se realizar uma análise, a qual enfatiza uma investigação do problema e de como a solução
será definida. A metodologia de desenvolvimento abordada é o PU – Processo Unificado que está
subdividido em fases, sendo a fase de Concepção, Elaboração, Construção e Transição.
Através da análise realizada durante as fases de concepção e elaboração, quando realizado as
reuniões e levantamento de requisitos, foram identificados casos de uso, correlacionando-os e os
atores que farão parte deste projeto foi construído o diagrama de casos de uso. O diagrama pode ser
visto na Figura 3.
Figura 3 – Diagrama de Casos de Uso do Sistema
Caso de Uso:
Objetivo:
Atores:
Pré-Condições:
Ativação:
Fluxo de Eventos:
Abrir Incidente Desenvolvimento
Cadastrar incidente para desenvolvimento.
UserGuest, UserKey, Analista Interno, Analista Externo,
Programador Interno, Programador Externo, Analista de Suporte
Interno, Analista de Suporte Externo, Administrador e
Administrador de Analistas.
Estar logado no sistema, existir cadastro de tipo de incidente ativo.
O caso de uso inicia quando o usuário clica no botão denominado
“Abrir Incidente de Desenvolvimento”.
FLUXO NORMAL:
Fluxo Alternativo:
1. O sistema monta formulário de abertura do incidente;
2. São carregadas todas as possibilidades de tipo de incidente para
o ator logado conforme seu perfil;
3. O sistema envia mensagem para os analistas que possuem o
Sistema e Sub-Sistema relacionados a seu usuário.
FLUXO ALTERNATIVO: (UserGuest abre incidente)
1. O sistema envia mensagem para os UserKey que possuem o
Sistema e Sub-Sistema relacionados a seu usuário.
2. Um UserKey detalhará o incidente e marcará se procede ou não
o incidente, ou pode solicitar troca de informações com o
usuário.
3. O sistema envia mensagem para os analistas que possuem o
Sistema e Sub-Sistema relacionados a seu usuário.
Tabela 1 - Descrição do Caso de Uso Abrir Incidente Desenvolvimento
Caso de Uso:
Objetivo:
Atores:
Pré-Condições:
Ativação:
Fluxo de Eventos:
Emitir Relatórios
Ator emite relatórios do sistema.
UserGuest, UserKey, Analista Interno, Analista Externo,
Programador Interno, Programador Externo, Analista de Suporte
Interno, Analista de Suporte Externo, Administrador e
Administrador de Analistas.
Estar logado no sistema, incidentes cadastrados.
O caso de uso inicia quando o usuário clica no menu Relatórios e no
sub-menu com a opção desejada.
FLUXO NORMAL:
1. Opção lista usuários chave do sistema: exibe uma listagem em
html contendo duas colunas, uma coluna exibe quebra por
sistema e sub-sistema com os usuários que responde a outra
coluna exibe quebra por usuário e os sistemas e sub-sistemas
que responde;
2. Opção lista analistas do sistema: exibe uma listagem em html
contendo duas colunas, uma coluna exibe quebra por sistema e
sub-sistema com os analistas que responde a outra coluna exibe
quebra por analista e os sistemas e sub-sistemas que responde;
3. Opção interdependência de incidentes: quando usuário chave
logado, seleciona no combo uma das categorias que seu perfil
responde, é processado e são exibidos os analistas que atendem
para categoria selecionada e o administrador, e também exibe
todos os usuários chaves envolvidos na listagem dos incidentes
abertos. O programa busca todos os analistas que responde para
área selecionada e lista html com todos os incidentes abertos
para as áreas que estes analistas atendem conforme a ordem de
atendimento. Quando outro usuário logado que possua acesso:
deve selecionar o usuário chave e a categoria.
4. Opção lista incidentes por analista: exibe todos incidentes
relacionados com o analista selecionado no combo do período
escolhido, exceto com Status Cancelado e Fechado.
5. Opção lista incidentes: e contabiliza horas de programação e de
análise; exibe todos incidentes relacionados com o analista
selecionado no combo do período escolhido, com Status Em
Programação e Em Análise, exibindo subtotal de horas por
incidente, total geral de horas e total geral por status.
6. Opção administrador de analistas: exibe todos administradores
de analistas e os analistas de seu grupo.
Tabela 2 - Descrição do Caso de Uso Emitir Relatórios
Na fase de concepção também foram levantados os estados possíveis do sistema:
ABERTO: quando aberto por um usuário e está disponível para o analista atender.
PENDENTE DE KEYUSER: quando está disponível para o Usuário Chave dar procedência
ao incidente. Neste caso o usuário chave tem a responsabilidade de verificar se o incidente é
pertinente para ser desenvolvido. Status somente para o tipo desenvolvimento.
PENDENTE DE PREVISÃO: quando o analista está analisando o incidente para definir um
prazo de entrega para o mesmo. Status somente para o tipo desenvolvimento.
PENDENTE DE TERCEIRO: quando estiver pendente de uma tarefa e ser executada por
uma empresa terceira que presta serviços de informática para ThyssenKrupp Elevadores, este status
é específico para o suporte.
EM ANÁLISE: quando o analista está analisando o incidente.
PENDENTE DE INFORMAÇÃO: quando o analista solicita informações para o usuário que
abriu o incidente. Significa que o incidente depende desta informação para prosseguir com o
andamento.
TROCA DE INFORMAÇÃO: quando o usuário chave ou analista solicita troca de
informações com o usuário que abriu. Quando se deseja somente trocar informações com o usuário.
EM PROGRAMAÇÃO:
quando o analista encaminhar um incidente para fila de um
programador e o mesmo não tiver nenhum incidente para ser atendido no momento. Status somente
para o tipo desenvolvimento.
FILA DE PROGRAMAÇÃO: quando o analista encaminhar um incidente para fila de um
programador e o mesmo já estiver com outro incidente com status “EM PROGRAMAÇÃO”, então
entrará na fila do programador. Status somente para o tipo desenvolvimento.
EM VALIDAÇÃO: quando está disponível para o usuário que abriu o incidente testar as
alterações. Status somente para o tipo desenvolvimento.
FECHADO: quando o analista ou usuário chave fechar o incidente
CANCELADO: quando o analista, ou usuário chave, ou usuário que abriu o incidente
cancelar o incidente.
Na fase de Construção, seguindo a metodologia proposta, foi implementado e validado o
sistema proposto que será descrito a seguir.
O sistema desenvolvido está disponível para acesso através do Portal de Informações da
empresa, podendo ser acessado internamente ou externamente. Os usuários do sistema que possuem
login da rede da empresa utilizam o mesmo usuário e senha para acessar o sistema de fora da
empresa, através da extranet.
Após o usuário autenticar-se no sistema será exibida a tela principal do sistema conforme
Figura 4. No momento do login do usuário o sistema monta os perfis de acesso e conforme o perfil
logado exibirá ou não determinados menus do sistema, funcionalidades, campos em tela e
incidentes.
Se for um usuário com perfil:
UserGuest: exibirá somente seus incidentes, ou seja, somente os incidentes abertos pelo
usuário logado.
KeyUser: exibirá seus incidentes, e todos os incidentes com status “Pendente de KeyUser”
abertos para área que o KeyUser atende.
Analista: exibe os incidentes que foram abertos pelo usuário, os incidentes que está como
analista responsável, os que incidentes que está como apoio solicitado e os incidentes que estão
Abertos;
Programador: exibe os incidentes que foram abertos por este usuário, os incidentes para os
quais foi adicionado como programador, os incidentes que ele está como apoio e os incidentes que
estão Aberto para sua área;
Administrador: exibi todos os incidentes.
Figura 4 - Tela principal do sistema
A Figura 5 mostra o formulário para abertura de um incidente de desenvolvimento.
Figura 5 – Formulário
Quando o usuário detalhar um incidente será exibido um formulário com os dados do
mesmo, conforme Figura 6.
Quando o analista alterar o status do incidente para “Em Análise” deverá preencher o campo
“Previsão de Entrega”, esta data é a data final para entrega da solicitação incluindo o tempo de
validação pelo usuário, se este prazo não for cumprido ficará exibindo na tela principal de listagem
dos incidentes a “Data de Previsão” em vermelho.
Para cada andamento (parecer) realizado pelos analistas ou usuários do incidente fica
registrado com: data e hora de início, status, parecer, nome de quem registrou e data e hora final,
estes dados são importantes para o controle do tempo trabalhado em cada incidente e ainda dividilos por status.
Quando um incidente estiver com status “Pendente de Informação” e o usuário responder as
informações solicitadas, o incidente voltará para o status “Em Análise” e será gravada a data de
previsão em histórico e o analista deverá orçar uma nova previsão ao incidente.
Quando um incidente estiver com status “Em Validação”, o usuário poderá aprovar ou
reprovar o incidente, se aprovar o incidente será automaticamente fechado e o analista será
comunicado por e-mail informando que o programa pode ser colocado em produção no prazo de 24
horas, se caso for reprovado o incidente voltará para o status “Em Análise” e será gravada a data de
previsão em histórico e o analista deverá orçar uma nova previsão ao incidente.
Figura 6 – Tela de detalhe do incidente
Na fase de transição realizaram-se reuniões com os usuários e foi disponibilizado o sistema
para uso em produção. Hoje o sistema já está em pleno funcionamento na matriz e nas filiais da
empresa.
Esta ferramenta controla hoje todas as solicitações de chamados referentes a problemas de
tecnologia tratados pelo setor de TI, não é mais aceito pela empresa outra forma para atender os
usuários, pois todos os chamados devem ser devidamente registrados na central de atendimento
denominada Service Desk.
5
CONCLUSÃO
O desafio para o desenvolvimento deste sistema e talvez o principal eixo motivador foi a
oportunidade de estudar e utilizar as melhores práticas para gerenciar a infra-estrutura de TI através
do ITIL, desenvolvendo uma ferramenta capaz de monitorar os incidentes abertos por usuários para
o setor de TI.
Se não fosse realizado o desenvolvimento totalmente customizado ao processo de
atendimento a chamados da área de desenvolvimento e suporte, teríamos mais uma ferramenta
desenvolvida que poderia ser descontinuada na empresa, assim como o ITS e o Qualitor.
É importante para obtenção de um sistema bem planejado e bem elaborado adotar os
princípios de Engenharia de Software no seu desenvolvimento, através destes princípios a equipe
envolvida tem uma metodologia e padrões de desenvolvimento para seguir. Neste trabalho foi
importante a utilização do Processo Unificado para concepção do sistema, o PU dispõe de uma série
de regras para o desenvolvimento de um projeto bem sucedido e a geração de artefatos para sua
documentação.
Através da implantação do sistema na empresa, obtivemos os seguintes resultados: melhoria
na satisfação do usuário, ponto único de contato entre usuário e TI, controle padronizado das tarefas
dos funcionários de TI, dados disponíveis, redução de atendimento telefônico e histórico do
atendimento dos chamados. A empresa hoje dependente desta ferramenta para executar suas tarefas
diárias e tornou visível o trabalho de TI na empresa melhorando assim o nível de satisfação dos
usuários da área de TI.
REFERÊNCIAS
ACADEMY, Quint W. Redwood. Conceitos Básicos ITIL para Gerenciamento de Serviços em TI.
São Paulo: Quint, 2003.
HILES, A. N. Service level agreements: panacea or pain? The TQM Magazine, Bradford, v. 6, n. 2,
p. 14, 1994.
ILUMNA. Planejando a Implementação de ITSM. 2.ed. São Paulo: Ilumna, 2004.
LARMAN, Craig. Utilizando UML e Padrões. Uma Introdução à Análise e ao Projeto Orientado a
Objetos. Porto Alegre: Bookman, 2000.
STURM, R.; MORRIS, W. JANDER, M. Service level management: fundamentos do
gerenciamento dos níveis de serviço. Rio de Janeiro: Campus, 2001.