SISTEMA SERVICE DESK

Transcrição

1 SISTEMA SERVICE DESK Taiana Rosales de Oliveira Anderson Ricardo Yanzer Cabral Universidade Luterana do Brasil (Ulbra) Curso de Sistemas de Informação Câmpus Guaíba BR 116 KM 299 N 5724, CEP 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 m² e área coberta de aproximadamente m². 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 ITS 1 em 2004/01 e o Qualitor 2 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;

2 - 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 acesso remoto. A Figura 1 mostra a tela do correio eletrônico - outlook onde é realizado o acompanhamento

3 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 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 e- mail. 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.

4 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

5 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

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

7 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: Abrir Incidente Desenvolvimento Objetivo: Cadastrar incidente para desenvolvimento. Atores: UserGuest, UserKey, Analista Interno, Analista Externo, Programador Interno, Programador Externo, Analista de Suporte Interno, Analista de Suporte Externo, Administrador e Administrador de Analistas. Pré-Condições: Estar logado no sistema, existir cadastro de tipo de incidente ativo. Ativação: O caso de uso inicia quando o usuário clica no botão denominado Abrir Incidente de Desenvolvimento. Fluxo de Eventos: FLUXO NORMAL:

8 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: Emitir Relatórios Objetivo: Ator emite relatórios do sistema. Atores: UserGuest, UserKey, Analista Interno, Analista Externo, Programador Interno, Programador Externo, Analista de Suporte Interno, Analista de Suporte Externo, Administrador e Administrador de Analistas. Pré-Condições: Estar logado no sistema, incidentes cadastrados. Ativação: O caso de uso inicia quando o usuário clica no menu Relatórios e no sub-menu com a opção desejada. Fluxo de Eventos: 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

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

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

11 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

12 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 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

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

14 REFERÊNCIAS ACADEMY, Quint W. Redwood. Conceitos Básicos ITIL para Gerenciamento de Serviços em TI. São Paulo: Quint, HILES, A. N. Service level agreements: panacea or pain? The TQM Magazine, Bradford, v. 6, n. 2, p. 14, ILUMNA. Planejando a Implementação de ITSM. 2.ed. São Paulo: Ilumna, LARMAN, Craig. Utilizando UML e Padrões. Uma Introdução à Análise e ao Projeto Orientado a Objetos. Porto Alegre: Bookman, STURM, R.; MORRIS, W. JANDER, M. Service level management: fundamentos do gerenciamento dos níveis de serviço. Rio de Janeiro: Campus, 2001.