Através de conversas informais com o coordenador do setor de help desk da empresa Guia Fácil Comunicação, verificou-se a necessidade de desenvolver um novo sistema de informação para gerenciar os chamados técnicos efetuados pelos colaboradores ao help desk. Anteriormente, todas as solicitações eram realizadas através do envio de e-mails. Desta forma, manter controle de chamados pendentes, resolvê-los dentro do tempo máximo aceitável, respeitar prioridades, registrar as soluções encontradas, fornecer métricas, dentre outros itens
35
necessários para manter o atendimento em um nível de qualidade aceitável era uma tarefa difícil.
Através da troca de e-mails, não há um registro confiável de soluções que já foram encontradas em situações anteriores, nem uma forma eficiente de recuperá-las. Todo o esforço de pesquisa e expertise do técnico para resolver um problema fica perdido entre centenas de mensagens, ou muitas vezes, nem é armazenado. Uma das principais funcionalidades do sistema é a pesquisa de chamados técnicos semelhantes através da técnica de Raciocínio Baseado em Casos. Sempre que um novo chamado técnico for aberto, o técnico responsável pelo atendimento poderá consultar os casos mais semelhantes e aproveitar ou adaptar a solução já encontrada em um momento anterior. Todo o trabalho de pesquisa dos técnicos para encontrar soluções poderá ser reaproveitado, permitindo soluções dos chamados de forma mais rápida e eficiente, além de armazenar o conhecimento de forma padronizada, categorizada, conforme os manuais de processo ITIL Gerência de Problema, e priorizada, conforme o processo de Gerência de Incidentes. Para garantir maior padronização e agilizar ainda mais as pesquisas por casos similares encontrando automaticamente os parâmetros, o RBC será apoiado pelo algoritmo de classificação de documentos Naive Bayes.
Outra necessidade do help desk da empresa é um mecanismo de avaliação de satisfação dos colaboradores em relação ao serviço de atendimento prestado por cada técnico. Após o fechamento de cada chamado técnico, o colaborador que fez a abertura terá a oportunidade de avaliar o atendimento recebido. Esta avaliação se dá em forma de uma nota e comentários. Com estes dados, o coordenador do help desk terá métricas e relatórios disponíveis para tomar ações no sentido de corrigir e melhorar cada vez mais a qualidade do atendimento.
O sistema possibilita técnico e usuário trocarem mensagens através do sistema, mantendo o histórico destas interações de forma organizada, e sempre avisa por e-mail quando há qualquer mensagem nova. Além disso, os técnicos podem classificar todos os chamados em relação a sua prioridade, para desta forma, saberem exatamente qual deve ser sua próxima tarefa, sem a necessidade de vasculhar e-mails e alinhar seus trabalhos as necessidades, conforme o processo de Gerência de Incidentes.
No Quadro 4, apresentam-se os requisitos funcionais previstos para o sistema e sua rastreabilidade, ou seja, vinculação com os casos de uso correspondentes.
36
Quadro 4 – Requisitos Funcionais
Requisitos Funcionais Caso de Uso
RF01: O sistema deve permitir abrir chamados técnicos. UC01 RF02: O sistema deve permitir fechar chamados técnicos. UC02 RF03: O sistema deve permitir a consulta de chamados técnicos. UC03 RF04: O sistema deve permitir registrar interações (troca de mensagens) em
chamados técnicos.
UC04 RF05: O sistema deve permitir avaliar o atendimento de cada chamado técnico. UC05
RF06: O sistema deve permitir efetuar login. UC06
RF07: O sistema deve permitir manter os usuários do sistema. UC07 RF08: O sistema deve emitir relatório de usuários que mais abrem chamados
técnicos.
UC08 RF09: O sistema deve emitir relatório de quantidade de chamados técnicos
resolvidos e não resolvidos por técnico.
UC08 RF10: O sistema deve emitir relatório de tempo médio de solução para os
chamados técnicos.
UC08 RF11: O sistema deve emitir relatório de avaliações recebidas por técnico. UC08
RF12: O sistema deve permitir cadastrar soluções. UC02
RF13: O sistema deve permitir consultar casos semelhantes através da técnica de RBC, complementado por text mining.
UC10, UC02 RF14: O sistema deve enviar um e-mail ao técnico quando o usuário registrar
uma interação no chamado técnico e vice-versa.
UC04 RF15: O sistema deve permitir técnicos vincularem-se a chamados técnicos. UC11 RF16: O sistema deve enviar um e-mail ao coordenador quando houver
chamados abertos com mais de 24 horas sem interações registradas.
UC14 RF17: O sistema deve enviar um e-mail ao coordenador quando um
atendimento for avaliado com nota menor que 6,0.
UC13 RF18: O sistema deve permitir manter prioridades de chamados técnicos. UC15 RF19: O sistema deve permitir manter o dicionário de palavras similares. UC16 RF20: O sistema deve permitir ajustar os pesos dos atributos do RBC. UC17
RF21: O sistema deve permitir manter stopwords. UC18
RF22: O sistema deve permitir manter exceções de flexões de número. UC19 RF23: O sistema deve permitir manter tokens de classificação de documento. UC20
O Quadro 5 apresenta os requisitos não funcionais previstos para o sistema. Quadro 5 - Requisitos Não Funcionais
Requisitos Não Funcionais
RNF01: O sistema deve ser desenvolvido na linguagem Hypertext Preprocessor (PHP). RNF02: O sistema deve ser compatível com o sistema gerenciador de banco de dados (SGBD) MySQL.
RNF03: O sistema deve ser compatível com o servidor web Apache.
RNF04: O sistema deve possuir layout responsivo, compatível com tablets e smartphones. RNF05: O sistema deve utilizar o método do vizinho mais próximo normalizado para calcular a similaridade entre os casos.
RNF06: O sistema deve utilizar o algoritmo de Naive Bayes para classificar os chamados.
Na Figura 10, apresenta-se o diagrama de atividades para abertura de um chamado, até a pesquisa de casos similares e fechamento do caso. As fases do ciclo do RBC, conforme Figura 2, estão destacadas no diagrama pelas regiões tracejadas.
37
Figura 10 - Diagrama de atividades para abertura, pesquisa de casos similares e fechamento dos chamados
act 3 Diagrama de Ativ idades
Usuário Final Técnico Sistema
Início
Abrir chamado técnico Vincular-se ao chamado técnico Fim Informações do são suficientes? Registrar interação Responder interação
Definir v alores dos
atributos do RBC Salv ar atributos
Buscar casos mais similares Visualizar soluções dos
casos mais similares
Selecionar caso com solução mais adequada
Adaptar solução selecionada Salv ar solução Deseja pesquisar casos similares? Descrev er solução Recuperação Reuso Adaptação Retenção Não Sim Não Sim
O fluxo inicia com o usuário abrindo um chamado. Uma vez que o chamado esteja aberto, ele estará disponível a todos os técnicos na lista de chamados pendentes, quando um técnico deve vincular-se ao chamado. Neste momento o técnico verifica através do relato do usuário se possui informações suficientes para prosseguir com o atendimento. Se não houver informações suficientes, o técnico pode enviar uma mensagem ao usuário. O usuário responde à mensagem. Se neste momento houver informações suficientes, o técnico prossegue para a próxima atividade.
38
Neste momento, o técnico pode simplesmente descrever a solução que foi tomada e concluir o chamado caso se depare com um chamado simples, que não tenha necessidade de efetuar pesquisas no RBC.
Se o técnico optar por realizar a pesquisa no RBC, o próximo passo é identificar os atributos do RBC para o caso em questão, para permitir a realização da busca. Quando os atributos forem identificados, o sistema salva para pesquisas posteriores e aplica a técnica de recuperação de casos, exibindo ao usuário os dez casos mais similares encontrados. O técnico pode navegar pela solução dos casos mais similares até encontrar a mais adequada. Quando encontrar a solução correta, o sistema redireciona para o chamado em questão e permite que o técnico faça alguma adaptação na solução do caso recuperado para o novo caso, ou simplesmente salve a solução da mesma forma. Quando a solução for salva, o novo caso está concluído e retido na base do RBC, disponível para consultas posteriores.