SOLUÇÃO DE PROBLEMAS DE INFRAESTRUTURA DE
TI ATRAVÉS DE UM SISTEMA ESPECIALISTA
Murilo Luis Iung <[email protected]>
Christiano Cadoná <[email protected]> – Orientador
Universidade Luterana do Brasil (Ulbra) – Tecnólogo em Redes de Computadores – Campus Canoas
Av. Farroupilha 8001 – Bairro São José – CEP 92425-900 – Canoas - RS
22 de Junho de 2011
RESUMO
Este artigo descreve os passos para o desenvolvimento de um sistema de apoio à equipe de suporte para
solução de problemas relacionados à infraestrutura de TI, tomando como base de modelagem os sistemas inteligentes,
utilizando, dentre as variadas metodologias existentes, uma mescla de sistemas especialistas com o método de
raciocínio baseado em casos, para efetivar uma melhor gerência de aquisição e recuperação de ocorrências.
Demonstra também noções sobre conhecimento e sua gestão, o cenário atual relacionado a níveis do Help Desk e
sistemas baseados em casos, e os resultados analisados após o teste do sistema desenvolvido em um ambiente real.
Palavras-chave: Sistema especialista, raciocínio baseado em casos, Help Desk, gestão do conhecimento.
ABSTRACT
Title: “Solving IT infrastructure problems through a based case system”
This article describes the steps for developing a support system to support staff to solve problems related to
IT infrastructure, based on modeling of intelligent systems, using, among the various existing methodologies, a mix of
intelligent systems and case-based reasoning to effect a better management of acquisition and retrieval of known
cases. It also demonstrates notions about knowledge and its management, the current situation related to levels of
Help Desk and case-based systems and the results were analyzed after testing the system developed in a real
environment.
Key-words: Expert system, case based reasoning, Help Desk, knowledge management.
1
INTRODUÇÃO
Tempo para as empresas significa retorno dos mais variados tipos, e a perda de tempo implica
diretamente em perda desse retorno, seja ele financeiro, social, ou qualitativo. Para diminuir o tempo de suas
ações e agregar maior valor ao serviço ou produto oferecido, instituições dos mais variados cenários e
interesses buscam aprimorar suas habilidades tendo maior conhecimento no que se desempenha ou se
depende para alcançar seus objetivos, e para isso dependem de todos seus recursos em pleno funcionamento.
A utilização de sistemas especialistas e raciocínio baseado em casos auxilia diariamente em distintos
casos de solução de problemas ou detecção de diagnósticos, diminuindo o tempo de atendimento,
determinando com mais precisão as características do problema, encaminhando o usuário para uma solução
que resolva ou se adapte ao buscado.
As equipes de atendimento hoje oferecem recursos e times que se mantêm disponíveis em
determinados horários, e muitas delas permanecem 24 horas por dia prontas para atender, como por exemplo,
atendentes de telefonia móvel. O atendimento dessas geralmente segue registro de protocolo, o qual poderá
ser consultado posteriormente tanto para confirmação de ações desempenhadas, quanto para consulta de
soluções para casos parecidos através da leitura do relatório registrado.
Este artigo propõe uma solução para diminuir o tempo de busca pelo conhecimento necessário para
solucionar problemas de infraestrutura de TI, agregando valor ao atendimento da equipe de Help Desk e
aumentando o grau de satisfação do usuário final.
Na sessão 2 serão abordados tópicos importantes sobre características do conhecimento e sua gestão,
metodologia de raciocínio baseado em casos, sistemas especialistas, esse responsável pela consulta das
soluções buscadas, e a estrutura das equipes de Help Desk em geral.
Na sessão 3 será tratado sobre o planejamento e as características do sistema desenvolvido. Na
1
sessão 4 serão abordados os testes, resultados e depoimentos sobre o sistema. Na sessão 5 serão expostas as
conclusões sobre o projeto, e na sessão 6 serão mostrados trabalhos futuros.
2
REFERÊNCIAS IMPORTANTES
Nesta sessão serão abordados detalhes e características importantes sobre conhecimento e sua gestão,
raciocínio baseado em casos, sistemas especialistas, equipes de Help Desk, além de um levantamento de
sistemas destinados à área de suporte, com o intuito de contextualizar o leitor para melhor entendimento
deste artigo.
2.1
Conhecimento
Segundo Mastella (2004), conhecimento pode ser considerado o agrupamento ou ligação entre
informações, resultando em uma relação que obtém significado para o detentor; o resultado desse
relacionamento possibilita o conhecedor a reproduzir, aplicar ou gerar novas informações, sendo que o uso
das mesmas poderá ser destinado à resolução de problemas, um dos tópicos tratados neste artigo.
Informação, essa anteriormente citada, é resultado do nexo aplicado entre dados, fazendo com que o
mesmo tenha uma atribuição, relação ou significado associado a outro dado, que por si só, também tem o
mesmo tipo de ligação com o inicialmente citado.
Tais dados esses são palavras, registros, imagens, ou quaisquer outros tipos de saída bruta sem
coerência, definição ou associação. Sozinhos não apresentam sentido, pois por não terem tratamento ou
conexão alguma em sua forma original, não resultam em algo significativo.
Existem, de uma maneira geral, três níveis de conhecimento que são utilizados para compreensão de
certo assunto, e, ordenados crescentemente de acordo com a intensidade do mesmo, são eles o conhecimento
superficial, conhecimento do domínio, e conhecimento profundo.
Conhecimento superficial abrange informações de manuseio em casos específicos e particulares, não
adaptativos a outras situações; é o tipo de conhecimento geralmente utilizado para soluções imediatas, com
tratamento fixo e não mutável.
Conhecimento do domínio se refere ao que manuseia informações com um nível detalhado baixo,
porém suficiente para execução de tarefas e procedimentos, ou descrição de ações, itens e processos, sem a
capacidade de justificar o porquê do que está sendo exposto.
Conhecimento profundo pode ser claramente descrito como capaz de explicar a origem do que está
sendo descrito, pois tem embasamento teórico fundamentado, podendo utilizá-lo de forma análoga para
resolução de problemas semelhantes, com condicionamento necessário para avaliar se as informações
aplicadas podem ou não serem úteis para o caso a ser solucionado ou analisado para nova informação a ser
registrada.
Existem dois tipos de conhecimento estudados, o tácito e o explícito. O conhecimento tácito é aquele
que não pode ser mensurado ou exposto, tratando-se de experiências, ações, habilidades, ou todo tipo de
registro que é trabalhado no subconsciente do detentor, resumindo-se na parte prática do que é executado.
Ele possibilita, em grande parte dos casos, maior eficiência nas tarefas desempenhadas, pois permite ao
executor processamento de informações em segundo plano, sem ter de desviar o foco momentâneo para
refletir sobre o que fazer, pois já está claramente definida em sua memória a experiência do que deve ser
feito, ou como agir.
Já o conhecimento explícito se porta exatamente ao contrário, sendo ele de possível registro,
exposição, medição e reflexão, possibilitando sua captura e compartilhamento em linguagem formal e
compreensível. Ele pode ser identificado como a área teórica do conhecimento, pois dele poderão ser
estudadas suas informações registradas para criação de novos conhecimentos, reprodução do mesmo a outros
indivíduos, adaptação a outros cenários e melhoramento para aumento da eficácia do que se almeja alcançar.
Há duas formas gerais de aquisição de conhecimento que possibilitam a criação dos tipos de
conhecimento anteriormente citados; são elas a manual, e a baseada em tecnologia da informação (TI) - esta
dividida em automática e semiautomática.
Das técnicas manuais, podem-se citar como exemplos entrevistas, questionários, observações
2
focadas, relatórios verbais, análise de protocolos e brainstorm.
As técnicas baseadas em TI, subgrupo semiautomáticas, têm o homem como agente em relação com
a máquina para aquisição do conhecimento desejado, seguindo de exemplo sistemas desenvolvidos através
de uma metodologia bastante usual e funcional dentro da área de inteligência artificial (IA), o Raciocínio
Baseado em Casos (RBC); já o subgrupo automático tem o computador como executor da ação cognitiva em
si, como por exemplo, um sistema monitor inteligente que registra dados específicos de ativos em uma
infraestrutura e os analisa, informando automaticamente dados filtrados que serão absorvidos posteriormente
pelo homem.
2.2
Gestão do conhecimento
Segundo artigo publicado na Revista HSM Management (nº 42 janeiro-fevereiro 2004), gestão do
conhecimento significa “organizar e sistematizar, em todos os pontos de contato, a capacidade da empresa de
captar, gerar, criar, analisar, traduzir, transformar, modelar, armazenar, disseminar, implantar e gerenciar a
informação, tanto interna como externa”. Isso significa gerenciar o conhecimento do qual a empresa obteve
ao longo dos anos, utilizando as informações geradas por ela mesma.
Com esse gerenciamento, atuais empresas têm domínio sobre tópicos decisivos na qualidade de sua
estrutura, garantindo um caminho mais efetivo em direção ao sucesso ou vantagem sobre outras que não
aplicam conscientemente a prática; é evidente o fato de que não necessariamente o detentor de maior
conhecimento tem vantagem sobre os outros, pois quem sabe gerir melhor suas informações aplicadas obtém
resultados mais positivos na gestão da instituição.
Vantagens resultantes da prática formal de Gestão do Conhecimento podem ser identificadas
claramente nos seguintes itens:
1. Garantia de um melhor aproveitamento da experiência da empresa para formação de novos
membros ou treinamento da equipe existente;
2. Aplicação do conhecimento de maneira mais definida em situações sucintas, uma vez que o
mesmo já está dominado pela instituição;
3. Aprimoramento de processos conhecidos que já existem em documentação formal, possibilitando
melhor análise dos registros formais;
4. Facilidade na organização setorial, em casos onde os processos conhecidos estão claramente
definidos e documentados, tendo suas dependências e ações declaradas de maneira efetiva.
Para que todas essas tarefas e facilidades sejam possíveis, várias metodologias podem ser adotadas
para registro e manuseio das informações, e alguns exemplos de programas desenvolvidos pela área de TI
para Gestão do Conhecimento, no caso os Sistemas de Gestão do Conhecimento, são “BraZip mySuite”,
“Wintility” e “Lotus Notes”; fóruns, blogs, Wikis e webcast podem ser fortemente considerados como
mecanismos de disseminação de conhecimento na internet.
Em 24 de março de 2011, o jornal americano “New York Times” publicou uma matéria chamada “A
Better Way to Measure Twitter Influence” (A melhor maneira de medir a influência do Twitter), onde
informava que o maior influente do microblog “Twitter” é o comediante brasileiro “Rafinha Bastos”, que na
data de 15 de fevereiro de 2011 contava com 1.690.817 seguidores, e no dia 15 de Junho de 2011, o mesmo
registrou 2.330.455, mais de 600 mil novos seguidores em quatro meses.
2.3
Raciocínio Baseado em Casos
Para auxiliar no resultado eficaz do que é buscado em sistemas que efetuam consultas de
conhecimento, metodologias do mais variados tipos foram desenvolvidas, e algumas delas são métodos de
raciocínio. Os comumente usados são raciocínio baseado em regras, métodos e casos, e nesse artigo será
abordado o Raciocínio Baseado em Casos (RBC).
Começou a ser profundamente estudado em 1980, pelo professor Roger Schank, psicólogo e cientista
Robert Abelson, na Universidade de Yale, onde seus registros e conhecimentos deram possibilidades à Janet
Kolodner, em 1983, desenvolver o “Cyrus” - sistema que registrava as viagens e encontros do ex-secretário
do Estado Americano, Cyrus Vance, utilizando a teoria de MOP’s (Memory Organization Packets - Pacotes
de Organização de Memórias) desenvolvida por Schank.
3
Segundo Carvalho (2009), RBC é uma metodologia, dentro da área de Inteligência Artificial,
utilizada para reaproveitamento de soluções de casos já registrados em uma base de conhecimento, onde as
mesmas podem ser aplicadas e atribuídas diretamente ao novo caso, ou também serem adaptadas para gerar
novas respostas se não contemplarem uma resolução efetiva após sua consulta e reaproveitamento.
É amplamente aplicada na área de sistemas de Help Desk por agregar valor às ferramentas utilizadas
diariamente, pois os recursos baseados nessa metodologia encurtam o caminho da busca pela resposta
desejada quando existem questões a serem resolvidas. Para que o RBC possa funcionar adequadamente, o
mesmo precisa estar ligado diretamente a uma base de conhecimento fundamentada com qualidade, pois
mesmo que o mecanismo esteja desenvolvido de maneira eficaz, não será efetivo se a base de dados que
contém os casos não esteja alimentada de maneira satisfatória.
2.3.1
Ciclo de vida do RBC
A metodologia consiste em quatro processos principais em ciclo, possibilitando ao sistema que
utiliza RBC continuidade no crescimento de sua base de conhecimento, aprimorando e detalhando cada vez
mais os casos a serem resolvidos. Tais processos são a Recuperação de casos, Reutilização da solução,
Revisão da solução e Retenção do novo caso. Os mesmos são expostos na Figura 1, a seguir.
1. Recuperação
de casos
2. Reutilização
da solução
3. Revisão
da solução
4. Retenção do
novo caso
. Identificação de características
. Busca
. Identificação de compatibilidade
. Seleção
. Cópia
. Substituição
. Transformação
. Derivação
. Avaliação
. Reparação
. Integração
. Indexação
. Extração
Figura 1 – Ciclo de vida do RBC
A primeira etapa, Recuperação de casos, é descrita como a mais considerável, pois é nela que
acontece a busca pela solução que mais se adapta ao caso a ser resolvido. Isso é realizado através de
identificação de características, busca, identificação de compatibilidade e seleção. Além de ser responsável
pela pesquisa inicial na base de casos conhecidos pelo sistema, ela é quem dá início aos próximos processos,
dando continuidade ao ciclo de vida.
A segunda, Reutilização da solução, é responsável por reaproveitar as informações encontradas na
recuperação, adaptando-as para o novo caso, pois dificilmente são encontradas soluções recorrentes em casos
semelhantes, justamente pela mudança de detalhes entre eles, características essas que acabam influenciando
nas ações a serem tomadas. A reutilização poderá ser feita a partir de quatro passos comumente utilizados, e
são eles: cópia, substituição, transformação e derivação.
O terceiro processo, a Revisão da solução, conta com duas tarefas comumente conhecidas e
inconscientemente executadas em processos não declarados como RBC, que são a avaliação e reparação.
Elas são responsáveis por testes, validação, e quando forem necessárias, modificações da solução recuperada,
para haver certeza de que a aplicabilidade ao caso seja efetiva.
O quarto e último processo do ciclo, a Retenção do novo caso, consiste através de integração,
indexação e extração, em armazenar informações referentes à nova solução do caso a ser resolvido,
alimentando a base de conhecimento do sistema; pode-se identificar claramente que essa etapa é o momento
de aprendizagem, disponibilizando o novo caso para futuras consultas, e dando inicio novamente ao ciclo de
RBC para que próximas recuperações aconteçam, e assim por diante.
2.4
Sistema Especialista
Segundo Fernandes (2010 apud CARDOSO, RIBEIRO e SÁ), sistema especialista é aquele que tem
seu propósito voltado à emulação do papel de um especialista humano, desempenhando funções e tarefas que
dependem do conhecimento profundo do detentor de informações aplicadas.
A existência do especialista real para popular a base de casos conhecidos em tal sistema é de extrema
importância, porém a partir do momento em que a mesma se apresenta fundamentada, a condição de
4
consultar soluções para casos conhecidos no sistema poderá se tornar de múltipla instância, ou seja, o
conhecimento nele detido poderá ser consultado por mais de um usuário ao mesmo tempo, em locais
distintos, inclusive sobre assuntos distintos, enquanto o especialista humano poderá responder apenas uma
consulta a cada vez, pela comum limitação físico-humana de executar uma tarefa consciente por vez.
Segundo O’Brien, Luger e Fernandes (2003, 2004a e 2004b apud DA SILVA, DE SOUZA e SÁ),
outras vantagens apresentadas por um sistema especialista são velocidade na recuperação das respostas,
segurança de que o conhecimento já registrado não se extinguirá por esquecimento ou mudança de pessoal,
menor suscetibilidade à falha no que diz respeito à instabilidade na ordem de processos, possibilidade de ser
moldado com mais facilidade, e sempre constante disponibilidade.
Para garantir tais funcionalidades, o sistema deve ser estruturado com dois componentes básicos: uma
base de conhecimento organizada e fundamentada com informações relevantes, e métodos inteligentes de
manipulação do conhecimento adquirido, esses chamados de mecanismos de inferência.
Esse tipo de sistema está amplamente aplicado em diversas áreas, sendo algumas delas direito,
economia, educação, geologia, química, matemática, medicina e TI.
2.5
Help Desk
Segundo Da Silva (2007), uma equipe de Help Desk (HD) consiste em um time que presta serviços de
atendimento a um usuário, com o intuito final de resolver o incidente ou problema por ele informado logo no
primeiro atendimento. Inicialmente focavam em atender apenas a área de TI, porém hoje é utilizado para
outros segmentos, como telefonia, produtos eletrônicos e eletrodomésticos, pré-venda e pós-venda, entre
outros.
Analisando a estrutura de atendimento dentro de uma equipe de TI, pode se ter mais de um nível de
atendimento do HD, estrutura essa que garante com que alguns problemas a serem solucionados possam ser
escalados diretamente para a equipe competente, evitando desperdício no tempo de resolução; em geral, são
divididos em três níveis, porém existem instituições que podem apresentar apenas o primeiro deles, ou mais
de três, dependendo do porte e da complexidade das equipes.
2.5.1
Níveis de atendimento
O Nível 1 (N1) conta com uma equipe que recebe o primeiro contato e, identificando a área do
problema a ser resolvido, o atendente se destina a resolver o problema diretamente na mesma ligação caso
seja conhecedor da área, encaminha para outro membro da equipe que detenha o conhecimento necessário
para resolver o caso, ou escala para o próximo nível de atendimento, quando a complexidade ou tipo de
atendimento for divergente do oferecido e possível.
O Nível 2 (N2) pode ser identificado, dependendo da instituição ou estrutura do HD, como a equipe de
especialistas que detém conhecimento ou ferramenta adequada para solucionar o caso de maior
complexidade, ou a equipe de atendimento local, quando o que deve ser resolvido apresenta um problema
físico ou as tarefas a serem executadas não são de capacidade do usuário leigo, como por exemplo um
equipamento queimado que deverá receber outra peça, ou uma reconfiguração do sistema que não está
acessível remotamente.
O Nível 3 (N3) tem como participantes outros dois tipos de grupos, que são membros da equipe que
dispõem de conhecimento mais avançado que do N2, onde os atendimentos de alto nível de complexidade
geralmente são resolvidos, ou equipes de terceiros, como fabricante de algum equipamento em específico ou
equipes que atendem problemas que não são de possível treinamento de pessoal interno, como casos onde o
fabricante não abre as informações para o usuário final.
Na Figura 2 é exposto o fluxo dos níveis de atendimento da equipe de HD geralmente aplicado nas
empresas, onde o atendimento inicia no N1, e é analisado como sendo de domínio conhecido ou não; se sim,
efetua o atendimento. Caso não seja, este é encaminhado para o próximo nível, que novamente efetua a
análise e define se efetua o atendimento ou avança para o próximo nível. Esse processo se repete quantos
níveis existirem, enquanto o problema não for resolvido.
5
Figura 2 – Fluxo dos níveis da equipe de Help Desk
A importância de dividir os atendimentos em níveis é de evitar casos como, por exemplo, um técnico
de atendimento N1 se deter a atender um chamado de complexidade alta que ele detém o conhecimento
necessário, porém não está designado a resolver tarefas que podem demorar horas em atendimento,
acumulando solicitações de nível mais baixo que poderiam ser resolvidas em poucos minutos ou
devidamente encaminhadas.
2.5.2
Tempo de resposta e priorização
Tempo de resposta e priorização de chamados dentro do HD são pontos importantes a serem
gerenciados, a partir do momento em que existem variados problemas com prioridades diferentes.
A entrada de um chamado urgente dentro da equipe de atendimento poderá acarretar em transferência
do mesmo para o início da fila de atendimento, mesmo que haja outros chamados já abertos para serem
solucionados. Existem casos em que um chamado deverá ter resposta mais rápida que outros já existentes,
em virtude da existência de falhas que prejudicam o valor do negócio afetado pelo problema, podendo gerar
perda de dinheiro, danos permanentes a equipamentos, demissões e perda de causas judiciais.
2.5.3
Qualidade de serviço
O aprimoramento dos atendimentos prestados pelos times de HD é uma métrica importante e constante
a ser buscada pelos coordenadores dessas equipes, devido aumento do uso do computador para praticamente
todos os serviços e por grande parte dos setores de uma instituição. Pode-se verificar que com o aumento do
uso da ferramenta, a quantidade de serviços que param quando existe uma falha é maior do que a de
antigamente, fazendo-se necessário constante aprimoramento e maior eficácia da equipe de suporte.
Para que um HD tenha o desempenho desejado pelos usuários, que é solução de seu caso no primeiro
contato, a equipe deve contar com uma base de conhecimento muito bem fundamentada, e nem sempre isso é
possível de se manter em todos os colaboradores envolvidos no setor de atendimento; para isso, o uso de
ferramentas de sistema de gestão do conhecimento é de extrema importância, pois metodologias
automatizadas auxiliam de maneira direta na busca pela eficácia desejada.
2.6
Sistemas existentes
Uma análise foi efetuada em uma série de softwares de Help Desk disponíveis para as empresas de
HD aplicarem em seus ambientes de atendimento ao usuário, e as principais funcionalidades que envolvem a
consulta do conhecimento foram analisadas no que diz respeito à busca de casos conhecidos.
6
O Quadro 1 apresenta características dos softwares analisados.
Quadro 1 – Funcionalidades dos sistemas de HD
Consulta de Automatização Relatório Ambiente
documentos de etapas
de acesso
GLPI
X
Web
iSupport
X
X
App
Kayard
X
App
Liberium Help Desk
X
Web
OcoMon
X
Web
OneOrZero
X
X
Web
OpenIT
X
Web
Redmine
Web
Sinergia
Web
Site-Desk
X
Web
SupportWorks
X
App
Sistema
Licença
Gratuito
Pago
Pago
Gratuito
Gratuito
Pago
Gratuito
Gratuito
Gratuito
Gratuito
Pago
Nota-se que praticamente todos os sistemas dispõem de documentos para consulta, como por exemplo,
tutorial, vídeo-aula, entre outros, matéria esse disponibilizado aos usuários da aplicação, a fim de auxiliar na
solução do problema proposto. Apenas dois sistemas apresentaram relatório de acessos para verificar qual
documento tem sido lido com mais frequência, porém nenhum sistema hoje disponibiliza uma metodologia
de automatização de etapas, desmembrando o problema em uma sequência de ações, vinculadas a uma opção
que possa ser escolhida pelo usuário, funcionalidade essa que facilita a execução de testes para absorção do
conhecimento buscado.
Nesse caso, pode-se entender por automatização de etapas uma metodologia onde cada procedimento
leva para outro seguinte, porém dependendo de como são conduzidas as respostas do usuário às perguntas
que são inseridas no programa, o sistema encaminha-o para uma ou outra próxima pergunta, tornando a
consulta dinâmica e evitando que a leitura de um documento massivo seja efetuada, como é padrão dos
outros sistemas pesquisados.
Devida ausência desse tipo de metodologia (automatização de etapas), surgiu-se a motivação de se
desenvolver um sistema com tal característica, com o intuito de medir sua aceitação e resultados dentro de
uma empresa real, aplicando o software em paralelo ao atendimento já existente.
3
SISTEMA RDS
O sistema RDS (Recomendação de Soluções) é um sistema especialista utilizado pelo usuário na busca
por soluções através da automatização de etapas, dentro de um grafo com duas possíveis saídas, tendo o
intuito de auxiliar na resolução de problemas existentes em um cenário específico. Disponibiliza inserção de
problemas e manuseio completo dos mesmos, tendo estrutura suficiente para manter-se em constante
crescimento e aprimoramento. Em geral, o RDS disponibiliza conhecimento armazenado através de situações
reais, essas catalogadas por um especialista no domínio.
Foi projetado para ser aplicável em variadas áreas, pois não trabalha com o tratamento de informações
específicas, podendo receber registro de qualquer tipo de conhecimento que possibilite sua exposição em
forma de texto. Proporciona também aos seus usuários e especialistas plena gerência e aprendizagem sobre
tudo aquilo que nela foi registrado, pois permite propagação de conhecimento entre os possíveis níveis de
atendimento, o que melhora a gestão do conhecimento adquirido pela instituição durante seu período de
existência.
Para sua implementação, foi utilizando o conjunto de bibliotecas ASP clássico (Active Server Page),
combinado com banco de dados em Microsoft Access 2003, tendo seu ambiente de utilização através da
web, o que permite acesso em diversos tipos de dispositivos, garantindo maior versatilidade à ferramenta.
3.1
Principais funcionalidades
Para que a ferramenta possa cumprir com todos os requisitos das metodologias aqui levantados,
determinou-se que o sistema terá um ambiente de consulta acessado pelo usuário final, e outro utilizado pelo
especialista da área de conhecimento que receberá as informações aplicadas, tornando o sistema
7
independente, e eliminando a necessidade de injeção direta de dados em banco, ou programação estática de
informações nas sessões da aplicação. O acesso será distinguido por tela de login, para evitar uso indevido da
ferramenta.
Na Figura 3 é demonstrado o diagrama de caso de uso da aplicação, demonstrando as principais
funcionalidades do sistema RDS.
x
< e
d
ten
>
Armazenar problema não resolvido
Consultar questões
Usuário
Cadastrar novo caso
Validar novo caso
Gerar relatório
Especialista
Figura 3 – Diagrama de caso de uso do sistema RDS
No diagrama, o usuário desempenha o papel principal do sistema, possuindo como ação a consulta de
questões, que irá buscar perguntas e respostas, as quais lhe apoiarão na resolução de seus problemas,
recebendo instruções de como agir e o que analisar. No decorrer do encaminhamento das perguntas, poderá
ocorrer a não resolução do problema proposto, o que implica no armazenamento do incidente não resolvido,
que consiste na gravação da sequência que não retornou uma solução válida para o usuário.
O especialista tem como ação cadastrar os casos novos nas bibliotecas de problemas, validar novos
casos, onde ele gerencia e aprimora o conhecimento já existente gravado, gera relatórios para buscar os
problemas não resolvidos.
3.1.1
Modo usuário
Como já mencionado, o usuário possui o caso de uso “Consultar questões”, que tem início no
momento em que o mesmo clica na área de conhecimento onde procurará por orientações (conforme item 1
da Figura 4). Após selecioná-la, a aplicação listará todos os problemas já catalogados para a respectiva área,
onde o usuário escolherá o que deve ser resolvido (item 2 da Figura 4). Depois de definido o problema, a
aplicação inicia uma sequência de ações que devem ser executadas, com o intuito de resolver aquele que foi
selecionado. Para cada ação existirá duas saídas, onde uma indica uma próxima ação ou conclusão pelo
sucesso, e a outra, uma diferente ação ou conclusão sem sucesso.
A etapa de consulta e respostas às perguntas com solução encontrada pode ser identificada como a
“recuperação de casos”, etapa essa a primeira do processo do ciclo de vida do RBC, citado no tópico 2.3.1.
Cada consulta que o usuário efetua é gravada no sistema, registrando todos os problemas que foram
solucionados, e também os que não obtiveram sucesso na busca por uma resposta que se adequasse ao
atendimento solicitado. Em caso da busca não obter sucesso, o conjunto armazenado de etapas percorridas é
utilizado pelo especialista como base no processo de reutilização e revisão do ciclo de RBC, permitindo a
adaptação da solução.
8
Na Figura 4, é demonstrado o diagrama que exemplifica o modo de consulta do usuário, expondo
todas as possíveis opções que o consultante pode percorrer para resolver um caso. É possível identificar,
através do item 4 da Figura 4, que o usuário poderá executar uma repetição de procedimentos, pois até que
não seja encontrada uma resposta viável, o mesmo percorrerá por uma sequência de perguntas iniciadas no
item 3 da Figura 4, até que um aviso seja retornado. No item 5 da Figura 4, expõe-se o momento onde o
usuário identificará sua solução, ou a necessidade de adaptação do caso, aguardando, conforme o item 6 da
Figura 4, retorno do especialista com as novas respostas.
Figura 4 – Modo de consulta pelo usuário
Um exemplo da utilização do modo usuário é visualizado a seguir, quando ao entrar no módulo, a
interface apresentada disponibiliza ao consultor a escolha da área de conhecimento que necessita pesquisar
problemas. Na Figura 5 é identificada através do exemplo do item 1 a lista de áreas. Já o item 2 da Figura 5
apresenta um conjunto de possíveis problemas relacionados à opção selecionada na área. Neste caso, o
usuário selecionou a opção Hardware, e são apresentados os problemas relacionados à ela.
9
Figura 5 – Tela da lista de problemas relacionados ao Hardware
Ao clicar no problema “Mouse não funciona” (listado no item 2 da Figura 5), o consultante é
direcionado para a primeira pergunta registrada na base de conhecimento, conforme apresenta o exemplo na
Figura 6. Esta interface é dividida em 3 partes, sendo que a primeira apresenta o problema original (item 1 da
Figura 6). O item 2 da Figura 6 descreve uma ação ou pergunta relacionada, e o terceiro item apresenta as
opções de escolha relacionadas à pergunta.
Figura 6 – Tela da primeira pergunta do caso “Mouse não funciona”
A partir do momento em que o usuário entra no problema para buscar sua solução, as respostas “Sim”
e “Não” são responsáveis pelo dinamismo do sistema, conduzindo o usuário a navegar pelo grafo estruturado
pelo especialista.
Na Figura 7 é possível identificar a estrutura do caso exemplo definido pelo especialista e utilizado
pelo sistema para mostrar a sequência de ações a serem realizadas pelo usuário. Como pode ser constatada, a
sequência de ações e respostas de sim ou não para o problema “Mouse não funciona” implica em encaminhar
o usuário dentro da estrutura.
Figura 7 – Grafo completo do problema “Mouse não funciona”.
Ainda no exemplo de modo usuário, pode-se analisar que no grafo exposto na Figura 7, o consultante
tem quatro possíveis procedimentos a serem executados, esses identificados pela cor amarela, e que não
10
obrigatoriamente percorrerá todos eles. Na Figura 8, tem-se a comparação entre um caso que foi
solucionado, e outro que não obteve sucesso (esse indicado pelo item 1 da Figura 8).
Figura 8 – Comparação entre caso solucionado e não solucionado
3.1.2
Modo especialista
Como já citado no título 3.1, o especialista possui como principais ações o cadastramento de novos
casos, a validação de novos casos, e a tiragem de relatório.
Através do caso de uso “Cadastrar novo caso”, é possível que ocorra o carregamento de um novo
problema, oriundo da experiência de um especialista. Neste, o mesmo poderá definir uma nova área ou
selecionar uma existente, além de cadastrar a sequência de ações e reações necessárias para transformar um
problema em uma série de etapas automatizadas.
No caso de uso “Validar novo caso”, o especialista seleciona um problema que não obteve solução e
visualiza a sequência de etapas executadas sem êxito. O mesmo fará análise e poderá interagir criando novos
encaminhamentos ao problema não resolvido, ou editando os existentes. Neste momento, identificam-se as
etapas de reutilização e revisão da solução, para validar o caso de uso como novo conhecimento.
Para validar novos casos, ou seja, os que necessitam de adaptação, o mesmo buscará através de um
relatório todos os casos que foram consultados e não obtiveram solução (ação referenciada no item 1 da
Figura 10), inserindo novas respostas às perguntas que foram filtradas pelo sistema, processo esse
representado pelas etapas 2 e 3 do ciclo de vida do RBC. Para que isso se efetive, poderá acrescentar novas
perguntas à sequência existente, editá-las ou excluí-las, sendo possível também alterar os problemas e as
áreas de conhecimento, tarefas essas que indicam a etapa final do ciclo de RBC exposto anteriormente na
Figura 1, a “retenção do novo caso”.
Para finalizar as validações de casos, conforme item 4 da Figura 9, o especialista executará a
simulação dos casos inseridos e adaptados, acessando a opção disponível no ambiente privilegiado, onde ele
terá condições de editar ou excluir cada etapa consultada, caso julgue necessário, ou apenas testar o caso por
completo.
Na opção de relatórios, o mesmo terá condições de gerar dados estatísticos sobre a reincidência de
consultas com mesma sequência pesquisada, além da pesquisa detalhada de cada caso, inclusive os não
solucionados, conforme já anteriormente citado.
Na Figura 9, é exposto o diagrama da adaptação de um caso não solucionado, onde no item 1 o
especialista filtra os casos que necessitam de adaptação, passando para o item 2 da Figura 9, esse responsável
pelo início do ciclo até que todas as ações necessárias sejam executadas, saindo do laço somente quando não
11
existir uma ação pendente, conforme item 3. Nesse caso, ação pendente significa uma ação ou pergunta a
serem executadas. Após o término do processo de adaptação, o especialista retorna para o usuário no item 5 a
existência de novas questões a serem respondidas.
Figura 9 – Modo de adaptação de caso
Dentre as opções disponíveis ao especialista, a opção de cadastro “Perguntas” conta com os recursos
necessários para criação de perguntas intermediárias – essas as seguintes à pergunta inicial - dentro de um
problema, revisão das perguntas incompletas – as que ainda não foram ligadas a outras perguntas, e as
questões que uma das alternativas resulta em caso não solucionado.
No item identificado como 1 na Figura 10, mostram-se todos os recursos disponíveis para o
especialista, e no corpo principal da página, a opção que gerencia a criação das perguntas depois de clicada
na opção “Perguntas”, disponível no item 1, mostrando a opção de cadastro de perguntas intermediárias
(item 2), edição de perguntas incompletas (item 3) e de perguntas onde uma das alternativas retorna a
resposta “Problema não solucionado” (item 4), auxiliando o especialista a controlar quantos casos existem
com opções sem solução, e a encontrar a pergunta que receberá novas interligações para adaptação de caso.
Figura 10 – Tela da sessão “Cadastro de perguntas”
12
Na opção de simulação, o especialista tem exatamente o mesmo caminho que o usuário tem
disponível, porém durante a consulta, ele conta também com a opção de edição e exclusão em cada tela da
navegação, podendo alterar o texto da pergunta, sem desviar do foco do teste, evitando distração ou perda de
tempo procurando a pergunta específica posteriormente.
A opção de relatório apresenta em uma tabela quais foram os passos que o usuário executou em ordem
de consulta, possibilitando ao especialista analisar o caso não solucionado, por exemplo, para buscar novos
processos a serem executados, até que o problema seja resolvido. A Figura 11 apresenta uma tabela que
contém as ações e perguntas executadas pelo usuário em uma consulta armazenada que apresentou caso não
solucionado, conforme item 1.
Figura 11 – Tela do relatório de uma consulta com problema não solucionado
3.2
Repositório de armazenamento
A estrutura do banco de dados foi dividida em seis tabelas, sendo três para a base de casos conhecidos,
e três destinadas à consulta de dados para formulação de relatórios.
A Figura 12 mostra o modelo lógico das tabelas do sistema, onde o item 1 referencia as tabelas
relacionadas à base de conhecimento e suas respectivas cardinalidades, e no item 2 é possível se observar as
tabelas auxiliares utilizadas para gravação dos registros de sessão das consultas.
13
Figura 12 – Modelo lógico do banco da ferramenta RDS
As tabelas da base de conhecimento são divididas entre “areas”, “problemas” e “perguntas”.
Na tabela “areas” são armazenadas as áreas relacionadas a um problema. Na tabela problemas é
armazenada a descrição do problema. Já na tabela perguntas, são armazenadas as ações e perguntas, e as
referências para outras perguntas.
Pode-se observar através das cardinalidades mostradas no item 1 da Figura 13, que uma área pode ter
nenhum ou inúmeros problemas cadastrados, e esses essencialmente terão no mínimo uma ou mais perguntas
registradas, sendo que cada uma delas será ligada a apenas um problema, e eles pertencerão a apenas uma
área de conhecimento.
A Figura 14 mostra de maneira mais clara a estrutura das tabelas envolvidas na base de conhecimento
e seus relacionamentos, onde se identifica a tabela “area" no item 1, “problemas” no item 2, e “perguntas” no
item 3.
Figura 15 – Banco de dados alimentado com casos conhecidos
Já as tabelas que são utilizadas para os relatórios são divididas entre “sessoes1”, “sessoes2” e
“sessoes3”.
Todas as consultas efetuadas são registradas nas tabelas “sessoes1” e “sessoes3”, gravando
informações importantes como um número automático de registro para ordenação dos passos registrados,
número de sessão da consulta, problema, usuário que efetuou a consulta, qual pergunta acessada, a origem
que levou o sistema até a pergunta e a data de logon.
14
A tabela “sessoes3” é utilizada apenas para registros temporários, pois no momento em que o
especialista utiliza o recurso de relatórios em seu ambiente, um script é executado para analisar os dados da
mesma e armazenar na “sessoes2” o problema consultado e a sequência de perguntas percorrida, apagando
posteriormente todo seu conteúdo. Isso dá condições ao especialista de rodar o relatório de estatística citado
no tópico 3.1.2 desse artigo.
4
VALIDAÇÃO DA FERRAMENTA
A fim de obter indicadores positivos e negativos do uso da ferramenta desenvolvida, foi elaborado um
plano para validá-la. Foi escolhida uma empresa real que possuía equipe de HD e especialistas de domínio,
que serviram como elementos de testes das funcionalidades propostas. Inicialmente foi executada uma
análise da estrutura geral da instituição, efetuados todos os levantamentos necessários para os devidos
treinamentos, e o sistema foi posto em produção com recursos e pessoal próprios da empresa.
No levantamento realizado, identificou-se uma relação entre os níveis de atendimento apresentados no
capítulo 2.5.1 desse artigo. Também foi constatado que a ferramenta atendia melhor o N1 dos HD, pelo fato
da pouca experiência dos membros.
A equipe do N1 conta com atendentes que têm perfil de solucionador e direcionador – perfil esse
responsável por encaminhar o chamado para o especialista condizente com o problema a ser resolvido.
Segundo interesse da coordenação da equipe, o perfil que mais se adéqua ao uso do sistema é o de
solucionador, pois a demanda de encaminhamentos dos direcionadores não possibilita atendimento para
solução de problemas por serem o filtro dos chamados. Foram selecionados três atendentes que têm em
média 21 anos, sendo que um deles tem 1 ano de empresa com pouquíssima experiência, o outro tem 3 anos
com experiência média, e terceiro tem 4 anos, com o mesmo nível do anterior.
4.1
Características dos problemas locais
Existe uma semelhança entre a equipe de HD avaliada e a metodologia utilizada pela ferramenta. Isso
se deve pelo fato de ambos executarem consultas para obter especialização ou realizar buscas de soluções
para casos mais comuns e absorção de conhecimento. Para efetivar tais ações, no ambiente de teste a equipe
de N1 recebe do N2 uma série de testes que devem ser feitos e perguntas que devem ser respondidas,
induzindo o usuário até à solução, exatamente a mesma sistemática utilizada na ferramenta.
A grande dificuldade enfrentada pela equipe N1 do HD ao consultar outros níveis de atendimento é a
disponibilidade dos especialistas; isso agregou mais uma característica que valida a implementação do
sistema para teste no ambiente de atendimento, onde grande parte dos profissionais de nível superior se
encontra indisponível. Tal indisponibilidade se caracterizada pela ocupação dos especialistas já em tarefas
programadas, e também por alguns detentores do conhecimento necessário não fazerem mais parte da equipe
de suporte.
Em virtude da indisponibilidade de especialização durante os atendimentos e a pouca experiência da
maioria dos membros atuais do HD, existem falhas em relação ao encaminhamento dos chamados pelo
direcionador. Isso se dá devido pouco conhecimento do técnico, que acaba não efetivando o escalonamento e
a ordem dos atendimentos mais importantes corretamente.
Por conta dessa pouca experiência, também surge uma característica negativa em relação aos
encaminhamentos e atendimentos, que é a demora na identificação do problema, aumentando o tempo de
solução ou resposta do chamado que o usuário abriu, causando insatisfação do cliente que está aguardando
uma solução para o seu incidente.
4.2
Sistema local
Para sanar o problema de comunicação e experiência dos atendentes N1, o sistema atual (GLPI Gestionnaire libre de parc informatique, que em francês significa “Gestor gratuito do parque de
informática”) conta apenas com o acesso à base de conhecimento com documentos inseridos por meio de
upload, disponibilizando arquivos com orientações estáticas, conforme levantamento demonstrado no
Quadro 1; isso faz com que a leitura e busca pela solução durante o atendimento seja mais demorada e
massiva, por existir a necessidade de leitura do manual completo antes de aplicá-lo, para conhecer todas as
possibilidades e saltos entre processos caso haja necessidade de pular determinados passos.
15
4.3
Metodologia aplicada
Ao discutir sobre as dependências, falhas e possíveis correções detectadas pela análise da estrutura da
equipe, a coordenação do time de HD demonstrou abertura total para utilização e personalização da base de
casos conhecidos que foi injetada no sistema, confirmando que em primeiro momento a ferramenta pode
auxiliar de fato nos atendimentos prestados pelo N1.
Para hospedagem da ferramenta, foi disponibilizado um computador para trabalhar como servidor do
sistema, com as seguintes configurações de componentes e sistema, que atendem às necessidades mínimas:
• Processador Intel® Core™ 2 Duo PC E4600 @ 2.40GHz 2,40GHz
• Memória instalada: 2,00 GB DDR2
• Sistema operacional: Windows 7 Professional 32 bits Service Pack 1
• Ferramenta instalada: Microsoft Office 2010
Os usuários que foram destinados à utilização do sistema RDS receberam treinamento no seu ambiente
de trabalho, onde exemplos de consulta foram executados para fixação da ferramenta proposta.
O especialista que foi designado a inserir os casos conhecidos no sistema recebeu instruções em todos
os procedimentos disponíveis no respectivo modo, exemplificando todas as possíveis ações com situações
práticas. Recebeu também orientações sobre mapeamento de processos, para que o mesmo tivesse maiores
condições de identificar cada tarefa envolvida em cada solução de problema, e obtivesse noção e condições
de gravar todas as informações necessárias para formação de conhecimento disponível no RDS.
Para medir a eficácia do sistema aplicado na instituição, alguns quesitos importantes foram coletados
através de relatórios e entrevistas, e analisados, para determinar marcadores que dessem condições de gerar
resultados mensuráveis e explícitos.
• Quantidade de chamados fechados e encaminhados pelos técnicos que utilizaram a ferramenta
• Tempo de resolução de problemas repetidos antes e depois da aplicação do recurso
• Potencial de aprendizagem do conhecimento nele embutido
• Aceitação dos técnicos ao uso do sistema
• Validade da ferramenta no tipo de ambiente empregado
• Possíveis mudanças no método de consulta
• Alterações na interface
• Sugestões sobre a estrutura geral do sistema
4.4
Estatísticas
O sistema foi posto em produção contendo cadastradas as áreas de e-mail, Hardware, redes, Software
e telefonia, e quinze problemas associados à elas. Durante o período de testes do dia 10 ao dia 16 de junho de
2011, apenas dois casos foram adaptados e um foi inserido como novo caso, expondo que mesmo em um
período curto de uso, a inserção e adaptação de casos ocorreram com sucesso.
No período do mês de Maio de 2011, a quantidade de chamados que foram atendidas pelos três
técnicos atendentes foi de 570 chamados, sendo que 109 foram encaminhados para outros níveis,
representando 19% de chamados não solucionados. No período de teste, 220 chamados foram abertos, e
apenas 18 chamados foram encaminhados, totalizando 8%. A Figura 17 apresenta um gráfico comparativo
entre o percentual dos atendimentos.
16
Figura 17 – Gráfico “Atendidos x Encaminhados” em percentual
O aspecto “tempo de atendimento” é um ponto importante quando se caracteriza como “rápido”, pois
como já abordado anteriormente, desperdício de tempo significa desperdício de recursos e retornos que a
empresa tem; com isso, o tempo de atendimento também foi analisado, sendo que a média obteve diminuição
desde o início do atendimento até a solução do problema.
Pode-se verificar que o tempo médio de atendimento remoto por chamado em Maio foi de 27 minutos,
e os atendimentos locais demoraram em torno de 49 minutos, contra 19 minutos e 42 no período de teste, em
Junho. As métricas registradas podem ser verificadas no gráfico da Figura 18.
Figura 18 – Gráfico do tempo médio de atendimentos em minutos
4.5
Análises e depoimentos
Com a utilização do sistema desenvolvido, pôde-se evidenciar a aprendizagem com a consulta de
casos conhecidos, pois segundo técnicos que utilizaram a ferramenta, certos problemas antes não conhecidos
pelos mesmos se repetiram após a primeira consulta à base de casos, fazendo com que nos atendimentos
seguintes tivessem condições de atender o chamado sem a necessidade da busca; isso confirmou um
treinamento paralelo do usuário do RDS e o compartilhamento do conhecimento entre níveis.
Essa característica também diminui a necessidade de mobilizar equipes ou times separados em salas
especiais de treinamento de pessoal, diminuindo o quadro atendente ou mobilizando o mesmo em horários
diferentes do expediente, evitando também o deslocamento de um agente especialista para prestar o
treinamento aos técnicos, economizando em material impresso ou digital, possível hora extra devido turno
diferenciado, dedicação do especialista em repetir a mesma tarefa para mais de uma turma, ou seja,
economizando no geral os recursos da instituição para tal finalidade.
Pôde-se também, através das entrevistas, coletar depoimentos que confirmaram a aceitação do sistema
como ferramenta diária de consulta, pois pelo fato da mesma agregar valor ao conhecimento individual, ela
se torna útil tanto nos casos não conhecidos por eles, quanto em reincidências. Apontam também que pelo
fato da reincidência ser registrada, e o conhecimento estar disponível numa plataforma de acesso comum,
não há a necessidade de encaminhamento para especialistas, justamente pela solução estar disponível a todos
17
que têm acesso ao RDS.
Tal aceitação pode ser confirmada também pelo especialista que testou a ferramenta, pois citou sobre a
facilidade de aprendizagem pela ferramenta, e expôs satisfação sobre a facilidade de registro dos casos mais
variados da instituição, já que a ferramenta tem um perfil genérico de consulta por método de automatização
de etapas, sendo ela utilizável pelas demais áreas da empresa, e não somente pela TI.
Segundo o próprio especialista, a aplicação tem condições de ser disponibilizada também para o
usuário final que entra em contato com o HD, auxiliando nos atendimentos dos técnicos da equipe pelo fato
de dar independência e autonomia suficiente para que o funcionário resolva pequenos problemas como um
equipamento que não funciona pelo simples fato do estabilizador estar desligado, ou uma impressora que não
está imprimindo por estar com o reservatório de dejetos de toner cheio, podendo ser esvaziado pelo próprio
usuário.
Para os casos em que o usuário não encontrou possível solução, o especialista sugeriu que o sistema
RDS tivesse possibilidade de integração com o sistema de chamados atual da instituição. De uma maneira
geral, isso possibilitaria a ferramenta em abrir diretamente um chamado para a equipe de HD já com todos os
passos realizados pelo funcionário, evitando repetição de processos pelo técnico de campo ou atendente
remoto, tornando a busca pela solução mais objetiva e, novamente, diminuindo o tempo total de atendimento
do chamado para melhor satisfazer os objetivos da empresa e do empregado.
Não foram registradas respostas negativas no que se diz respeito à interface gráfica do sistema,
metodologia de recuperação dos casos conhecidos, nem houve sugestões sobre a estrutura geral da
ferramenta, pois todos declararam que a ela leve e sóbria possibilita maior foco no conteúdo das
informações, não desviando a atenção ou tornando-a visualmente estressante.
5
CONCLUSÃO
Com o uso de um sistema especialista mesclado com metodologia de raciocínio baseado em casos,
utilizando como mecanismo de consulta “automatização de etapas”, pôde-se constatar que os atendimentos
prestados por uma equipe de Help Desk agregaram valor tanto na pesquisa direta de casos conhecidos,
quanto no treinamento de pessoal com pouca experiência, pois através da consulta ao sistema RDS, os
procedimentos foram absorvidos pelo consultante automaticamente, gerando um conhecimento de domínio
maior no mesmo.
Através desse tipo de prática, concluiu-se também que o valor do serviço prestado pela equipe de
suporte foi diretamente aumentado, pois teve condições de diminuir o tempo de resposta para solução de
problemas conhecidos. Tal resultado melhorou a satisfação de alguns usuários finais da instituição, pois os
mesmos tiveram seus problemas resolvidos em menor tempo, e isso aumenta a confiabilidade na equipe de
TI que disponibiliza tal perspectiva no cliente.
Esse tipo de opinião registrada no usuário final possibilita maior aceitação do mesmo para a equipe de
TI sempre que a mesma propõe mudanças de sistema para melhoramento dos processos e fluxos, pois grande
dificuldade existente na TI, em relação às pessoas que utilizam o recurso e que não são da área de
informática, é a troca de ações diárias que as mesmas estão acostumadas a desempenhar.
Com isso, aumentam-se as chances do sistema tornar o usuário final mais independente quando a
resolução de um problema de baixa complexidade estiver proposta na base de conhecimento, pois caso o
mesmo se disponha a testar certos procedimentos simples, ele estará tendo chance de resolver problemas
locais com rapidez, evitando a espera da visita de um técnico de campo para solucionar casos como um
computador sem internet por causa do cabo de rede desconectado, ou uma impressora que não está
imprimindo apenas por estar sem toner.
6
PERSPECTIVAS
Como trabalhos futuros em relação à ferramenta RDS, pode ser implementada uma funcionalidade que
gera uma visualização gráfica para o modo usuário, onde é mostrado dinamicamente durante a consulta o
caminho que o usuário já percorreu dentro da sequência de perguntas em sua atual consulta, auxiliando o
mesmo a retomar passos para melhor apoiá-lo durante certos testes.
Poderá ser implementado um indicador da sequência de consultas mais utilizada ao lado de cada
18
problema na listagem da área, para que antes dele ser aberto para consulta, já ter o caminho que mais
auxiliou na solução do referente caso.
É possível também trocar a identificação da resposta no mecanismo de automatização de etapas,
substituindo a referência às próximas perguntas através das respostas fixas “sim” e “não” pela inserção de
dados personalizados, onde caso a questão seja “o e-mail é acessado via cliente ou ambiente web?”, as
respostas poderão ser “Cliente” e “Web”. Com isso, o especialista poderá diminuir a quantidade de testes
efetuados para objetivar mais a pesquisa.
Um mecanismo que pode auxiliar na detecção de consultas onde o caso não foi solucionado é o de
alerta ao especialista através de e-mail, tornando o sistema reativo à necessidade de adaptação de caso,
eliminando a necessidade do especialista procurar os casos não solucionados periodicamente.
REFERÊNCIAS
A gestão do conhecimento na prática. Revista HSM Management. 42, 2004. Disponível em:
http://www.paradigma.com.br/gestao-do-conhecimento-na-pratica/view. Acesso em: 10 ago. 2011.
BEPPLER, Fabiano Duarte. Emprego de RBC para recuperação inteligente de informações.
Florianópolis, 2002. 112 p.
CARDOSO, José Claudio; RIBEIRO, Vinicius Gadis; SILVEIRA, Sidnei Renato. SEGCCSC – Sistema
Especialista Para Gestão De Cobrança De Cheques Sem Compensação. Gravataí, 2010. 6 p.
CARVALHO, Eduardo Enrique Ostos. Raciocínio Baseado Em Casos: Uma Abordagem Utilizando o
Sistema Imune Artificial. Belo Horizonte, 2009. 198 p.
COHEN, Roberto. Gestão de Help Desk e Service Desk. Ed. Novatec, 2011. 296 p.
DA SILVA, Cassiana Fagundes; DE SOUZA, André Luiz B.; SILVA, Eddie Patrick; RODRIGUES, Jônatas
Vales. SECOLV – Sistema Especialista para Auxiliar no Diagnóstico de Enfermidades da Coluna
Vertebral. Macapá, 2007. 9 p.
DA SILVA, Jorge Moacir, Farias. Utilização do Raciocínio Baseado em Casos como Apoio a um Sistema
de Help Desk. Novo Hamburgo, 2007. 10 p.
Gestão
do
conhecimento.
Wikipédia,
a
enciclopédia
livre.
2011.
http://pt.wikipedia.org/wiki/Gestão_do_conhecimento. Acesso em: 09 jun. 2011.
Disponível
em
MASTELLA, Laura Silveira. Técnicas de Aquisição de Conhecimento para Sistemas Baseados em
Conhecimento. Porto Alegre, 2004. 39 p.
MATOS, Ivan Carlos. Utilização de Raciocínio baseado em casos na determinação de aparelhos
auditivos via web. São José, 2007. 82 p.
MELCHIORS, Cristina. Raciocínio Baseado em Casos Aplicado ao Gerenciamento de Falhas em Redes
de Computadores. Porto Alegre, 1999. 151 p.
PLOTEGHER, Silvio Luiz; FERNANDES, Marcio Merino. Raciocínio Baseado em Casos Aplicado a um
Sistema de Diagnóstico Remoto. Piracicaba, 2005. 14 p.
HEINZLE, Roberto; FEITEN, Wantoir; WEISSHEIMER, Érico. Protótipo de um Sistema Especialista
para Análise de Crédito de Pessoas Físicas. Palmas, 2003. 10 p.
19