UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL INSTITUTO DE INFORMÁTICA

CURSO DE ESPECIALIZAÇÃO EM DESENVOLVIMENTO, SEGURANÇA E QUALIDADE NA INTERNET.

JAINE JOSÉ DA SILVA

Help Desk com Sistema de RBC para as Gerências de Aplicativos do Banco do

Brasil

Trabalho de Conclusão de Curso apresentado como requisito parcial para a obtenção do grau de Especialista

Profa. Dra. Mara Abel Orientadora

Profa. Dra. Mara Abel Coordenadora do Curso

Porto Alegre, abril de 2004

CIP – CATALOGAÇÃO NA PUBLICAÇÃO

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL Reitora: Profa. Dra. Wrana Maria Panizzi Pró-Reitor de Ensino: Prof. Dr. José Carlos Ferraz Hennemann Pró-Reitora Adjunta de Pós-Graduação: Profa. Dra. Jocélia Grazia Diretor do Instituto de Informática: Prof. Dr. Philippe Olivier Alexandre Navaux Coordenadora do CEDSQI: Profa. Dra. Mara Abel Bibliotecária-Chefe do Instituto de Informática: Beatriz Regina Bastos Haro

Silva, Jaine José da

Help Desk com Sistema RBC para as Gerências de Aplicativos do Banco do Brasil / Jaine José da Silva – Porto Alegre: CEDQSI, 2004.

45 f.:il.

Trabalho de Conclusão (especialização) – Universidade Federal do Rio Grande do Sul. Curso de Especialização em Desenvolvimento, Segurança e Qualidade na Internet, Porto Alegre, BR – RS, 2004. Orientadora: Mara Abel.

1. Help Desk com sistema de RBC 2. RBC 3. Modelagem I. Abel, Mara. II. Título.

SUMÁRIO

LISTA DE FIGURAS......................................................................................................5

LISTA DE TABELAS.....................................................................................................6

RESUMO..........................................................................................................................7

ABSTRACT .....................................................................................................................8

1 INTRODUÇÃO ........................................................................................................9

1.1 As Gerências de Aplicativos do Banco do Brasil .................................................12

2 BC.................................................................................................................................13

2.1 Representação do Caso ..........................................................................................14 2.1.1 Memória ou Base de Dados .................................................................................14 2.1.2 Base de casos .......................................................................................................14

2.2 Indexação ................................................................................................................14

2.3 Recuperação............................................................................................................15 2.3.1 Similaridade.........................................................................................................15

2.3.2 Métrica da Similaridade.......................................................................................15

2.3.3 Recuperação.........................................................................................................16

2.3.4 Seleção /Combinação...........................................................................................16

2.4 Adaptação................................................................................................................16

2.5 Aprendizagem.........................................................................................................16

3 UMA PROPOSTA DE UM SISTEMA DE HELP DESK UTILIZANDO RBC PARA GERÊNCIA DE APLICATIVOS DO BB.......................................................17

3.1 Estrutura interna do sistema.................................................................................22 3.1.1 Fazendo a consulta...............................................................................................22

3.1.2 Registro de problemas .........................................................................................22

3.1.3 Recuperação de casos ..........................................................................................23

3.1.4 Atribuir responsável.............................................................................................24

3.1.5 Cadastro de soluções............................................................................................24

3.1.6 Relatórios básicos e consultas .............................................................................25

3.1.7 Monitoração do atendimento ...............................................................................25

3.2 Representação do Caso e Indexação no Sistema de Help Desk..........................25 3.2.1 Vocabulário e Dicionário de termos Técnicos.....................................................28

3.2.2 Analisador sintático .............................................................................................29

3.2.3 Extração automática da informação textual.........................................................30

3.3 Recuperação no Sistema de Help Desk.................................................................33 3.3.1 Extração por Seleção ...........................................................................................33

3.3.2 Pontuação.............................................................................................................34

3.4 Adaptação no Sistema de Help Desk ....................................................................34

3.5 Aprendizagem no Sistema de Help Desk..............................................................35

4 VALIDAÇÃO .........................................................................................................37

4.1 Aplicações................................................................................................................38

4.2 Híbridos...................................................................................................................40

4.3 Raciocínio baseado em regras vs. RBC ................................................................40

5 CONCLUSÕES ......................................................................................................42

5.1 Resumo das vantagens do RBC.............................................................................42

REFERÊNCIAS ............................................................................................................44

LISTA DE FIGURAS

Figura 1.1: Analogia - Tipos de Informações e seu tratamento nas empresas x Iceberg 10 Figura 2.1: Ciclo de RBC ............................................................................................... 13 Figura 3.1: Fluxo da informação na solução de problemas nas Gerências..................... 17 Figura 3.2: Estrutura típica vrs Estruturas para as gerências.......................................... 18 Figura 3.3: Tela inicial do assistene de inclusão de aplicativo....................................... 19 Figura 3.4: Tela do assistene de inclusão de aplicativo.................................................. 19 Figura 3.5: Tela do assistene para inclusão de eventos .................................................. 20 Figura 3.6: Tela do assistene para inclusão de itens....................................................... 20 Figura 3.7: Diagrama de casos de uso (UML)................................................................ 21 Figura 3.8: Diagrama de atividade (UML)..................................................................... 22 Figura 3.9: Tela para entrada de um novo chamado - Protótipo .................................... 23 Figura 3.10: Modelagem conceitual de dados – Cadastro de equipes............................ 24 Figura 3.11: Modelagem conceitual – Problema e solução............................................ 25 Figura 3.12: Estrutura de índice do Sistema de Help Desk ............................................ 26 Figura 3.13: Modelagem conceitual de dados – Representação parcial do caso............ 27 Figura 3.14: Modelagem conceitual de dados – Chamado............................................. 28 Figura 3.15: Modelagem conceitual de dados - Ontologia............................................. 29 Figura 3.16: Tela para controle do vocabulário.............................................................. 30 Figura 3.17: Modelagem conceitual – Características.................................................... 31 Figura 3.18: Tela que de técnicos e vocábulos indicativos extraídos do texto............... 34 Figura 3.19: Modelagem conceitual – Problemas do chamado...................................... 35 Figura 3.20: Tela que mostra os casos similares recuperados da base ........................... 36

LISTA DE TABELAS

Tabela 3.1: Representação do caso - Parcial ................................................................. 27 Tabela 3.2: Representação do caso................................................................................ 31

RESUMO

O sistema de suporte dos aplicativos utilizado por clientes e funcionários do Banco do Brasil recebe periodicamente uma enorme quantidade de consultas para resolver duvidas ou problemas no uso dos sistemas corporativos e de atendimento ao usuário do banco. A maioria destes problemas se repete ou são muito parecidos, de forma que a solução pode ser vista como uma simples reaplicação de soluções anteriormente aplicadas.

A abordagem da metodologia de raciocínio baseado em casos é usada para coletar e organizar casos, para aplicar soluções de sucesso anteriormente utilizadas na solução de novos problemas. Este trabalho analise as vantagens e os problemas de se utilizar o conhecimento disperso nos bancos de dados do sistema BB Resolve para responder novas consultas. O banco de dados armazena descrições textuais das consultas organizadas de acordo com o tipo de problemas e seus tipos de aplicações.

Um sistema de raciocínio baseado em casos foi proposto para analisar o conteúdo textual de uma consulta, identificando o vocabulário principal utilizado para descrever os problemas, os quais serão posteriormente utilizados para indexar a base de casos e medir a similaridade entre problemas e casos armazenados. Além da analise léxica dos termos técnicos, este trabalho propõe um modelo de representação que impõe uma estrutura sobre o conjunto de casos, garantindo maior eficiência no processo de recuperação.

A solução aqui apresentada garante eficiência e atendimento individualizado no atendimento do help desk, com o conseqüente aumento de satisfação do usuário. Mais ainda, o sistema oferece um novo canal de comunicação para o relacionamento do cliente com o Banco do Brasil.

Palavras-Chave: CBR, Help Desk, Banco do Brasil, Aplicativos.

A Case-based reasoning system for the help desk support of “Banco do Brasil” applications

ABSTRACT

The help desk system of “Banco do Brasil” applications receives a huge amount of consultations to solve doubts or problems in the system usage. Most of these problems are the same or quite similar to previous problems and the solution can be seemed as a simple reapplication of the same solution.

The case-based reasoning approach can be used to collect and organize cases to pro-vide the application of the successful previously applied solutions for the new incoming problems. This works analyses the advantages and problems of using the knowledge embedded in the BB Resolve databases to answer new consultations. The database store textual descriptions of the consultations organized according to the kind of problems and the application types.

A case-based reasoning system was proposed to analyze the textual content of the consultation, identifying the main vocabulary used to describe the problems that were further used to indexing the case base and measured the similarity between problems and stored cases. Besides the lexical analysis of technical terms, this work has proposed a representation model that imposes a structure over the set of cases providing more efficiency in the retrieving process.

The described solution provides efficiency and user-fitted solutions in the help desk support, with the consequent increasing user satisfaction. Moreover, the system in-creases the user satisfaction and offers a new channel of client relationship with “Banco do Brasil”.

Keywords: CBR, Help Desk, Banco do Brasil, Applications.

9

1 INTRODUÇÃO

As grandes mudanças na sociedade e nas organizações, baseadas no conhecimento do mundo contemporâneo, assim como foi com a globalização e a informatização, geram crises e incertezas, levando a necessidade de uma total compreensão destes novos rumos, levando as organizações à necessidade de criação de diferenciais competitivos, que possam assegurar a sobrevivência organizacional neste novo contexto econômico, político e social.

A totalidade dos autores consultados acredita que já não pairam dúvidas de que o conhecimento é o recurso econômico mais valioso para a competitividade das empresas e das nações. Porém, muitos têm observado uma grande distorção por parte dos gestores, que na tentativa de se adequarem às novas exigências de mercado, fazem grandes investimentos em infra-estrutura tecnológica, acreditando ser o suficiente, e raramente obtêm êxito.

A Gestão do Conhecimento propõe o tratamento de informações tanto estruturadas quanto não-estruturadas, transformando-as em vantagens competitivas. As informações estruturadas correspondem basicamente a 10% das informações contidas em uma empresa, representando apenas a “ponta de um iceberg”, enquanto o restante do iceberg, ou seja, os outros 90% correspondem às informações ditas não estruturadas, que apesar deste alto percentual, vem sendo negligenciadas por grande parte das corporações (Tucker, 1999). Tornando assim, a informação não-estruturada o mais difícil de ser gerida.

O conceito tradicional de informação estruturada é um legado do processo de sistemas de informação. Há algum tempo, um registro era composto somente de dados que representavam uma coleção de fatos agrupados. O armazenamento destes dados era muito caro, assim as organizações avaliavam a possibilidade de agrupar informações em elementos de dados pré-definidos. O objetivo era reduzir o espaço necessário para armazenar os dados. O produto final desta formatação de dados é a informação estruturada.

A informação não-estruturada é quase uma informação textual. Áudio, vídeo, voz, imagens, e objetos vívidos são todos exemplos de informação não-estruturada; ainda que possam figurar documentos eletrônicos. Embora se possam armazenar estes tipos de documento eletrônicos em um computador, eles ainda são informações não-estruturadas porque os seus conteúdos exatos e as suas organizações são imprevisíveis. Assim, por definição, informação não-estruturada é qualquer tipo de informação composta de conteúdo que não se ajusta a um modelo predefinido.

O Conhecimento pode ser definido como uma abstração interior, pessoal, de algo que foi experimentado, vivenciado, por alguém. Assim, o conhecimento não pode ser

10

descrito; o que se descreve é a informação. Também não depende apenas de uma interpretação pessoal, como a informação, pois requer uma vivência do objeto do conhecimento. Assim, “o conhecimento está no âmbito puramente subjetivo do homem ou do animal” (Setzer, 2001). Parte da diferença entre eles está no fato de um ser humano poder estar consciente de seu próprio conhecimento, sendo capaz de descrevê-lo parcial e conceitualmente em termos de informação.

O conhecimento é resultado de três elementos: informação, contexto e experiência. Não se torna conhecedor de um assunto em especial apenas com uma informação. Essa informação, após ser adquirida, deve estar relacionada com o ambiente onde vai ser usada, ou seja, deve fazer parte de um contexto onde será experimentada e praticada, tendo como resultado a memorização da informação.

Estando grande parte das empresas voltada para a “ponta do iceberg”, elas enfatizam o processamento de informações tipicamente estruturadas, deixando de ampliar seus horizontes incorporando o tratamento das informações não-estruturadas. Voltando-se para o grande contexto, ou seja, todo o iceberg, as empresas deixam de ter enfoque apenas na adaptação ao ambiente para assumirem também um enfoque de criação e inovação, redefinindo seus problemas e suas soluções. Veja Figura 1.1.

Figura 1.1: Analogia - Tipos de Informações e seu tratamento nas empresas x Iceberg

Grandes investimentos em tecnologia, sem a preocupação com a estruturação do grande contexto, não garante o sucesso da organização. Investimento em tecnologia é apenas um dos componentes da gestão do conhecimento, é necessário pensar além das máquinas, e investimentos em tecnologia somente não se apresenta como o meio mais adequado para mudanças. Pois muitas das mudanças terão que ser relativas aos recursos

11

humanos e não tecnológica.

O ser humano é o ponto central da Gestão do conhecimento, ou seja, a informação tem um lado humano comportamental que acaba influenciando e formando a cultura informacional da empresa. O conhecimento não pode ser armazenado em um disco rígido ou em prateleiras, como se faz com a informação.

Barreiras são comuns em todos os processos de mudanças. Com a Gestão do Conhecimento não é diferente. Muitas das empresas ainda operam em um sistema ultrapassado, com vários executivos defendendo com seus conceitos as informações chaves. Juntamente com uma visão utópica de tecnologia, estes conceitos acabam dificultando avanços nos processos de mudanças.

Na nova economia as pessoas (Capital Humano), estruturas (Capital estrutural) e clientes (Capital do Cliente) formam o Capital Intelectual. O conhecimento dos profissionais da organização forma o Capital Humano, as necessidades e as opiniões dos clientes formam do Capital do Cliente e a Gestão do Conhecimento forma o Capital Estrutural. Assim o modelo de gestão é democrático, valorizando a habilidade, iniciativa e a criatividade. Segundo (Zucker, 1996), as universidades estão repletas de pessoas brilhantes, mas não representam um exemplo de brilho coletivo. Como o fluxo de conhecimento é pequeno, a universidade não é inteligente como um todo. Por outro lado, as pessoas que trabalham no Mc Donald’s têm QI médio, mas trata-se de uma organização muito inteligente, capaz de oferecer a mesma qualidade em diversas culturas. Eles modularam e padronizaram seu conhecimento.

Na era do conhecimento as empresas devem se configurar para oferecer inovações para seus clientes com tal rapidez que raramente se dêem ao trabalho de criar estruturas sofisticadas como departamentos. Elas simplesmente agem.

As empresas devem investir em seus clientes da mesma forma que investem em pessoal e em estruturas. O Capital do Cliente é muito semelhante ao Capital Humano: não se possui o cliente, do mesmo modo que não se possui pessoas. Mas da mesma forma como uma organização pode investir em funcionários, não apenas para aumentar seu valor como indivíduos, mas também para criar ativos de conhecimento para a empresa como um todo, a empresa e seus clientes podem aumentar o Capital Intelectual.

O mercado é a mãe das inovações, e o destruidor das burocracias. Não se pode simplesmente assumir uma organização pesada, contratar indivíduos inteligentes e esperar que as coisas boas aconteçam. Obter resultados investindo em conhecimento requer um sistema e uma cultura organizacional que permitam o livre fluxo do conhecimento, o que significa descartar regras que abafem novas idéias.

A verdadeira Gestão do Conhecimento, não ocorrerá sem maiores mudanças nas abordagens de gerenciamento e na estrutura organizacional, o espírito empresarial deve estar sintonizado com uma gerência que valoriza muito a agilidade, utilizando mais o reconhecimento do que as punições, tendo como cultura empresarial o controle de estratégias ao invés de comportamento.

O investimento em inovação tecnológica é, sem dúvida, uma questão estratégica de grande importância. E como tal, deve ser resolvida pelas empresas. Devendo, no entanto, apoiar-se em um sistema de informações estratégicas que deve privilegiar, notadamente, aquelas relativas às tecnologias existentes e em desenvolvimento além daquelas de natureza mercadológica, econômica e social capazes de manter a estrutura produtiva e ou dinamizar os processos empresariais, colocando a organização em uma

12

nova posição competitiva. E isto só é possível pela observação, documentação, análise e sistematização do fluxo de informações sobre os ambientes interno e externo nos quais a empresa se insere. Uma ferramenta de Help Desk, sem dúvida proporciona um diferencial que além da documentação e sistematização oferece possibilidade de análise dos processos e fluxo de informações.

O importante é que se crie, difunda e incorpore o conhecimento a novos produtos, serviços, sistemas e processos, possibilitando a utilização do conhecimento e a sua gestão como vantagem competitiva.

1.1 As Gerências de Aplicativos do Banco do Brasil As Gerências de Aplicativos do Banco do Brasil são os departamentos da Unidade

de Tecnologia que trabalham diretamente na criação de aplicativos para todas as demais áreas do Banco. São compostas de divisões com núcleos formados por equipes de desenvolvimento, projetos e manutenção.

Nas Gerências de Aplicativos da tecnologia do BB, tem-se buscado uma técnica de Inteligência Artificial (devido ao grande volume de consultas) para auxiliar os usuários dos aplicativos em suas dúvidas, tanto no âmbito técnico, como no do negocio. Uma ferramenta de Help Desk. Atualmente a ajuda aos usuários, principalmente à rede de agências, é feita com o auxílio do “BB Resolve”.

O BB Resolve foi criado para satisfazer as necessidades de comunicação entre os usuários e os gestores dos aplicativos do Banto do Brasil. O usuário expõe de maneira textual o seu problema e submete ao órgão que ele acha ser o responsável e que irá resolver o seu problema. Uma das falhas no processo está no fato de muitas vezes o destinatário do BB Resolve não ser o mais indicado para resolver o problema descrito.

O outro grande problema está no fato de que uma dúvida ou dificuldade de um usuário possa ser igual, ou muito parecidos, com os de milhares de outros usuários em todo o país, e o BB Resolve não possui mecanismos de memória e recuperação de problemas já resolvidos, o que evitaria o grande número de consultas repassadas para a equipe de manutenção dos aplicativos. Uma ferramenta de RBC (Raciocínio Baseado em Casos, descrito no capítulo 2) resolveria este problema. O ponto marcante neste tipo de solução é o fato de se tratar com experiências anteriores dos próprios usuários.

Sendo assim, com o intuito de demonstrar as vantagens de uma ferramenta de RBC, e talvez um passo inicial à Gestão do Conhecimento, este trabalho propõe um estudo e uma análise além de propor um projeto de um sistema de Help Desk baseado em RBC (Raciocínio Baseado em Casos) para uso exclusivo das Gerências de Aplicativos da área de tecnologia do Banco do Brasil.

13

2 RACIOCÍNIO BASEADO EM CASOS

Raciocínio Baseado em Casos (RBC) é uma técnica de Inteligência Artificial (IA) onde, tendo-se um problema, busca-se a solução analisando um conjunto de experiências passadas. A filosofia básica desta técnica é buscar a solução para uma situação atual através da recuperação da solução de uma experiência que tenha ocorrido e apresente um contexto semelhante. O processo característico de RBC consiste em identificar a situação atual, buscar a experiência mais semelhante na memória e aplicar o conhecimento desta experiência anterior na situação atual, mantendo assim um aperfeiçoamento constante no processo (Figura 2.1) (Lee, 1998).

Figura 2.1: Ciclo de RBC (Lee, 1998)

Uma experiência anterior abstrai-se em um “caso”. O caso deve estar descrito em termos de seu conteúdo e contexto. Podendo assumir diferentes formas de representação. Um exemplo simples de caso é uma experiência descrita através de atributos e seus valores. Para fazer parte de um sistema de RBC, o caso deve ser indexado. No entanto, a falta de indexação não descaracteriza um caso. Assim, qualquer fato pode ser um caso: um texto descritivo de uma falha no sistema, uma idéia de uma nova implementação, um fato qualquer. Para a utilização computacional de um caso, deve-se garantir a sua contextualização e a modelagem adequada.

Assim, identificar o caso consiste no passo inicial e de grande importância para se projetar um sistema de RBC eficiente. A importância deste passo é tão significativa que pode definir o sucesso ou fracasso do sistema. Sendo a identificação e a definição do caso uma etapa tão importante, torna o desenvolvimento de sistemas de RBC uma tarefa variável, não se encaixando em metodologias genéricas. Cada sistema apresenta os seus próprios desafios, que quando resolvidos, modelados e implementados compreendem

Problema Soluções iniciais

Base de casos

Solução proposta

Solução confirmada

Reter

Recuperar

Reutilizar

Revisar

14

um sistema de RBC.

Além da representação dos casos, outras etapas sucedem o processo de desenvolvimento do sistema de RCB, tornando o sistema progressivamente adaptado. A indexação, a recuperação dos casos, a adaptação, a aprendizagem e a análise da situação. Podemos encarar este conjunto de etapas como áreas de problemas a serem modelados no desenvolvimento de um sistema de RBC. Entretanto, algumas destas etapas são plenamente dispensáveis, dado que se pode desenvolver um sistema de RBC que não realize adaptação ou aprendizagem, ou mesmo a análise da situação. Para configurar um sistema de RBC, basta o uso de experiências ocorridas para resolver, prever, analisar ou diagnosticar uma experiência similar atual.

2.1 Representação do Caso O conhecimento nos sistemas de RBC é essencialmente representado através dos

casos. Assim, o problema da representação do conhecimento envolve primordialmente a modelagem dos casos. O conjunto dos casos compreende a base de casos; a base de casos e suas inter-relações com o restante da estrutura de RBC compreende a memória (Wangenheim, 2003).

2.1.1 Memória ou Base de Dados Um conjunto de casos compreende uma base de casos ou memória. O tipo de

memória que organiza estes casos deve ser cuidadosamente escolhido. As questões de eficiência e tempo computacional são aqui consideradas. Os modelos de memória são estruturas de organização dos casos.

Um dos primeiros modelos de representação de conhecimento na IA foi o modelo de memória com o uso de redes semânticas. Entretanto, este modelo não é capaz de representar o conhecimento em sua totalidade. O modelo posterior que veio tentar complementar o modelo de redes semânticas é o modelo de memória episódica, de um psicólogo, (Tulving, 1983). Os pesquisadores de IA continuavam em busca de um paradigma capaz de representar o conhecimento e os melhores resultados foram conquistados pela equipe de Roger Schank em Yale. Suas pesquisas evoluíram para o desenvolvimento do modelo de Memória Conceitual, dos scripts e, posteriormente, dos "MOPS" (memory organization packets), pacotes de organização de memória, e do modelo de Memória Dinâmica.

2.1.2 Base de casos Na representação dos casos há dois componentes básicos: a descrição do problema e

a descrição da solução, como um algoritmo, por exemplo. (Kolodner, 1993) inclui um terceiro componente, o resultado da aplicação da solução ao problema. Dependendo do domínio da aplicação do sistema, a descrição dos casos deverá tomar a forma mais adequada. Cada um destes componentes será composto de acordo com a necessidade (Wangenheim, 2003).

2.2 Indexação A indexação é uma questão bastante importante considerando a estrutura e o

conteúdo da memória do sistema de RBC. A memória deve ser indexada para proporcionar recuperação e reutilização eficientes.

15

Sistemas baseados em casos são mais ou menos poderosos graças a sua habilidade para recuperar casos relevantes de uma biblioteca de casos de maneira eficiente. O fundamental para atingir este objetivo é saber como essa biblioteca deve ser indexada de maneira que o processo de recuperação seja mais preciso e eficiente.

A partir da descrição do problema, os índices devem apontar quais características do caso devem ser comparadas, determinando assim o caso que pode ser útil para se chegar a uma solução. Isto implica em inserir índices nos casos no momento de sua inclusão na base de casos, para que mais tarde eles possam ser recuperados, organizar os casos de maneira que facilite a busca e recuperação e definir os algoritmos de recuperação mais eficientes.

Muitas diretrizes na indexação têm sido propostas por pesquisadores de RBC (Watson, 1991). Os índices devem saber previamente de que forma a informação será recuperada na solução de diferentes problemas; endereçar as similaridades úteis entre os casos e permitir uma ampliação futura na base de dados.

A indexação é realizada no momento da geração do caso, ao ser criada uma meta-estrutura somente com os dados relevantes à decisão. A base de casos é gerada com a finalidade de indexação dos registros, uma vez que seria inviável, em termos de performance, permitir que, no momento da consulta, todos os registros de entrada fossem comparados com todos os casos da base.

2.3 Recuperação A partir de um problema a ser resolvido (problema de entrada), na etapa de

recuperação consiste em fazer uma busca na memória de casos e selecionar quais poderão ser aproveitados. A busca por casos é feita por algoritmos que selecionam casos com determinada similaridade com relação ao problema de entrada.

A etapa de recuperação envolve algumas tarefas, a saber: similaridade, métrica da similaridade, recuperação de casos e seleção do caso escolhido. Segundo (Aamodt & Plaza, 1994), há três maneiras de recuperar casos, a saber:

1. buscando diretamente os índices das características; 2. fazendo uma busca numa estrutura de índices; e 3. fazendo a busca em um modelo de conhecimento mais amplo.

2.3.1 Similaridade

A primeira questão a ser estudada na etapa de recuperação é a similaridade entre o caso alvo (problema de entrada) e o caso na memória a ser comparado. O que faz um caso ser similar ao outro? Esta resposta só é possível ser respondida dentro do domínio de conhecimento da aplicação. Quando a recuperação é do tipo que busca a similaridade diretamente comparando os índices, uma métrica de similaridade é usada para este cálculo.

2.3.2 Métrica da Similaridade A métrica da similaridade é a medida da similaridade entre dois casos. Em métodos

de recuperação baseados em restrições ou classificação, uma métrica talvez seja apenas necessária para estabelecer o grau de similaridade dos casos e ordená-los. Normalmente, são atribuídas diferentes importâncias às características e métodos de agregação, como a média ponderada, são utilizados.

16

2.3.3 Recuperação A recuperação é a etapa em que se dispara uma função que recupera os casos mais

similares. Esta função pode utilizar uma métrica ou pode ser orientada por metas ou por restrições. Métodos de classificação também podem ser utilizados. Esta recuperação requer que um limiar seja estabelecido para definir ou um limite de casos que podem ser recuperados ou um limite de medida de similaridade para que sejam recuperados somente os casos que ultrapassarem este limite. Em recuperações orientadas por restrições, alguns índices podem ser mais ou menos importantes podendo até excluir casos.

2.3.4 Seleção /Combinação A seleção do caso escolhido é a etapa final de recuperação. Segundo algum método

de seleção, (pergunta ao usuário, heurísticas, regras, etc.) realiza-se a escolha do caso cuja solução será utilizada como saída do sistema.

2.4 Adaptação Assim que o melhor caso é escolhido, o próximo passo é revisar este caso e sua

solução para verificar a necessidade de adaptação ao problema de entrada para, finalmente, utilizar sua solução no problema de entrada.

2.5 Aprendizagem Assim que a adaptação é feita, a solução do caso escolhido pode ser então reutilizada

para resolver o problema de entrada.

Quando outro usuário entrar com um problema igual ou similar, a solução já estará disponível.

A etapa de aprendizagem pode ser programada para execução automática ou com a participação de usuário específico e capacitado para isso. Se o usuário da aplicação informar que a solução não atendeu, a solução poderá ser descartada. A validação tem por objetivo avaliar a qualidade da solução adaptada ao problema de entrada para definir se esta tem condições de ser adicionada à memória. Alguns autores sugerem que a solução que não foi bem avaliada pelo usuário da aplicação deve ser incluída com uma observação que permita o sistema agregar este conhecimento para, depois de repetidas situações, ser retirado da memória.

A inclusão do caso adaptado, reutilizado e avaliado consiste na aprendizagem do sistema de RBC.

17

3 UMA PROPOSTA DE UM SISTEMA DE HELP DESK UTILIZANDO RBC PARA GERÊNCIA DE APLICATIVOS DO BB.

O suporte técnico aos usuários nas Gerências de Aplicativos do BB consiste em um modelo não unificado com fluxo de informações paralelas, apresentando problemas e gerando insatisfação do usuário. O usuário realiza sua consulta diretamente à equipe de manutenção ou através dos gestores (Figura 3.1). Para o usuário fica difícil saber se o seu problema está relacionado à área técnica ou á regra de negócio.

Figura 3.1: Fluxo da informação na solução de problemas nas Gerências

O meio utilizado (BB Resolve) não permite um controle eficaz do processo, possibilitando que um mesmo problema seja analisado mais de uma vez ou que jamais seja solucionado, por ser considerado já resolvido. Muitas vezes o usuário é obrigado a utilizar outros meios ainda menos eficientes, como o telefone, para resolver seus problemas urgentes. Estes contatos acabam se tornando um verdadeiro problema, pois não agrega nada a base de conhecimento da Gerência. Em situações onde milhares de usuários podem ter o mesmo tipo de problema, se houver um mecanismo de ajuda ao usuário eficiente, os ganhos poderão ser significativos.

Olhando para este quadro, não fica difícil elaborar um novo processo onde os fluxos se enquadrem na estrutura típica de sistemas de Help Desk (figura 3.2).

Usuário

Equipe de Manutenção

Gestores Equipe de versionament

o

18

Figura 3.2: Estrutura típica vrs Estruturas para as gerências

No modelo desejado, o primeiro nível é o ponto de contato inicial com o usuário e a primeira oportunidade de ajudá-lo. Normalmente este nível é estruturado em um local onde os chamados são respondidos de duas maneiras distintas:

1. automaticamente (com acesso direto aos bancos de casos ou de soluções),

2. via operador do sistema Help Desk.

O atendimento automático gera uma resposta imediata ao usuário, entretanto, este tipo de atendimento não garante uma solução imediata do problema.

2º Nível Busca

soluções imediatas

1º nível Linha de Frente

3º Nível Pesquisa para

busca de soluções

Problemas que o 1º nível não consegue

Problemas que o 2º nível não consegue

Usuário

Problemas que necessitam de conhecimento especialista

Problemas que necessitam de conhecimento especialista

Problemas que o 1º nível não consegue

Problemas que o 2º nível não consegue

Equipe de versionamento

(3º Nível)

Equipe de Manutenção (2º Nível)

Gestores (1º nível)

Usuário

Estrutura típica Estrutura para as Gerências

19

Figura 3.3: Tela inicial do assistene de inclusão de aplicativo

Figura 3.4: Tela do assistene de inclusão de aplicativo

20

Figura 3.5: Tela do assistene para inclusão de eventos

Figura 3.6: Tela do assistene para inclusão de itens

Quanto ao atendimento via operador, este normalmente tenta resolver o problema diretamente e os problemas relatados são passados a outrem somente se não forem

21

resolvidos. Os usuários precisam descrever bem seus problemas ao operador. A maneira com que o problema é descrito e repassado para o sistema, no primeiro nível, pode definir o sucesso no número de casos resolvidos neste nível. Um fator diferenciador é que no atendimento por operador, os usuários preferem o contato direto, ao invés de tentar resolver seus problemas usando o módulo automático. Como os principais meios de contato do usuário com as Gerências de Aplicativos são o BB Resolve, o correio eletrônico e o telefone, um operador de cada gerência poderá ser designado e treinado para cuidar do atendimento além de desempenhar tarefas de manutenção e controle do sistema, como cadastrar aplicativos e especialistas (veja Figura 3.7). Além de registrar os problemas enviados via BB Resolve, o operador trata dos cadastros de aplicativos e seus eventos, dos especialistas e suas equipes (Figuras 3.3 a 3.6). Um operador também bem treinado poderá receber chamados via telefone e registrá-los no sistema, desempenhado um papel de linha de frente e resolvendo problemas urgentes que tem solução conhecida na memória do sistema ou repassando para o nível superior caso não seja conhecida sua solução.

Cadastrar Aplicativo Cadastrar Especialis ta

BB-Resolve

Atender Usuário

Operador

UsuárioRegis trar Problema

Figura 3.7: Diagrama de casos de uso (UML) (Quatrani, 2001)

O Segundo Nível na estrutura do Help Desk consta de especialistas internos que trabalham para resolver os novos problemas (equipe de manutenção). Eles também podem desempenhar outras atividades. Devem, entretanto, trabalhar em turnos onde dividem o tempo entre o desenvolvimento do sistema Help Desk (rever soluções novas para incluí-las na base de soluções) e o atendimento na linha de frente. Idealmente, o segundo nível desenvolve atividades voltadas para a otimização do sistema de Help Desk atualizando-o com novos casos e soluções, bem como monitorando o desempenho dos casos, de forma a atender os usuários de maneira satisfatória.

O Terceiro Nível de apoio envolve áreas especialistas ligadas à equipe de desenvolvimento e monitoração dos aplicativos. Essas áreas especialistas podem ser constituídas por suporte tecnológico, administração de banco de dados, área de desenvolvimento de sistemas, prestadores de serviços terceirizados, especialistas externos, consultorias. Os serviços nesse nível precisam estar bem definidos, assinalando as responsabilidades de cada grupo ou pessoa envolvidos no processo.

22

3.1 Estrutura interna do sistema Após visualizar a estrutura básica de sistemas Help Desk em um nível mais elevado

de abstração, trata-se, agora, da estruturação interna do sistema. A administração do sistema Help Desk deve possuir uma interface simples intermediando as relações com os usuários através do BB resolve, do correio eletrônico ou ainda por ligação telefônica (Figura 3.8).

Início

Realiza consulta

Recebe a solução

Fim

Registra o Problema

Adequa a solução

Responde ao usuário

Cadastra na base de casos

Cadastra solução

Tem a Solução

Recupera dados

Solução conhecida

Atribuir responsável

<<Sim>>

<<Não>>

<<Sim >>

<<Não>>

EspecialistaOperadorUsuário

Figura 3.8: Diagrama de atividade (UML) (Quatrani, 2001)

3.1.1 Fazendo a consulta Os Usuários dos aplicativos das Gerências de Aplicativos do BB têm diversos

instrumentos para auxiliá-los na solução de problemas. Entre eles o LIC (Livro de Instruções Codificadas) que presta esclarecimentos nas diversas áreas. Entretanto alguns problemas exigem soluções imediatas e ainda não estão registrados no LIC. O meio mais comum e recomendado para complementar e auxiliar de maneira urgente na solução de problemas é o BB Resolve. Dependendo do nível de urgência, são realizadas consultas por telefone diretamente ao gestor ou até mesmo à equipe de manutenção da Gerência da Tecnologia do BB.

3.1.2 Registro de problemas

O operador de Help Desk ou um especialista responsável para atuar na linha de frente, o primeiro nível da estrutura, desempenhará o papel de transcrever o problema do usuário, exposto através de um dos instrumentos de auxilio (BB Resolve, Correio eletrônico ou Telefone) para o sistema de Help Desk. Cada BB Resolve, Correio eletrônico ou Telefonema, dará origem a um chamado. Quando o operador de Help Desk for registrar um chamado no sistema, deve-se identificar o usuário (nome, telefone

23

para contato, dia e hora), em seguida passa para os problemas do chamado (aplicativo que apresenta o problema, evento ou o momento que ocorreu o problema no aplicativo). Assim como um telefonema, um correio eletrônico ou um BB Resolve pode ter um ou mais problemas descritos, um chamado também poderá conter um ou mais problemas. Um cuidado especial deve ser tomado pelo operador de Help Desk ao identificar os problemas que comporão o chamado. Quando um problema se tornar difícil de descrever, será o indicativo de que se trata de um outro problema. Neste caso um novo problema deve ser criado, o qual terá sua própria descrição. Em seguida a descrição dos problemas em detalhes, o operador deverá caracterizar cada problema, fornecendo o maior número de informações possíveis. Neste ponto o mesmo cuidado deve ser tomado, quando um problema ficar difícil de caracterizar, um novo problema deve ser criado, descrito e caracterizado separadamente. A qualidade da descrição e da caracterização dos problemas é fundamental no bom desempenho do sistema, pois cada problema poderá se tornar um caso, e quanto mais especificado e caracterizado for o caso, melhor será a sua recuperação. O número de registro do problema é gerado automaticamente pelo sistema. Veja na Figura 3.9 um exemplo do registro de um novo chamado. Maiores detalhes sobre a representação de casos estão descritos na seção Representação do Caso e Indexação no Sistema de Help Desk.

Figura 3.9: Tela para entrada de um novo chamado - Protótipo

3.1.3 Recuperação de casos A recuperação de casos é feita pelo sistema utilizando as informações obtidas no

registro do problema. Maiores detalhes sobre a recuperação de casos estão descritos na seção Recuperação no Sistema de Help Desk.

24

3.1.4 Atribuir responsável Quando um problema não for resolvido no primeiro nível, ele deverá entrar em filas

onde será direcionado para áreas e analistas específicos que buscarão resolvê-lo. Quando o último problema do chamado for resolvido, o chamado será encerrado. A identificação do analista é registrada no cadastro de problemas. O analista responsável pela manutenção verifica se trata de um problema novo e, caso seja, registra anotações à medida que vai resolvendo o problema e estas vão compor o banco de soluções do sistema. O usuário que registrou o problema recebe uma mensagem informando a solução. A atribuição do responsável pelo problema será automática com base em informações do usuário a respeito da aplicação que gerou o problema. Cada subdivisão do aplicativo poderá ter uma equipe de especialistas responsáveis (Figura 3.10).

Equipe responde pelo item

Item esá sob responsabilidade da equipeR esponde por

Espec ialisata está na equipe

Equipe tem espec ialis tas

Está em

ItemCódigo do ItemDenominação do Item

EspecialistaCódigo do especialis taNome do especialistaMatrículaE_mail

EquipeCódigo da equipeDenominação da equipe

Figura 3.10: Modelagem conceitual de dados – Cadastro de equipes

3.1.5 Cadastro de soluções Neste cadastro deverão ser arquivadas as informações sobre os problemas, ou seja, a

anotação do responsável pelo atendimento na busca pela solução de um chamado. Os usuários devem ter acesso controlado a esse nível de informação para acompanhar a evolução do atendimento de seu problema ou para verificar a existência de solução de problemas que se apresentem a ele, antes de registrar um chamado para um novo problema. Isto poderá ser implementado na Intranet (Figura 3.11).

25

Soluc iona

ProblemaCódigo do problemaDescrição do problema

SoluçãoCódigo da soluçãoDescrição da soluçãoIndicativo de solução principal

Figura 3.11: Modelagem conceitual – Problema e solução

3.1.6 Relatórios básicos e consultas Esses relatórios devem apresentar informações básicas sobre os atendimentos

(quantitativos de problemas abertos, pendentes e fechados; especialistas responsáveis; problemas novos, pendentes, etc). As consultas de usuários e da equipe do sistema podem ser direcionadas a problemas resolvidos, atendimentos pendentes e seus andamentos, etc, cujas informações constam no banco de dados central. Esses são procedimentos vitais para o acompanhamento do desempenho do sistema pelo seu administrador e pelos usuários.

3.1.7 Monitoração do atendimento O sistema deve ser programado para disparar procedimentos que notifiquem

chamados muito antigos e outras situações predefinidas. Para a administração desses ambientes, devem ser gerados diversos tipos de relatórios (de evolução de problemas, por tipo de problemas, problemas não resolvidos, problemas resolvidos, problemas pendentes, lista do banco de soluções, etc).

3.2 Representação do Caso e Indexação no Sistema de Help Desk Uma demanda surge pelo fato da dificuldade do usuário em apresentar o problema

de entrada no formato compatível com o modelo de representação dos casos da base. Se o passo seguinte à apresentação do novo problema é sua comparação com os casos da base, torna-se necessário que o problema de entrada possa ser identificado pelo sistema dentro dos mesmos moldes de representação dos casos na base. Quando isto não ocorre é necessário uma uniformização da entrada para permitir a comparação. Será necessário, então, fazer o chamado ajuste do problema.

Considerando que as Gerências de Aplicativos do BB possuem diversos aplicativos, e que dificilmente os usuários desconhecem qual aplicativo gerou o problema, o primeiro elemento proposto para compor a representação do caso será a sigla do aplicativo.

Para montar outros elementos, poderão ser consideradas características dos casos que geram um evento. Por exemplo, o valor máximo para se contratar Capital de Giro fica caracterizado como uma regra de negócio em tempo de análise de proposta de operação de crédito. Assim um outro elemento seria Análise de Proposta, o evento da ocorrência do problema. Ao tentarmos comparar um problema no valor de uma

26

operação de crédito, a busca será por análise de proposta de operação de crédito. Um índice secundário poderá ser considerado a partir deste elemento, pois os casos para o aplicativo que controla operações de crédito (COP – Controle de Operações), já foram afunilados pela sigla do aplicativo, que poderá ser o índice primário. O problema maior é que cada aplicativo possui seus próprios eventos, tornando necessária a criação de índice secundário dinâmico baseado no índice primário, ou seja, cada aplicativo terá seus eventos.

Existe situação que o evento é muito abrangente e exige uma subdivisão para torná-lo detalhado o suficiente para uma recuperação eficiente do caso. O evento Análise da Proposta, citado no exemplo, pode ser mais bem especificado pelos itens: Análise do Proponente, Análise do Item Proposto, Análise de Encargos, etc. Cada um destes itens, especificados no momento do cadastramento do aplicativo no sistema de Help Desk, é uma instância de Itens do Evento (Figura 3.12).

Figura 3.12: Estrutura de índice do Sistema de Help Desk

Até aqui o caso está representado: com o Aplicativo, com os Eventos do Aplicativo e com os Itens do Evento (Figura 3.13). Cada aplicativo poderá ter uma quantidade variável de eventos, e cada evento poderá ter uma quantidade variável de itens. Com esta parametrização cada aplicativo poderá ter seus eventos e seus itens denominados conforme a ontologia utilizada no negócio de cada aplicativo. A atribuição dos eventos e dos itens para cada aplicativo, afetará diretamente a eficiência do sistema. O aplicativo deverá ter uma divisão com o número de eventos suficientes para especificar cada contexto, tomando-se o cuidado de não exceder a divisão para não tornar difícil para o operador de Help Desk adequar o problema ao caso. O mesmo cuidado também deve ser tomado na divisão do evento em itens.

Sigla do Aplicativo

Eventos do Aplicativo

Itens do Evento

27

Evento tem itens

I tem está em ev entoTem 2

C ada aplicat iv os possui seus N ev entos

C ada ev ento pertence a um aplicat ivo

Tem 1

Aplicativocódigo_aplicativoSigla_aplicativoDenominação aplicativoGerência do aplicativo

EventoCódigo do EventoDenominação do Evento

ItemCódigo do ItemDenominação do Item

Figura 3.13: Modelagem conceitual de dados – Representação parcial do caso

A primeira filtragem para recuperação dos casos semelhantes ao problema consultado (problema de entrada), será feita com as entidades: Aplicativo, Evento e Item. Assim o operador terá que saber, consultando o texto do problema, a que aplicativo, evento e item o problema se refere. Portanto se o texto tiver uma consulta sobre o preenchimento das parcelas de reposição de uma operação de financiamento de capital de giro, por exemplo, o operador terá que saber, ou consultar no momento, que o aplicativo para o financiamento de capital de giro é o COP – Controle de Operações. Este conhecimento muitas vezes é informado pelo próprio usuário. Não é incomum no texto do usuário conter o nome ou a sigla do sistema (aplicativo). O ideal nesta parametrização, é que cada aplicativo ou conjunto de aplicativos correlacionados, possua seu operador de Help Desk para trabalhar na linha de frente. Até agora, para o exemplo mencionado, a representação do caso poderia ficar como está demonstrado na Tabela 3.1.

Tabela 3.1: Representação do caso - Parcial

Aplicativo COP – Controle de Operações

Evento Acolhimento de proposta

Item Cronograma de reposição proposto

Certamente apenas os elementos descritos até agora não representam o caso com

28

eficiência. Será necessário incorporar à representação do caso, todo o contexto do problema. Em uma ferramenta de Help Desk um dos pontos importantes é o gerenciamento do chamado. O chamado contém a descrição textual do problema do usuário e já está previsto no modelo conceitual do sistema, independente da modelagem do caso (Figura 3.14). Assim a descrição textual do problema poderá fazer parte da representação do caso, possibilitando uma análise textual na recuperação do caso.

Estado do chamado

R elac iona

ChamadoCódigo do chamadoMatricula do chamadorNome do chamadorTelefone para contatoData do chamadoHora do chamado

ProblemaCódigo do problemaDescrição do problema

Estado do chamadoCódigo do estado do chamadoDenominação do estado do chamado

Figura 3.14: Modelagem conceitual de dados – Chamado

Para que o sistema de Help Desk analise um texto, será necessário dotá-lo de componentes para a extração automática de informação textual.

3.2.1 Vocabulário e Dicionário de termos Técnicos Devido às variações de vocabulário técnico e do negócio identificadas, é preciso que

um vocabulário e um dicionário de termos técnicos sejam desenvolvidos. Assim, é por meio desses léxicos que se pode inferir que "taxa de juros da operação de crédito", "encargos básicos do contrato" e "percentual de juros do financiamento", todos trechos extraídos de BB resolve, são similares entre si e correspondem às diversas variações encontradas na linguagem do domínio de operações de crédito. Para a elaboração desses glossários, um rol básico do LIC (Livro de Instruções Codificadas) ou até mesmo de BB Resolves já solucionados deve ser identificado, de forma a subsidiar a pesquisa, por parte do operador, de expressões e termos que os comporão (Figura 3.15).

29

Equiv ale

Palav ra C hav e

Term o

Sinônimo

C lass if ica

ProblemaCódigo do problemaDescrição do problema

VocabulárioCódigo do vocábuloVocábuloNível de signif icância

Classe da palavracódigo da classeNome da classe

Termo TécnicoCódigo do TermoDenominação do Termo

Figura 3.15: Modelagem conceitual de dados - Ontologia

3.2.2 Analisador sintático Uma das formas de potencializar o uso do vocabulário e do dicionário de termos

técnicos, em um ambiente em que a variação de termos é tão esparsa, é o uso combinado de um analisador sintático. Um analisador sintático já foi utilizado com sucesso em projetos, como os que se fundamentam em padrões proposicionais. Um padrão proposicional, de acordo com (Bruninghaus & Ashley, 2001), é obtido a partir da análise da função sintática de certas palavras que se repetem comumente. Assim, uma vez identificado um padrão em um domínio, um analisador sintático pode extrair conhecimento de novos textos simplesmente identificando a ocorrência desse padrão, e, a partir dele, por exemplo, seu sujeito ou objeto direto. O especialista teria de estar a par de uma variedade extensa de instruções normativas. A identificação exaustiva de termos técnicos e normativos no LIC pode se tornar tarefa infindável e por isso, o balizamento proporcionado por padrões proposicionais pode ser altamente útil. Ao se consultarem o LIC verifica-se que, embora os termos e denominações para coisas similares se alterem, principalmente em nível de detalhamento, de uma norma para outra, os verbos e substantivos utilizados para dispor sobre as ações reguladas via de regra são os mesmos. Por exemplo, "cadastrar", "cadastro", e "cadastrada" são palavras-chave do LIC que são empregadas de forma padronizada em quaisquer instruções, sejam elas técnicas ou do negócio. Com a utilização de padrões proposicionais a partir dessas palavras-chave, fica mais fácil identificar os termos e expressões indicativas distintas para coisas similares, tanto na fase de representação do conhecimento, quanto na de consulta. Para tal, basta que se procure, nas normas e textos de pesquisa, analisar sintaticamente seus conteúdos com base em poucos padrões criteriosamente estabelecidos, para que se identifique se há ou não similaridade entre certos nomes e expressões relevantes. Outro ponto

30

importante é o nível de relevância dos nomes, verbos e expressões técnicas no contexto do negócio. Certamente em uma ferramenta de Help Desk a palavra “falha” tem muito menos relevância do que o vocábulo “imprimir”, por exemplo (figura 3.16).

Figura 3.16: Tela para controle do vocabulário

3.2.3 Extração automática da informação textual No caso da descrição textual do problema, a extração de conhecimento exige uma

ampla gama de ferramentas utilizando o dicionário de termos técnicos e do vocabulário. O funcionamento das ferramentas, nesses casos, deve buscar a identificação de vocábulos e termos técnicos que possam contribuir para a posterior recuperação e comparação do novo problema. Essa possibilidade de agregação de novas decisões é que, por somar novos vocábulos indicativos à base de conhecimento, proporciona a capacidade de aprendizado por parte do sistema, que pode assim ser considerado inteligente. Um exemplo desse aprendizado pode se dar por meio do vocabulário e dos padrões proposicionais, que, ao permitirem a identificação de novas palavras ou expressões cumprindo as mesmas funções sintáticas em padrões que se repetem em dois problemas com alto grau de similaridade, conferem sensibilidade ao sistema para perceber, ou alertar, que duas palavras ou expressões distintas significam a mesma coisa naquele domínio de conhecimento específico, enriquecendo dinamicamente, portanto, seu vocabulário.

31

R esponde

R esponde

CaracteristicaCódigo da característicaDenominação da característica

OpçãoCódigo da opçãoDenominação da opção

Caso : 2Código do caso

Figura 3.17: Modelagem conceitual – Características

Com o crescimento da base de casos, que é justamente o que se espera em um sistema de RBC, mesmo com a descrição textual do problema indexada por termos técnicos e vocábulos indicativos, não está garantido um bom desempenho do sistema. Provavelmente um grande número de casos com termos semelhantes ainda serão extraídos da base na primeira fase de recuperação de casos, provocando uma ambigüidade de casos. Para garantir o bom desempenho do sistema será necessária uma representação do caso com maiores detalhes. Características pré-definidas dos aplicativos poderão ser incorporadas à representação do caso (Figura 3.17). Estas características também poderão ser divididas nos eventos e nos itens. Assim a representação final do caso, para o exemplo citado anteriormente, ficaria como demonstrado na Tabela 3.2.

Tabela 3.2: Representação do caso (continua)

COP – Controle de Operações

Características do aplicativo:

Aplicativo

Processamento: On Line

Acolhimento de proposta

Características do evento:

Evento

Local do acolhimento: Agência

32

Plataforma: Baixa

Linha de Crédito: BB Giro com reposição em parcelas

33

Tabela 3.2: Representação do caso (continuação)

Cronograma de reposição proposto

Características do item:

Reposição em parcelas: Iguais

Item

Periodicidade de reposição:

Mensal

Descrição textual do problema

Ao tentar acolher uma proposta de BB giro, quando na reposição informam-se as parcelas de reposição para doze parcelas iguais com periodicidade de trinta dias e com carência de quinze dias, o sistema gera uma falha informando que o prazo máximo para reposição é de trezentos de sessenta dias.

Vocábulos indicativos

Acolher, periodicidade, carência.

Termos técnicos

Proposta, BB giro, reposição, parcelas de reposição, parcelas iguais, prazo máximo para reposição.

- Informe reposição em 11 parcelas iguais ou;

- Informe reposição em doze parcelas iguais sem prazo de carência, ou;

-Informe reposição em parcelas distintas datando as parcelas de trinta em trinta dias, exceto na última, que deverá vencer em quinze dias após o vencimento da penúltima parcela.

Solução

Veja também:

LIC 54.545.54.a-c

3.3 Recuperação no Sistema de Help Desk A recuperação se dará em três fases: extração por seleção através dos índices

primário e secundário (Aplicativo, Evento e Item); pontuação por número de características iguais; e pontuação por número de vocábulos indicativos e termos técnicos iguais ou similares.

3.3.1 Extração por Seleção Por motivos de performance, acessibilidade e normativos internos do BB, os dados

deverão se armazenados em um Bando de Dados Relacional. O Banco de Dados Relacional já garante o processo de indexação dos elementos primário e secundário. Como a representação do caso proposta prevê um grande dinamismo, grande parte dos casos terá de ser recuperada na primeira fase, para serem submetidos à análise automática, resultando em uma filtragem final para obter a melhor solução (o melhor caso). Assim o primeiro rol de casos será o resultado da comparação do Aplicativo, do Evento e do Item informados pelo operador de Help Desk com os mesmos elementos

34

armazenados na base de casos. Portanto, tais elementos são obrigatórios na base de casos.

3.3.2 Pontuação Com o rol de casos extraído por seleção, o passo seguinte será pontuar cada caso

para obter um nível de similaridade. O caso mais pontuado será o melhor caso. Com o aplicativo, os eventos e os itens caracterizados, no problema de entrada, será feita uma consulta no rol de casos recuperados na seleção para detectar os casos com características iguais. Os casos com maior número de características iguais receberão maior pontuação. Um terceiro nível na etapa de recuperação trata de comparar as termos técnicos e vocábulos indicativos, automaticamente identificados no texto do problema através do vocabulário e do dicionário de termos técnicos. Neste ponto, o nível de significância do termo será considerado, evitando que um vocábulo pouco significativo no contexto, provoque uma pontuação elevada no caso. Veja na Figura 3.18 um exemplo de termos extraídos do texto, considerando apenas palavras significativas no contexto.

Figura 3.18: Tela que mosta termos técnicos e vocábulos indicativos extraídos do texto

3.4 Adaptação no Sistema de Help Desk Quando um caso for igual ao problema de entrada (100% similar), o problema será

resolvido com a solução deste caso. Então o caso perfeito passa a fazer parte da solução do chamado. Um chamado poderá conter um ou mais problemas, mas cada problema dará origem a um único caso (Figura 3.19). Esta referência possibilita uma estatística na base de casos para obter o desempenho dos casos, e até mesmo para saber que tipo de problemas tem ocorrido com maior freqüência. No entanto, há grandes possibilidades de

35

um problema estar próximo de uma solução e não se aplicar simplesmente na resolução do problema. Quando um caso é muito similar ao problema, pode significar para o operador de Help Desk ou até mesmo para o especialista encarregado, que um problema muito parecido já foi resolvido anteriormente. Assim, adaptar o caso similar exige menos esforço do que entrar um caso novo. Neste momento o operador poderá alterar os dados que representam o caso, e até mesmo adicionar novas características. Um ponto interessante é que o operador poderá adicionar características ao caso adaptado que não existiam quanto o caso original foi armazenado na base, levando ao sistema um constante aperfeiçoamento e especialização.

Estado do caso

Liga

Estado do chamado

R elac ionaSoluc iona

ChamadoCódigo do chamadoMatricula do chamadorNome do chamadorTelefone para contatoData do chamadoHora do chamado

ProblemaCódigo do problemaDescrição do problema

SoluçãoCódigo da soluçãoDescrição da soluçãoIndicativo de solução principal

Estado do chamadoCódigo do estado do chamadoDenominação do estado do chamado

Caso : 1Código do caso

Estado do casoCódigo do estado do casoDenominação do estado do caso

Figura 3.19: Modelagem conceitual – Problemas do chamado

3.5 Aprendizagem no Sistema de Help Desk Quanto um caso é adaptado para resolver um problema de entrada, dá origem a outro

caso que será armazenado na base de casos. Assim pode-se dizer que houve aprendizagem pelo sistema de Help Desk. Mas a inteligência do sistema está distribuída entre o conhecimento, através de sua base de casos, e os critérios de indexação e recuperação de casos. Assim, além do aprendizado tradicional através da adaptação de casos, uma manutenção periódica com revisão e impostação de novos casos, tornará o sistema mais eficiente. Um outro fator interessante é que quanto mais se usa o sistema, mais especialista ele se torna. Assim um ajuste periódico nos critérios de pontuação, com o objetivo de torná-lo mais exigente, caracterizará uma afinação. O sintoma da necessidade deste ajuste poderá ser observado quando o sistema retornar um número muito grande de casos parecidos. Veja na Figura 3.20 um exemplo de casos similares recuperados na base de casos.

36

Figura 3.20: Tela que mostra os casos similares recuperados da base

37

4 VALIDAÇÃO

Considerando que os aplicativos da Gerência de Aplicativos está em constante manutenção e ajustes, as etapas de adaptação e aperfeiçoamento do sistema de RBC tornam-se um diferencial significativo. No entanto, a eficiência da ferramenta não é garantida com o cumprimento da todas as etapas citadas. É necessário, ainda, que se proceda à etapa de validação do sistema como ocorre com qualquer outro sistema. No entanto alguns passos são específicos de sistemas de RBC.

A validação de um sistema de RBC pode ser feita em função de vários aspectos. Métodos de validação de outros sistemas inteligentes são adequados, mas ainda há um conjunto de técnicas de validação exclusivas para os sistemas de RBC. Uma questão exclusiva dos sistemas de RBC trata-se de avaliar se a tarefa para qual o sistema é proposto, quando executada por especialista humano, é uma tarefa baseada em casos. Nas Gerências de Aplicativos da Tecnologia do BB as equipes de desenvolvimento desempenham o papel de orientar os usuários dos aplicativos e, quando necessário promover as alterações nos programas. Notadamente muitas das questões vindas dos usuários aprecem repetidas vezes e consomem o tempo dos analistas com problemas já resolvidos anteriormente, ou estão sendo conduzidos por outra equipe. Considerando cada questão dos usuários como um caso, a solução seria analisada, preparada e adaptada apenas uma vez. Liberando as equipes para o trabalho exclusivo de manutenção.

Em termos gerais, estas são algumas das características a serem consideradas para a validação de um sistema de RBC:

• características técnicas; tais como estabilidade e operacionabilidade; • escolha do problema; se o problema é próprio para o tipo de raciocínio; • características organizacionais; se o sistema é adequado à operação dentro de uma

organização; • características econômicas, (retorno do investimento, aumento na qualidade de

serviços); • características estratégicas, se a memória de casos pode ser vista como um ativo; • qualidade e eficiência com relação às principais etapas de um sistema baseado em

casos: recuperação, adaptação, representação dos casos e aprendizagem. Com relação à aprendizagem, além de avaliar a eficiência e qualidade, deve ser considerado se o aumento de robustez resultante da aprendizagem irá realmente beneficiar a qualidade do sistema ou diminuir sua velocidade, utilidade e eficiência;

• avalia-se o sistema comparativamente a especilistas humanos em dois momentos: num primeiro, apenas compara-se o sistema ao especilista; num segundo momento, o especialista utiliza o sistema como um colega ou um assistente técnico. Nesta etapa, calcula-se os percentuais em que o especialista utilizou as sugestões oferecidas pelo

38

sistema.

4.1 Aplicações A grande questão é se uma aplicação de RBC aplica-se a determinada necessidade.

Em uma ferramenta de Help Desk um ponto crítico é determinar quanto uma aplicação deve ser genérica, tomando-se o cuidado de não “engessar” a aplicação para torná-la específica ao que se pretende, a ponto de prejudicar a sua capacidade de aprendizagem e ao mesmo tempo deixá-la com características satisfatória ao processo.

As aplicações já desenvolvidas de sistemas de RBC são um forte indicativo do potencial do paradigma. Três são os tópicos pertinentes às aplicações que são considerados relevantes:

1. quais os tipos de aplicações são adequados; 2. quais as ferramentas disponíveis para implementação; e 3. quais são as importantes aplicações que podem orientar e ilustrar o

potencial dos sistemas de RBC. Muitos das aplicações que podem ser implementadas em um sistema baseado em

casos são comuns a outras técnicas de IA. Genericamente, estes são alguns dos tipos de problemas endereçados:

• interpretação, • projeção, • diagnóstico, • análise e elaboração de projetos, • formação de preços, • desenvolvimento de propostas, • planejamento, • configuração, • "scheduling", • monitoramento, • "debugging", • consertos, • análise situacional, • classificação, • instrução, • aprendizagem e controle.

Um resumo de aplicações de RBC está em (Grupe, 1993). As ferramentas para desenvolvimento e implementação de sistemas de RBC não têm

a mesma aplicabilidade do que as "shells" de outras técnicas de IA pela diversidade de estilos de estruturação das bases de dados destes sistemas. Um dos fatores que torna um problema adequado para ser implementado num sistema de RBC é o fato de existir um banco de dados com os casos para utilização. Sendo assim, muitas vezes é mais eficiente desenvolver o sistema com uma ferramenta que seja compatível com os dados disponíveis do que o oposto. Mesmo assim, as seguintes ferramentas servem como plataforma para implementação de sistemas de RBC:

• ART*Enterprise; • CASE-1; • CasePower;

39

• CBR2; • CBR Express; • The Easy Reasoner; • Eclipse; • ESTEEM; • Induce-It; • KATE; • MEM-1; • ReCall; • ReMind; • S3-CASE.

Um trabalho que apresenta e compara estas ferramentas foi feito por (Watson, 1991).

Algumas aplicações de cunho comercial que estão em atividade, outras são sistemas desenvolvidos apenas com objetivo de pesquisa foram citadas por alguns autores. O comentário que acompanha o nome das aplicações é uma tentativa de classificar as aplicações conforme os tipos de problemas resolvidos pelos sistemas.

• ABBY, conselheiro romântico. • ACBARR, navegação de robôs. • ALFA, projeção de carga elétrica. • ARCHIE, projetos arquitetônicos. • CABINS, scheduling. • CADET, projeto de componentes mecânicos. • CASEY, diagnostica a causa e a solução para problemas cardíacos. • CADSYN, projeto estrutural de edifícios. • CASCADE, auxilia na recuperação de falhas em sistemas VMS. • CELIA, diagnóstico de automóveis. • CHEF, planejamento de receitas. • CLAVIER, projeto de layout de autoclave. • COACH • COPRA (IRS) • COMPAQ, Help Desk para suporte a clientes, fazendo diagnóstico e reparos. • GREBE, aplica regras baseadas em preceitos legais e bom senso sobre casos legais,

para identificar e explicar conseqüências legais de uma situação. • HYPO, contrói argumentos tanto para defesa como para a acusação utilizando casos

legais que compartilham das mesmas características. O sistema constrói um argumento, uma réplica e uma tréplica para seu "cliente".

• JUDGE, contrói sentenças para crimes de homicídio praticados por delinqüentes juvenis a partir de situações de briga. A sentença é construída em cima de circunstâncias do crime: quem iniciou a luta, grau de violência e quais as chances do acusado de repetir o crime. A sentença é construída através de adaptações feitas sobre uma situação similar.

• JULIA, projetista para planejamento de refeições. • MARS, analisa transferências e regulamentações corporativistas. • MEDIATOR, planejamento, diagnóstico e consertos; para mediar disputas, o sistema

identifica metas e submetas das partes e busca uma solução que é um plano que visa

40

atingir metas sujeito a restrições. • NETTRAC, planejamento e monitoramento de administração de tráfego em redes de

telefones públicos. • PERSUADER, atua como mediador de negociações sindicais, adapta planos

considerando as metas e restrições dos agentes envolvidos, elabora argumentos e adapta os os padrões praticados na indústria.

• PLEXUS, planejamento de tarefas cotidianas. • PRISM, classificação de textos e roteamento de telexes interbancários. • PRODIGY/ANALOGY, planejamento e aprendizagem. • PROTOS, classificação heurística para diagnóstico. (Aha, 1994) e classificação por

Kolodner que ainda ressalta que seu procedimento é bem mais "accurate" que abordagens indutivas.

• QUICKSOURCE, assitência técnica de computadores por telefone. • SQUAD, controle de qualidade de softwares. • SWALE, gerador de explicações.

Algumas referências que descrevem aplicações são: (Kolodner, 1993), (Riesbeck & Schank, 1989), (Grupe, 1993).

4.2 Híbridos Há vários trabalhos que combinam RBC com outras técnicas, principalmente

sistemas especialistas e sistemas indutivos. Entretanto, algumas aplicações são apenas integrações entre técnicas.

Dentro das metodologias baseadas em casos, há integrações de aplicações com conhecimento representado por casos dentro de um domínio específico combinados com metodologias com conhecimento mais geral, (Branting, 1991). (Aamodt, 1993) propõe que o uso de conhecimento de vários domínios como alternativa de utilização em um sistema de RBC quando o conhecimento contido nos casos não é suficiente para solucionar o problema de entrada. (Aamodt, 1993) chama de integração horizontal quando o método de RBC falhar e então o sistema utiliza o método contido no universo de conhecimento geral. Integração vertical, quando o conhecimento geral for utilizado dentro do método baseado em casos.

Talvez seja este o futuro dos sistemas que se propõem a realizar tarefas que anteriormente eram exclusivas de especialistas humanos.

4.3 Raciocínio baseado em regras vs. RBC O mais forte argumento para a utilização do paradigma baseado em casos para a

simulação de um especialista humano para resolver problemas de usuários é o fato de o que faz um especialista é sua experiência. Se o conhecimento especialista fosse somente aquele dos livros, bastaria modelar a informação dos livros em regras e pronto. Entretanto, num processo de extração de conhecimento especialista, observa-se que o especialista coloca sua experiência para tentar explicar como faz seu trabalho. Muitas vezes, sua especialidade é ilustrada através de exemplos, experiências passadas que justificam a abordagem escolhida para tratar determinado problema. Além disso, quando é possível estabelecer uma regra para determinada situação, esta vem sempre acompanhada de exceções.

Muitos são os artigos que apresentam os sistemas baseados em casos como uma

41

alternativa aos sistemas baseados em regras. Esta forma é extremamente antididática porque aproxima e confunde duas técnicas que, não têm muito em comum além do fato de serem ambas técnicas de IA e servirem para análise, diagnóstico e outros problemas comuns, embora com características bem distintas para os mesmos tipos de aplicação.

Em termos práticos de implementação, a grande vantagem dos sistemas baseados em casos sobre os baseados em regras refere-se ao conhecimento. O sistema baseado em casos não requer extração de conhecimento para sua representação. Mesmo que a extração de conhecimento especialista não fosse o maior gargalo dos sistemas baseados em regras, ainda assim não é possível representar todas as interações que a complexidade de um vasto domínio compreende. A representação do conhecimento nos sistemas de RBC engloba toda a complexidade do universo da aplicação com as informações presentes nos casos, ficando o problema de representação uma tarefa bem mais fácil do que num sistema baseado em regras.

42

5 CONCLUSÕES

A integração da tecnologia de RBC ao Help Desk permite o desenvolvimento de assistentes inteligentes para atendimento ao usuário. Permite eficiência e individualidade em atendimentos exigidos pela rede de agências do Bando do Brasil. Permite que seja atendida a um baixo custo com alto potencial de satisfação do usuário. Dessa forma a utilização de RBC altera não só a orientação de um Help Desk: Não é apenas o aumento de eficiência e a otimização do processo de suporte ao usuário que está no centro das atenções, mas também uma nova estratégia de relacionamento com usuário. O RBC abre a usuários, funcionários e especialistas no desenvolvimento de sistemas um acesso intuitivo e interativo às mais variadas fontes de conhecimento e lhes permite resolver problemas a qualquer instante e em qualquer lugar. Através do RBC é possível que tanto funcionários inexperientes como técnicos especialistas utilizem uma mesma fonte de conhecimento durante o seu trabalho para responder a consultas de usuários de forma rápida e objetiva. O mesmo conhecimento pode auxiliar usuários e outros funcionários, podendo estar disponível tanto na Intranet como em terminal emulado. Através dessa disponibilidade muito maior do conhecimento e do suporte à decisão proporciona redução dos custos e aumento de eficiência e garantia de qualidade do suporte ao usuário.

5.1 Resumo das vantagens do RBC • Extração do conhecimento; basta ter um banco de dados. A difícil fase de extração

do conhecimento especialista é facilitada nos sistemas de RBC pois a representação do conhecimento pode ser feita com o preenchimento direto dos fatos que descrevem uma experiência. O paradigma proporciona um excelente mecanismo de aprendizagem, que pode ser utilizado para aquisição automática de conhecimento.

• Representação do conhecimento; A tarefa de representação do conhecimento resume-se em escolher o tipo de estrutura da base de casos. Em aplicações onde a complexidade exigir, é necessária a criação de índices, entretanto muitas aplicações omitem este passo.

• Reutilização do conhecimento; o conhecimento contido nos casos pode ser utilizado ou combinado e adaptado para gerar novas soluções além das originalmente presentes na memória.

• Aprendizagem; a atualização do conhecimento é feita automaticamente, na medida que as experiências são utilizadas, assim o sistema pode crescer e incrementar sua robustez e eficiência.

• Justificativas; (humanas) as justificativas são sempre consistentes com as soluções por serem as próprias experiências, representando mais um aspecto de proximidade ao comportamento humano do sistema. Além disso, as justificativas podem avisar

43

sobre possíveis riscos que o uso de determinada abordagem pode implicar. • Consciência Conforme (Stottler, 1994) uma outra vantagem dos sistemas de CBR é

uma forma de consciência que estes sistemas possuem com relação a suas próprias limitações. Se o sistema não encontra casos com a devida similaridade com o caso em análise, o sistema não gera solução alguma. Isto evita possíveis problemas gerados por sistemas sob outros paradigmas que podem gerar uma solução aproximada.

• Fácil acesso as soluções; (Kolodner, 1993) aponta outras importantes vantagens dos sistemas de CBR que reduzem o espaço de solução. Primeiro, estes sistemas podem recuperar uma solução rapidamente, ao contrário de outros sistemas que precisam fazer todo um trabalho para buscar uma solução numa vasta base de conhecimento.Outra vantagem refere-se ao fato de que o problema deve ser identificado pelo sistema o suficiente para recuperar uma solução, não é necessário que o sistema entenda perfeitamente as condições e circunstâncias do problema para propor uma solução. Os sistemas de RBC também proporcionam um meio de resolução de um problema quando não houver um algoritmo disponível para avaliação e solução do mesmo.

44

REFERÊNCIAS

AAMODT, A. Explanation-Driven Case-Based Reasoning: Topics in Case-Based Reasoning. In: EUROPEAN WORKSHOP ON CASE-BASED REASONING, EWCBR,1., 1993. Advances in Case-Based Reasoning: proceedings. Berlin: Springer-Verlag, 1993. p. 274-288. Wess. Disponível em: <http://www.iiia.csic.es/People/enric/AICom.html>. Acesso em: 19 dez 2003.

AAMODT, A.; PLAZA, E. Case-Based Reasoning: Foundational Issues, Methodological Variations, and System Approaches. Artificial Intelligence Communications, Trondheim: University of Trondheim ,1994, p 7, 39-59. Disponível em: <http://www.iiia.csic.es/People/enric/AICom.html>. Acesso em: 19 dez 2003.

AHA, D. In: AIRIES ’94 WORKSHOP, Case-based reasoning. Biloxi, MS, 1994. Disponível em: <http://www.aic.nrl.navy.mil/~aha/>. Acesso em: 19 dez. 2003.

BRANTING, K. Exploiting the Complementarity of rules and precedents with reciprocity and fairness. In: PROCEEDINGS WORKSHOP ON CASE-BASED REASONING, DARPA, 1., 19991. CASE-BASED REASONING, Washington, 1991. Disponível em: <http://www.karlbranting.net/pubs.html>. Acesso em: 19 dez. 2003.

BRUNINGHAUS, S.; ASHLEY, K. D. Improving the Representation of Legal Case Texts with Information Extraction Methods. Pittsburgh: University of Pittsburgh, 2001.

GRUPE, F. H. Case-based Reasoning: applying past experience to new problems. Information Systems Management, Tennessee, p. 10, n. 2, 1993.

KOLODNER, J. Case-Based Reasoning. Los Altos, CA: Morgan Kaufmann, 1993. Disponível em: <http://www.cc.gatech.edu/aimosaic/faculty/kolodner.html>. Acesso em: 19 dez. 2003.

LEE, R. W. CBR Course Home Page. 1998. Disponível em: <http://www.eps.ufsc.br/~martins/fuzzy/cbr.html>. Acesso em: 19 dez. 2003.

QUATRANI, T. Modelagem Visual com Rational Rose 2000 e UML. Rio de Janeiro: Ciência Moderna, 2001.

RIESBECK, C.K.; SCHANK, R.C. Inside Case-Based Reasoning, Hillsdale, NJ, Erlbaum, 1989. Disponível em: <http://www.das.ufsc.br/~sumar/Where%27s_the_AI.html>. Acesso em: 19 dez. 2003.

45

SCHMITZ, C. ; BETTY, Z.; WISSEN, G. Knowledge Flow Management. Duesseldorf: Metropolitan Verlag, 1996. Disponível em: <http://www.bettyzucker.ch/de/schaufenster/bibliothek.html>. Acesso em: 19 dez. 2003.

SCHREIBER, G. at al. Knowledge Engineering and Management: The CommonKADS Methodology. Cambridge: MIT Press, 1999.

SETZER, V.W. Os Meios Eletrônicos e a Educação: uma visão alternativa. São Paulo: Ed. Escrituras, 2001.

STOTTLER, R. H. CBR for Cost and Sales Prediction. AI Expert, San Francisco, v.2, n.15, p. 25-33, 1994. Disponívei em: <http://www.stottlerhenke.com/papers/IITSEC-03-auto-aar.pdf>. Acesso em: 19 dez. 2003.

TUCKER, M. Dark Matter of Decision Making, Intelligent Enterprise, v. 2, n. 13, p. 20-26, Sept. 1999. Disponível em: <http://www.informal.com.br/noticias/gc/n26091999010.html>. Acesso em: 19 dez 2003.

TULVING, E. Elements of Episodic Memory. Oxford: Oxford University, 1983. Disponível em: <http://www.bbsonline.org/Preprints/OldArchive/bbs.aggleton.html>. Acesso em: 19 dez. 2003.

WANGENHEIM, C. G. Von ; WANGENHEIM, A Von. Raciocínio Baseado em Casos. Curitiba: Ed. Manole, 2003. v. 1. p 296,

WATSON, I. Case-based reasoning development tools: a review, 1991. Disponível em: <http://www.salford.ac.uk/survey/staff/IWatson/cbrtools.htm> Acesso em: 19 dez. 2003.

ZACK, M. H. Managing Codified Knowledge 1999. Disponível em: <http://www.cba.neu.edu/~mzack/articles/kmarch/kmarch.htm>. Acesso em: 19 dez. 2003.