1

SOLUÇÃO DE PROBLEMAS DE INFRAESTRUTURA DE TI ATRAVÉS DE UM SISTEMA ESPECIALISTA

Murilo Luis Iung <murilo.iung@gmail.com> Christiano Cadoná <cadona@ulbra.br> – 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

2

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

3

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.

4

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.

4.  Retenção  do          novo  caso.  Integração.  Indexação.  Extração

3.  Revisão          da  solução.  Avaliação.  Reparação

2.  Reutilização          da  solução.  Cópia.  Substituição.  Transformação.  Derivação

1.  Recuperação          de  casos.  Identificação  de  características.  Busca.  Identificação  de  compatibilidade.  Seleçã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

5

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.

6

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.

7

O Quadro 1 apresenta características dos softwares analisados. Quadro 1 – Funcionalidades dos sistemas de HD

Sistema Consulta de documentos

Automatização de etapas

Relatório de acesso

Ambiente Licença

GLPI X - - Web Gratuito iSupport X - X App Pago Kayard X - - App Pago Liberium Help Desk X - - Web Gratuito OcoMon X - - Web Gratuito OneOrZero X - X Web Pago OpenIT X - - Web Gratuito Redmine - - - Web Gratuito Sinergia - - - Web Gratuito Site-Desk X - - Web Gratuito SupportWorks X - - App 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

8

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.

Consultar  questões

Cadastrar  novo  caso

 Validar  novo  caso

Gerar  relatório

Usuário

Especialista

Armazenar  problema  não  resolvido

<  exten

d  >

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.

9

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.

10

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

11

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

12

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”

13

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.

14

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.

15

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.

16

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.

17

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

18

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

19

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. Disponível em http://pt.wikipedia.org/wiki/Gestão_do_conhecimento. Acesso em: 09 jun. 2011. 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.