Armazenamento de conhecimento explícito referente ao DFA (Design for Assembly) utilizando regras baseadas em casos

Storage of Design for Assembly (DFA) explicit knowledge according to guidelines based on cases

Armazenamento de conhecimento explícito referente ao DFA (Design for Assembly) utilizando regras baseadas em casos

Storage of Design for Assembly (DFA) explicit knowledge according to guidelines based on cases

Antonio Francisco Savi^I,*; Eduardo Vila Gonçalves Filho^II; Erika Monteiro de Souza e Savi^III

^[e-mail], USP, Brasil

^[e-mail], USP, Brasil

^[e-mail], USP, Brasil

RESUMO

Uma importante fonte de vantagem competitiva para muitas organizações no mundo é a capacidade de criar projetos de produtos menos complicados, compostos por um número pequeno de partes e de fácil montagem, sem deixar de atender às expectativas do consumidor, denominada abordagem de DFA - Design for Assembly (Projeto para Montagem). Existe uma dificuldade de catalogar essas abordagens, mais especificamente, não existem regras para o seu armazenamento, e a consequência é a ineficácia na recuperação desse conhecimento explícito. O objetivo desta pesquisa é caracterizar as regras de armazenamento a respeito de informações de DFA com base em casos (RBC - Raciocínio Baseado em Casos), por meio do tipo qualitativo, com propósito exploratório-descritivo. Observa-se que RBC ressalta a possibilidade de armazenar conhecimento explícito ordenadamente, resultando com isso maior eficácia na sua recuperação e, consequentemente, a diminuição do número de informações dispensáveis.

Palavras-chave: Gestão do Conhecimento. DFA (Design for Assembly). Raciocínio baseado em casos.

ABSTRACT

An important source of competitive advantages for many organizations worldwide is the capacity to create designs for less complicated products, consisting of a small number easily assembled parts which, nonetheless, satisfy consumers' expectations, known as the Design for Assembly (DFA) approach. There is an obstacle in cataloguing these approaches, specifically, a lack of storage guidelines; consequently, the retrieval of this explicit knowledge is ineffective. The aim of this study is to identify storage guidelines for DFA information based on previous cases (CBR - Case-based reasoning), qualitative in kind and with a descriptive-exploratory purpose. It is noted that CBR highlights the possibility of explicit knowledge stored in an orderly manner, resulting in more efficient retrieval and a decrease in the amount of irrelevant information.

Keywords: Knowledge Management. Design for Assembly (DFA). Case-based Reasoning.

1. Introdução

As organizações de hoje enfrentam cada vez mais um ambiente dinâmico, convivendo com altas taxas de inovação tecnológica e um elevado nível de competitividade. Para enfrentar estes desafios, é necessário que se mantenham em permanente melhoria, operando dinamicamente conforme a evolução tecnológica no seu ramo de atividade.

Um estudo do McKinsey Global Institute (2006) cita que uma importante fonte de vantagem competitiva para muitas organizações no mundo é a capacidade de criar projetos de produtos menos complicados, ou seja, compostos por um número pequeno de partes e de fácil montagem, sem deixar de atender às expectativas do consumidor. Essa preocupação com o projeto do produto justifica-se à medida que se percebe que projetos bem pensados podem levar ao aumento da lucratividade da organização.

Existe uma abordagem para facilitar o projeto do produto chamado de DFX (do inglês: Design for Excellence), baseada no conhecimento que visa desenvolver projetos de produtos que maximizem todas as características.

Como algumas das variáveis incluídas na excelência do produto é a sua facilidade de ser manufaturado (manufaturabilidade) e de montagem, surgem o DFM (Design for Manufacturability) e o DFA (Design for Assembly) como parte da abordagem DFX. O objetivo principal dessas duas partes do DFX é revisar o projeto do produto facilitando a fabricação e montagem com o escopo de reduzir custos. Estima-se que 50% do custo de manufatura, segundo Boothroyd, Dewhurst e Knight (2001), estão relacionados ao processo de montagem. Grandes investimentos são necessários para automatizar a montagem de produtos complexos, quando seria muitas vezes mais econômico reprojetar o produto para simplificar a montagem.

Para o reprojeto do produto ou para reduzir o custo do projeto de novos produtos com foco nessa abordagem, é necessário ter acesso à informação. Essa informação pode estar muitas vezes armazenada em locais de difícil acesso em uma comunidade, como: nas pessoas, livros, artigos, e nas mais variadas formas de repositórios do conhecimento (NONAKA, 1994).

Para o armazenamento dessas abordagens citadas anteriormente poderiam ser utilizados quaisquer bancos de dados, mas o elevado número de informações e variáveis é uma barreira para uma busca eficiente.

Deste modo, o objetivo do projeto é desenvolver regras de armazenamento de informações baseadas em casos, mais especificamente, resolver um novo problema relembrando uma situação anterior similar e, desse modo, reutilizar a informação e o conhecimento daquela situação. Sendo assim, o repositório de informações seguirá regras de armazenamento que facilitarão sua busca.

A seção 2 descreve a base conceitual necessária para o entendimento do trabalho em questão, demonstrado na seção 4. A seção 3 mostra o método utilizado no desenvolvimento do trabalho seguido dos resultados na seção 5 e, por último, as referências bibliográficas (seção 6).

2. Revisão teórica

2.1. Gestão do conhecimento: conceitos básicos

Gestão do Conhecimento (Knowledge Management) é uma disciplina emergente que tem como principais objetivos criar, registrar e compartilhar o capital intelectual das organizações. O conceito de conhecimento aplicado ao trabalho não é novo, frases contendo a palavra conhecimento, tais como bases de conhecimento e engenharia do conhecimento, existiam antes da gestão do conhecimento se tornar popular. Muitas empresas de softwares se empenharam em desenvolver sistemas relacionando atividades de ensino, captura e reuso de experiências adquiridas, mas nunca usaram a expressão "Gestão do Conhecimento". A comunidade de inteligência artificial, por exemplo, tem uma longa dedicação com a representação do conhecimento, armazenamento e aplicação.

O foco da gestão do conhecimento incide sobre o indivíduo, como um especialista e como um portador do importante conhecimento que pode ser sistematicamente compartilhado com a organização. Nesse sentido, segundo Rus e Lindvall (2002), o conceito de Gestão do Conhecimento apareceu em meados de 1980 da necessidade de se diferenciar conhecimento de informação e era principalmente usado como um termo de business world.

O uso de gestão do conhecimento tem crescido rapidamente desde a década de 90: 80% das grandes corporações globais possuem projetos relacionados com Gestão do Conhecimento e 40% das empresas que aparecem na Revista Fortune 1000 (2006) possuem profissionais especializados em conhecimento. Os CKOs (Chief Knowledge Officer) são executivos seniores que criam a infraestrutura e a cultura da empresa para o compartilhamento do conhecimento (RUS; LINDVALL, 2002).

O conceito de conhecimento pode não ser consensual. A história da filosofia, desde o período clássico grego, está associada a uma busca para o significado do conceito de "conhecimento". Neste trabalho, não será seguida a epistemologia para adotar uma definição de conhecimento, um ramo da Filosofia que trata especificamente do estudo da ciência. Nonaka (1994) afirma seguir este significado tradicional e adota uma definição do conhecimento como sendo "uma crença justificadamente verdadeira".

Segundo Soffner (2002), conhecimento é o recurso-chave das tomadas de decisão inteligentes, previsões, projetos, planejamentos, diagnósticos, análises, avaliações e julgamentos intuitivos. É criado e compartilhado entre mentes individuais e coletivas. Não surge de bancos de dados, mas da experiência, sucessos, falhas e aprendizagem. Desta forma, o conhecimento está nas pessoas e não nos sistemas computacionais.

Sanches, Heene e Thomas (1996) entendem o conhecimento como o conjunto de crenças mantidas por um indivíduo acerca de relações causais entre fenômenos, entendendo relações causais como sendo relações de causa e efeito entre eventos ou ações imagináveis e prováveis consequências para aqueles eventos ou ações.

A manifestação de Grant (1996) acerca do assunto concentra-se na afirmação de que a definição de conhecimento é discutida desde os primórdios dos tempos. Existem muitas definições de vários autores cada qual focando a definição de conhecimento em sua área. É preciso, entre essas várias definições, encontrar uma que se adapte ao foco do trabalho em questão. A definição do conhecimento adotada neste trabalho é a de Davenport e Prusak (1998): conhecimento é uma mistura fluida de experiências, valores, informação contextual e intuição, formando um framework (um "cenário") na mente de uma pessoa que a habilita a interpretar, avaliar e tomar decisões acerca de casos, experiências e/ou informações. Os referidos autores ainda diferenciam duas grandes classes de elementos relacionados com conhecimento dentro das empresas. São eles:

• Dado: é um conjunto discreto e objetivo de fatos sobre um determinado evento. É, portanto, a parcela quantificável e objetiva do estoque de informação e conhecimento de uma empresa e está armazenado em bancos de dados ou documentos da empresa; e

• Informação: é uma mensagem contendo um emissor e um receptor e cujo significado envolve uma nova interpretação de algo, baseado em um conjunto de dados. Como, por exemplo: conforme um valor de temperatura e pressão atmosféricas podemos inferir que deverá chover amanhã, portanto, tem-se uma informação a respeito do clima. Dentro de qualquer empresa há um complexo e contínuo fluxo de informações, seja por meios tecnológicos como sistemas computacionais ou simplesmente através da interação entre as pessoas.

E qual é a relação entre conhecimento, informação e dados? Todas as características do conhecimento podem ser suportadas pela disponibilidade da informação e dos dados. Assim entram a tecnologia da informação, os bancos de dados, livros, manuais, documentos e apresentações. Apenas uma ínfima parte do conhecimento pode estar armazenada nestes meios, a maior parte está na cabeça das pessoas (SOFFNER, 2006).

Segundo Terra (2002), também não há uma definição padrão sobre gestão do conhecimento, nem um esquema universal dentro do qual se possa alinhar diferentes profissionais.

Diante desse contexto, este trabalho adotou a definição de Loughbridge (1996), que expõe que a gestão do conhecimento pode ser definida como a aquisição, troca e uso do conhecimento dentro das organizações, incluindo os processos de aprendizado e os sistemas de informação, requerendo a transformação do conhecimento pessoal em conhecimento corporativo de forma a ser compartilhado e apropriadamente aplicado, sendo sua sistematização vital às organizações.

O objeto de estudo no qual se apoia a gestão do conhecimento é composto basicamente pelo conhecimento tácito e explícito, amparado em bases individuais e coletivas. A criação do conhecimento se refere a um processo reflexivo que envolve o pensamento racional e o empírico, a mente e o corpo, a análise e a experiência, o implícito e o explícito (NONAKA; TAKEUCHI, 1997). Tais autores realizaram essa importante distinção entre dois tipos de conhecimento, também chamados de Categorias de Conhecimento, elencados abaixo:

• Tácito: pessoal, conteúdo-específico, difícil de formalizar, registrar ou articular; nas pessoas. Desenvolvido por tentativa e erro da prática.

• Explícito: pode ser codificado e transmitido em linguagem formal e sistemática: documentos, bancos de dados, Web, e-mails, gráficos, etc.

Assim, a Gestão do Conhecimento permite a criação, comunicação e aplicação de conhecimento de todos os tipos, a fim de atingir metas e objetivos traçados para a organização. O conhecimento tácito dificilmente pode ser externalizado, ou seja, passado para explícito, já que é afetado por modelos mentais e outras barreiras (NONAKA; TAKEUCHI, 1997).

Segundo Amaral (2001), existe ainda uma distinção de pesquisas realizadas em gestão do conhecimento. Haveria abordagens centradas no armazenamento ou codificação do conhecimento e outras centradas nas pessoas. Exemplos de trabalhos que fazem esta distinção são Blodgood e Salisbury (2001) e Carayannis(1998). Rubenstein e Montano (2001) argumentam que é um grande desafio gerar uma abordagem para a gestão do conhecimento que considere ambos os aspectos e dimensões do conhecimento. Para auxiliar essa dinâmica, a Tecnologia de Informação (TI) oferece inúmeros recursos tecnológicos e ferramentas. Rus e Lindvall (2002) afirmam que, recentemente, desenvolvimentos em TI têm habilitado compartilhamento de informações.

No entanto, como afirma Carvalho (2000), é importante ressaltar que a TI desempenha um papel de infraestrutura, pois a gestão do conhecimento envolve também aspectos humanos e gerenciais. Davenport e Prusak (1998) asseveram que a gestão do conhecimento é muito mais do que tecnologia, mas é certo que esta faz parte da gestão do conhecimento.

A subseção 2.2 mostra conceitualmente o DFX, mais especificamente o DFA que é foco do trabalho.

2.2. DFX (Design for Excellence)

As necessidades do cliente atreladas às especificações do projeto levam a um conceito do produto requerido, acarretando no incremento de um projeto. Da dificuldade de unir esses dois primeiros requisitos (necessidades do cliente e especificação do projeto) surgiu o DFX (Design for Excellence), no qual o X são critérios de qualidade tais como: confiabilidade, robustez, eficiência, impacto ambiental, montagem ou manufaturabilidade.

Como, uma das variáveis incluídas na excelência do produto é sua manufaturabilidade, isto é, sua facilidade de ser manufaturado, surgiu o DFM. Entende-se DFM como Design for Manufacturability (Projeto para a Manufaturabilidade ou Projeto para a Manufatura). E define-se DFM como uma técnica baseada no conhecimento que evoca uma série de orientações, princípios, recomendações ou regras para o projeto de um produto de forma a facilitar sua fabricação (BRALLA, 1996).

Na prática, o primeiro passo no estudo do DFM é estimar os custos de manufatura. Esforços devem ser feitos no sentido de reduzir custos de componentes, custos de montagem e custos de sistemas de apoio à produção. A equipe de projeto, então, deve considerar os impactos das decisões tomadas com o objetivo de diminuir os custos de manufatura sobre fatores como: tempo de desenvolvimento, custo de desenvolvimento, qualidade dos produtos e outros fatores externos. Com estes dados em mãos, os custos de manufatura são recalculados e é possível concluir se o projeto é bom o suficiente ou não.

A estimativa dos custos de montagem é importante no DFM, pois a montagem é um elemento crucial da fabricação. Estudos sobre os custos de montagem foram e ainda são desenvolvidos por pesquisadores. Dentre tais estudos encontra-se o DFA - Design for Assembly (Projeto para Montagem). O DFA é um subconjunto do DFM que envolve a redução máxima dos custos de montagem (ULRICH e EPPINGER, 1995).

A maximização da facilidade de montagem é ligada diretamente com a redução do custo de montagem. Podem-se fazer as seguintes perguntas durante o projeto do produto para a determinação do número mínimo de peças:

1. Existe necessidade de movimento relativo entre as partes?

2. Existe necessidade de especificação de diferentes materiais por razões físicas/químicas?

3. O componente deve ser desmontável para facilitar a manutenção?

Como exemplo, os seguintes processos podem ser considerados para a obtenção da facilidade de montagem:

• Partes não precisam ser orientadas: peças que precisam de orientação, como parafusos, requerem mais tempo de montagem (Figura 1); e

• Orientação para Montagem: assimetria (Figura 2).

Além desses métodos de montagem existem vários outros citados na literatura. Com a aplicação dessas técnicas podem existir vários benefícios tais como:

• Em relação a custo, tem-se a diminuição do custo de suporte;

• Com a redução do número de partes, a demanda de gerenciamento de inventário é reduzida;

• Com a redução da montagem, diminui o número de trabalhadores na produção, reduz o custo da supervisão e gerenciamento de recursos humanos; e

• A padronização de componentes reduz a demanda de engenheiros de suporte e controle de qualidade.

A subseção 2.3 demonstra um conceito que apoia a recuperação de informações relacionadas à abordagem DFA, que é o Raciocínio Baseado em Casos.

2.3. Raciocínio baseado em casos

O RBC - Raciocínio Baseado em Casos (Case-Based Reasorning (CBR)) estabeleceu-se nos últimos anos como uma das tecnologias disseminadas para o desenvolvimento de Sistema Baseado em Conhecimento. É uma abordagem para a solução de problemas e para o aprendizado com base em experiência passada. De uma forma simplificada, podemos entender RBC como a solução de novos problemas por meio da utilização de casos anteriores já conhecidos. Um novo problema que nos é apresentado é resolvido com a reutilização da solução de um problema anterior parecido com o atual. Esta solução pode ser aplicada em sua totalidade ou de forma parcial no novo problema, podendo ainda ser modificada de acordo com os requisitos da nova situação.

Assim, pode-se definir RBC como um enfoque para a solução de problemas e para o aprendizado baseado em experiência passada. RBC resolve problemas ao recuperar e adaptar experiências passadas - chamadas casos - armazenadas em uma base de casos. Um novo problema é resolvido com base na adaptação de soluções de problemas similares já conhecidas (WANGENHEIM; WANGENHEIM, 2003).

Para Watson e Marir (1994), o estudo de raciocínio baseado em casos tem seu marco inicial no trabalho de Schank e Abelson (1977), no qual a proposição traz a concepção do conhecimento geral sobre as situações é registrado na forma de scripts . Os scripts descrevem sequências de passos ou etapas em que permite antecipar como os acontecimentos devem se suceder e realizar inferências a partir dessa expectativa. Os scripts são propostos como uma estrutura para a memória conceitual descrever informações sobre eventos estereotipados, como ir a um restaurante ou ir ao médico. Os experimentos mostraram, no entanto, que os scripts não podiam ser considerados como um modelo completo de representação da memória, uma vez que uma pessoa pode "lembrar-se" de scripts que são compostos por pedaços de diferentes sequências de eventos, mais especificamente, lembrar-se de algo que na verdade foi criação de sua mente. Outros mecanismos podem atuar na formação da memória e são explicados por teorias da Filosofia e Psicologia de solução de problemas, formação de conceitos e aprendizado experimental, como por exemplo, a teoria da memória dinâmica de Schank (1977), que foi uma das importantes contribuições para o desenvolvimento da pesquisa na área. A teoria baseou-se na ideia de que não é possível separar experiência, compreensão, memória e aprendizado e propôs o conceito de pacotes de organização de memória ou MOPs (Memory Organization Packets), que utilizam a lembrança de experiências passadas associadas a estereótipos de situações para a solução de problemas e aprendizado. Paralelamente ao trabalho de Schank, Gentner (1983) desenvolveu uma estrutura teórica para o raciocínio por analogia que foi importante para o desenvolvimento de RBC.

Embora raízes filosóficas da teoria de RBC possam se espalhar por trabalhos de diversos pesquisadores no campo da Psicologia ou Ciência da Computação, foram, sem dúvida, os trabalhos do grupo de Schank, na Universidade de Yale (2006), no início dos anos 80, que produziram o modelo cognitivo de RBC e as primeiras aplicações baseadas nesse modelo.

O RBC também é usado extensivamente para raciocínio de senso comum no dia a dia. Quando pedimos uma refeição em um restaurante, nos baseamos em outras experiências que tivemos para tomar decisões sobre o que deve ser bom. Como também, quando planejamos nossas atividades domésticas, nos lembramos o que funcionou e o que falhou e usamos isso para criar nossos planos.

Em 1986, um trabalho alternativo foi desenvolvido na Universidade do Texas, utilizando recursos de classificação heurística e aprendizado de máquina para unificar em um modelo o conhecimento genérico do domínio e o conhecimento específico de casos. O resultado foi o sistema PROTOS com seu modelo de memória de casos (PORTER; BAREISS, 1986). Modelos como esse unificam conhecimento genérico e episódico e têm influenciado grandemente os sistemas de RBC, uma vez que o conhecimento do domínio pode melhorar a qualidade do raciocínio, encurtar o caminho de busca da solução ou mesmo preencher lacunas do espaço do problema que os casos naturalmente não cobririam.

A seção 3 descreve a metodologia utilizada para o desenvolvimento deste trabalho.

3. Método

Para atingir o objetivo proposto e responder à pergunta de pesquisa estabelecida para este trabalho, é empregada metodologia de pesquisa e é classificada, segundo Dane (1990), como pesquisa de campo do tipo participante-observador.

Ainda, segundo Dane (1990), pesquisa de campo é um rótulo que pode ser atribuído a uma coleção de métodos de pesquisa que envolve a observação direta de ocorrências de eventos naturais. A pesquisa de campo, do tipo participante-observador, tem como características o conhecimento dos participantes de que se trata de um pesquisador e que o mesmo influencia e participa diretamente nas ações do fenômeno.

Em relação à abordagem de levantamento e manipulação dos dados é possível classificar uma pesquisa em quantitativa ou qualitativa (SILVA; MENEZES, 2000). Gil (1991) diz que esse tipo de pesquisa, geralmente é de natureza qualitativa, por se tratar de uma amostra intencional, em que indivíduos são selecionados a partir de certas características tidas como relevantes pelos pesquisadores e participantes, que é o caso deste trabalho.

Para o desenvolvimento de uma integração em áreas tão complexas deve haver um grande equilíbrio entre a fundamentação teórica e a experiência prática.

A seção 4 descreve como as regras do Raciocínio Baseado em Casos (RBC) podem auxiliar na prática do uso de abordagens de montagens (DFA).

4. Regras para armazenamento de informações de DFA (Design for Assembly) baseada em casos (RBC)

4.1. Contextualização

Há atualmente um conjunto grande de informações a respeito de técnicas de DFA distribuídas em várias formas de armazenamento: ferramentas, livros, artigos, pessoas, etc. Deste modo, cada uma dessas formas de armazenamento possui informações diferentes, já que existem diferentes autores, boas e más práticas de aplicação, práticas que só se aplicam sob um determinado ambiente. Mais especificamente, as informações estão descentralizadas, o que causa carência de informação na organização. Uma forma de organizar essa descentralização incorre na realização de um conjunto de atividades dedicadas a garantir e incentivar a criação, registro e compartilhamento do conhecimento, a denominada Gestão do Conhecimento (GC).

Nesse ínterim , incide o enfoque deste trabalho, que compõe a ideia básica de como trabalhar com o conhecimento a respeito de práticas de DFA, armazená-lo e reutilizá-lo. A GC fornece o que é o conhecimento e as formas básicas de armazenamento. A problemática é constituída na capacidade de recuperação do conhecimento armazenado, pois muitas organizações desconhecem ou pouco sabem acerca do conhecimento que possuem. Tal fato, muitas vezes, não advém da ausência de uma política de gestão do conhecimento, mas sim da omissão de regras para o seu armazenamento, tornando a recuperação do conhecimento retido complexa e repleta de dificuldades. Assim, apresenta-se o questionamento, de qual a melhor forma de armazená-lo? Existe algum tipo de regra que auxilie no armazenamento do conhecimento de práticas de DFA?

O RBC pode fornecer a resposta a essa pergunta, pois um grande número de exemplos da vida diária pode ser utilizado para demonstrar como os seres humanos utilizam casos conhecidos na resolução de problemas de um modo extremamente natural. Alguns exemplos de Wangenheim e Wangenheim (2003) merecem ser destacados:

Ao atender um novo paciente e escutar seus problemas, o médico lembra-se do histórico da doença de um outro paciente devido ao conjunto similar de sintomas e aplica-lhe um tratamento semelhante ao que administrou ao paciente que apresentou aqueles sintomas similares:

Os problemas apresentados nos ouvidos do paciente são parecidos como um caso típico de otite média. Assim vou administrar-lhe um tratamento para otite média.

Um técnico de serviço de um determinado tipo de aparelhos lembra-se de um defeito similar no tipo de máquina que está tentando consertar: "Esta TV tem os mesmos problemas de uma que eu consertei na semana passada, então vou trocar as válvulas de saída de áudio."

Um profissional jurídico reforça seus argumentos com jurisprudências semelhantes: "Esse caso deve ser decidido como no caso Santos versus de Silva."

Um arquiteto estuda as plantas de um prédio já existente ao planejar uma construção similar: "No passado fiz uma casa de praia com três quartos, na encosta de um morro, vou usar o plano daquele caso como uma base."

Um vendedor relata para um cliente, com necessidades e características semelhantes às de um cliente anterior, fatos sobre a venda com sucesso de um determinado produto: "Muitos estudantes ficam neste hotel em Porto de Galinhas."

Um projetista de máquinas se depara com a dificuldade de desenhar certo eixo para uma máquina específica: "Este eixo é semelhante ao eixo da máquina X, que vi nos arquivos do sistema na semana passada."

Todas essas situações têm em comum o fato de que uma solução para um problema obtida no passado foi reutilizada para guiar a solução do problema da situação presente. Assim sendo, para continuar demonstrando como o RBC pode auxiliar o trabalho com abordagens DFA, faz-se necessário revelar os elementos básicos de um sistema desse tipo, que, portanto, serão descritos na próxima subseção (4.2).

4.2. Os elementos básicos de um sistema de RBC

A forma principal de representação de conhecimento em um sistema RBC é o caso. Este caso é uma peça de conhecimento contextualizado que registra um episódio em que um problema ou situação problemática foi total ou parcialmente resolvido.

Os elementos básicos de um sistema de raciocínio baseado em casos são:

Representação do conhecimento: em um sistema de RBC, o conhecimento é representado principalmente em forma de casos que descrevem experiências concretas. No entanto, se for necessário, também outros tipos de conhecimento sobre o domínio de aplicação podem ser armazenados em um sistema de RBC, por exemplo, casos abstratos e generalizados, tipos de dados, modelo de objetos usados como informação.

Medida de similaridade: a capacidade de encontrar um caso relevante para o problema atual na base de casos e de responder à pergunta quando este for relembrado, devido à sua similaridade ao novo problema.

Adaptação: situações passadas representadas como casos dificilmente serão idênticas às do problema atual. Sistemas de RBC avançados têm mecanismos e conhecimento para adaptar os casos recuperados completamente, para verificar se satisfazem às características da situação presente.

Aprendizado: para que um sistema se mantenha atualizado e evolua continuamente, sempre que ele resolver um problema com sucesso, deverá ser capaz de lembrar dessa situação no futuro como mais um caso.

A representação do conhecimento é um aspecto tão importante do RBC que se pode demonstrar adiante. Um caso representa tipicamente a descrição de uma situação (problema) conjuntamente com experiências adquiridas (solução) durante sua resolução. A essa associação dos dois conjuntos de informações, demonstra-se: a descrição do problema e a respectiva solução. Deste modo, os casos podem, exemplificadamente, representarem:

• O conjunto de sintomas de um paciente e os passos de um tratamento médico;

• A descrição dos sintomas dos defeitos técnicos apresentados por um equipamento e da estratégia de conserto aplicada;

• Os objetivos de um processo legal e a respectiva jurisprudência;

• A descrição de um pacote de viagem; e

• A descrição de abordagens de montagem e suas respectivas técnicas demonstradas passo a passo.

O caso pode também conter outros itens, como efeito de aplicação da solução ou a justificativa para aquela solução e sua respectiva explicação (KOLODNER, 1993). Pode ainda ser enriquecido por informações relevantes, como as tratadas em gestão do conhecimento, mais especificamente, dados administrativos, melhores práticas ou fóruns realizados para resolver determinado problema.

Conforme exposto, casos contêm experiências concretas, vividas em uma situação específica. No entanto, podemos também criar casos abstratos, que realizam a subsunção de experiências adquiridas em um conjunto de situações (BERGMANN, 1998).

A recuperação de casos similares é de muita ajuda para a resolução de casos novos. A subseção a seguir (4.3) descreve o conceito de similaridade.

4.3. O conceito de similaridade

O objetivo do RBC é a reutilização de soluções conhecidas no contexto de um problema novo, de solução ainda conhecida. Em função disso, a determinação de exemplos de casos adequados, que não precisam, necessariamente, ser idênticos à situação atual, é um dos problemas centrais desta técnica.

O conceito de similaridade de casos é útil, de um ponto de vista abstrato. Durante a recuperação de casos procura-se por um exemplar na base de casos, que, no contexto da descrição do problema atual, é útil para determinar a sua solução.

É difícil definir exatamente o que significa um caso ser útil para solucionar um determinado problema, como a utilidade deveria ser medida ou o que torna um determinado caso mais apropriado para solucionar um problema do que outro. Em especial, a adequação de um caso para solucionar determinado problema pode ser apontado com alto grau de segurança, pois somente após a tentativa de elaboração de um desfecho para este problema no caso escolhido. Esta forma de determinação de utilidade, porém, em que um sistema constrói soluções hipotéticas a partir de todos os casos armazenados na base e depois determina qual a melhor para aplicá-la, é impraticável. Portanto, é necessário um método heurístico para analisar um caso e julgar sua utilidade sem realizar todo o trabalho de tentar construir uma solução a partir dele e tentar aplicar essa solução, até porque, em muitos casos, como em diagnósticos, realizar isto não é possível.

Uma das hipóteses básicas de sistemas de RBC trata-se de um problema de similares que possuem soluções similares. Com base nesta hipótese, o critério a posteriori da utilidade de soluções passa a ser reduzido ao critério a priori similaridade de descrições de problema. Esta forma de se proceder é justificada pela premissa de que, em muitas aplicações, a similaridade de definições de problemas implica a aplicabilidade da solução de um sobre o outro. Portanto a solução descrita em um exemplo de caso escolhido pode ser útil para um novo problema, em que:

• Permita a solução do problema atual de alguma forma;

• Evite a repetição de um erro anterior;

• Permita uma solução eficiente do problema, que seja mais rápido do que, por exemplo, utilizar uma heurística passo a passo para calcular uma solução;

• Ofereça a melhor solução para o problema de acordo com um critério qualquer; e

• Ofereça ao usuário uma solução cuja lógica possa ser compreendida por ele.

O enquadramento de uma solução análoga para um caso, acontece na minimização da necessidade de alterações no intuito de adaptá-lo ao problema atual. Desta maneira, o objetivo da determinação da utilidade de casos para um problema atual é o de se determinar uma relação de preferência baseada no critério de similaridade. Esta relação de preferência serve para determinar uma ordem parcial sobre os casos da composição de sua base em relação à utilidade destes casos para o problema particular que o sistema de RBC está tentando resolver. Em suma, é possível afirmar que, para a determinação da similaridade em um sistema de RBC, as seguintes premissas têm de ser satisfeitas (BURKHARD, 1998):

• A similaridade entre a questão atual e o caso implica utilidade;

• A similaridade é baseada em fatos a priori; e

• Como casos podem ser mais ou menos úteis em relação a uma questão, a similaridade precisa prover uma medida.

De acordo com a última subseção do parágrafo anterior a similaridade precisa prover uma medida, é isso que descreve a subseção a seguir (4.4).

4.4. Recuperação de casos

O objetivo da recuperação de casos é encontrar um ou um pequeno conjunto destes na base de casos que contenha uma solução útil para o problema ou situação atual. Exemplificando: dada a descrição de um problema de montagem com um eixo de um produto, um sistema de RBC deveria ser capaz de recuperar um caso descrevendo uma solução apropriada ao problema (mostrar o desenho de um eixo com os dois lados iguais).

Para realizar essa recuperação, é necessário "casar" a descrição do problema atual com os problemas armazenados na composição da base, aplicando uma medida de similaridade. Vários enfoques diferentes são aplicados para a realização do processo de correspondência consulta-casos na base, a fim de recuperar um conjunto de casos úteis. É necessário discutir primeiramente os princípios gerais por detrás da recuperação de casos. O processo de recuperação de casos pode ser formalmente descrito por meio de um conjunto de subtarefas que devem ser realizadas pelo sistema RBC:

Assessoramento da situação, objetivando a formulação de uma consulta representada por um conjunto de descritores relevantes da situação ou problema atuais;

Casamento, objetivando a identificação de um conjunto de casos suficientemente similares à consulta; e

Seleção, que escolhe o melhor casamento ou casamentos como base no conjunto de casos selecionado.

O assessoramento da situação é a mais complexa das três subtarefas da recuperação, pois utiliza conhecimento e, muitas vezes, exige uma interação pró-ativa com o usuário. Para encontrar uma solução adequada ao problema proposto, temos de "casar" nosso problema com os problemas armazenados na base de casos. Problemas do mundo real, no entanto, são muitas vezes mais complexos, apresentando inúmeras características essenciais. O problema atual pode não se apresentar exatamente da mesma forma que um problema sugerido, com semântica equivalente ao armazenado na base de dados. Por isso, durante o processo de recuperação de casos, a meta é recuperar casos potencialmente úteis para a situação presente. Todavia, é comum encontrar casos que são os mais similares à nova situação ao longo de dimensões consideradas importantes no contexto da aplicação. A situação ou problema atual deve ser descrito como entrada para o processo de recuperação, especificando o objeto de busca. Isto é realizado por meio de uma consulta relacionando descritores de entrada - índices que são relevantes para se encontrar a solução adequada, como sintomas ou características do produto a ser consertado. Esses descritores devem ser elaborados como a entrada do processo de recuperação, que ocorre durante o assessoramento da situação.

Diante do contexto anteriormente mencionado, questionam-se quais descritores de entrada serão importantes? A resposta incorre na sujeição do domínio de aplicação específica do sistema de RBC, por exemplo:

Quando um médico está buscando pelo diagnóstico de uma doença, ele caracterizará o paciente - idade: 35 anos; sexo: masculino; doenças prévias: malária - e descreverá seus sintomas atuais, por exemplo, dor no peito, febre;

Quando um técnico de serviço está consertando uma impressora e está procurando a causa do problema presente, ele caracterizará a impressora - marca: HP^®; modelo: 555 - e descreverá o sintoma atual, por exemplo, a impressora não funciona;

Quando procuramos por uma receita de como preparar uma refeição, podemos tentar encontrá-la com base no nome do prato, por exemplo: lasanha de carne.

A identificação de quais descritores é relevante para a solução do problema atual é um dos maiores fatores de complexidade de um sistema de RBC. A diminuição dos fatores que necessitam ser considerados proporciona o aumento do índice de eficiência do sistema.

A seção seguinte relata a técnica utilizada a partir de um conjunto de casos para fazer uma escolha melhor.

4.5. Técnica de escolha

Inicialmente, considerando o conjunto de casos similares, a escolha considerada melhor é realizada. Isto pode ter sido desempenhado durante o processo de casamento (descrito anteriormente). Contudo, geralmente um conjunto de casos é retornado por essa tarefa. O caso que melhor satisfaz a consulta ou é mais útil para a solução é escolhido por meio da avaliação do grau de casamento ou similaridade de forma mais detalhada. Isto pode ser realizado como uma tentativa de gerar explicações para justificar atributos não idênticos, com base em conhecimento do domínio de aplicação.

Se um casamento demonstra ser forte o suficiente, uma tentativa de se encontrar um casamento melhor pode ainda ser realizada. Por exemplo: a exploração das diferenças com os outros casos do conjunto retornado. Se esta tentativa falha, tem-se uma evidência adicional da adequação do caso escolhido.

O processo de seleção gera, tipicamente, implicações e perspectivas para cada caso recuperado e tenta avaliar consequências e justificar expectativas. Isto pode ser realizado com o uso do conhecimento do modelo de conhecimento do domínio do próprio sistema ou com a solicitação ao usuário para que confirme escolhas ou forneça informação adicional. Os casos são eventualmente classificados de acordo com alguma métrica ou critério de ordenação.

A técnica mais simples é a recuperação sequencial, na qual a medida de similaridade é calculada sequencialmente para todos os casos na base de dados.

O processo de recuperação sequencial permite a determinação dos m casos mais similares. Para a determinação de uma relação de preferência específica para a situação aplica-se o conceito de similaridade do sistema sucessivamente a cada um dos casos da base de dados. Todos os casos pertencentes à base são então ordenados de acordo com sua similaridade com a consulta. Como resultado, retomam-se então os m casos mais similares. O método de recuperação sequencial é um método de aplicação universal e extremamente fácil de ser implementado para a determinação de casos similares. A principal desvantagem desse método é em relação a bases de dados grandes.

4.6. Exemplo de utilização de casos de uso

Pode-se exemplificar um caso de uso com uma ficha em que se cadastram informações sobre:

• Problemas ou sintomas;

• Solução daquele problema ou sintoma;

• Observações; e

• Um desenho no qual se mostra o "antes" e o "depois" da aplicação da solução.

A Figura 3 retrata o exemplo descrito acima.

Uma base de dados contendo todos os casos existentes em uma empresa pode ser realizada por intermédio de várias técnicas de programação nas quais a busca por casos de uso seria feita das seguintes formas:

• Referenciando o problema e/ou;

• Referenciando o diagnóstico e/ou;

• Referenciando o produto.

Desta forma, abrangem-se todos os tipos de busca que um caso possui. No caso do exemplo proposto, o usuário poderia realizar a busca pelo problema (montagem de eixo). Dentre os vários resultados pode-se refinar a busca por produto. Sendo assim, recupera-se o caso exemplificado, em que é apresentada a solução.

5. Conclusão

Nos dias atuais, o grande problema que as empresas enfrentam em relação ao conhecimento é, predominantemente, a ineficácia de sua recuperação e isto acontece também com a recuperação de conhecimento explícito relacionado com abordagens de DFA: algumas vezes pela quantidade desordenada de conhecimento explícito armazenado sem nenhum tipo de regra ou simplesmente de conhecimento não armazenado que se dispõe na sua forma inicial, como nas pessoas, em livros, etc. Este trabalho mostra uma forma ordenada de armazenamento baseada em regras, ou melhor, em casos que podem ordenar o armazenamento. O RBC nos apontou como é possível guardar conhecimento explícito ordenadamente, resultando numa maior eficácia de recuperação do conhecimento e, consequentemente, diminuir o número de informações dispensáveis. A técnica de recuperação aqui demonstrada é uma das mais simples oferecidas pela RBC. Existem outras mais complexas que podem ser aplicadas em base de dados grandes, no entanto, o intuito deste trabalho não é mostrar uma técnica eficaz na recuperação de conhecimento explícito armazenado, e sim divulgar como isso é possível através do armazenamento correto. E é isso que o RBC nos fornece.

Referências

AMARAL, D. C. Arquitetura para gerenciamento de conhecimentos explícitos sobre processo de desenvolvimento de produto. São Paulo, 2001. 214 p. Tese (Doutorado em Engenharia Mecânica) - Universidade de São Paulo - USP.

BERGMANN, R. On the use taxonomies for representing case features on local similarity measures. In: GERMAN WORKSHOP ON CASE-BASED REASONING, 1998. Proceedings. ..

BOOTHROYD, G.; DEWHURST, P.; KNIGHT, W. Product design for manufacture and assembly. New York: Marcel Dekker, 2001.

BRALLA, J. G. Design for excellence. New York: McGraw-Hill, 1996. 326 p.

BURKHARD, H. D.; HANNEBAUER, M.; WENDLER, J. AT Humboldt: development, practice and theory. London: Springer, 1998. p. 357-372. (Lecture Notes in Computer Science, v. 1395).

CARAYANNIS, E. G. The strategic management of technological learning in project program management: the role of extranets, intranets and intelligent agents in knowledge generation, diffusion, and leveraging. Technovation, v. 18, n. 11, p. 697-703, 1998.

CARVALHO, R. B. Aplicações de softwares de gestão do conhecimento: tipologia e usos. Minas Gerais, 2000. Dissertação (Mestrado em Ciência da Informação) - Universidade Federal de Minas Gerais - UFMG.

DANE, F. C. Research methods. California: Brooks/Cole, 1990.

DAVENPORT, T. H.; PRUSAK, L. Conhecimento empresarial: como as organizações gerenciam seu capital intelectual. Rio de Janeiro: Campus, 1998.

GENTNER, D. Structure mapping: a theoretical framework for analogy. Cognitive Sciense, v. 7, n. 2, p. 155-170, 1983.

GIL, A. C. Como elaborar projetos de pesquisa. São Paulo: Atlas, 1991.

GRANT, R. M. Toward a knowledge-based theory of the firm. Strategic Management Journal, v. 17, p. 109-122, 1996.

KOLODNER, J. L. Case-Based Reasoning. San Francisco: Morgan Kaufmann, 1993.

LOUGHBRIDGE, M. E. D. Intellectual capital and knowledge management. IFLA Journal, v. 22, n. 4, p. 299-301, 1996.

Mckinsey and Company. Disponível em: <http://www.mckinsey.com/>. Acesso em: Abril 2006.

NONAKA, I. A dynamic theory of organizational knowledge creation. Organization Science, v. 5, n. 1, p. 14-37, 1994.

NONAKA, I.; TAKEUCHI, H. Criação de conhecimento na empresa. Rio de Janeiro: Campus, 1997.

PORTER, B. W.; BAREISS, R. Protos: an experiment in knowledge acquisition for heuristics classification tasks. In: INTERNATIONAL MEETING ON ADVANCES IN LEARNING - IMAL, 1, 1986. Proceedings... France: Les Ares, 1986. p. 159-174.

Revista Fortune. Disponivel em: <http://money.cnn.com/magazines/fortune/>. Acesso em: Outubro 2005.

RUBENSTEIN-MONTANO, B. et al. A systems thinking framework for knowledge management. Decision Support Systems, v. 31, n. 1, p. 5-16, 2001.

RUS, I.; LINDVALL, M. Knowledge managemente in software engineering. IEEE Computer Society Press, v. 19, n. 3, p. 26-27, 2002.

SANCHES, R.; HEENE, A.; THOMAS, H. Towards the theory and pratice of competence-based competition. In: ______. (Ed.). Dinamics of competence-based competition. Oxford: Elsevier, 1996.

SCHANK, R. C.; ABELSON, R. Scripts, plans, goals and understanding. Northvale: Erlbaum, 1997.

SILVA, E. L.; MENEZES, E. M. Metodologia da pesquisa e elaboração de dissertação. Florianópolis: Laboratório de Ensino a Distância da UFSC, 2000.

SOFFNER, R. Curso sobre gestão do conhecimento. Disponível em: <http://www.soffner.eng.br>. Acesso em: Novembro 2002.

TERRA, J. C. C. Portais corporativos: a revolução na gestão do conhecimento. São Paulo: Negócio, 2002.

ULRICH, F. T.; EPPINGER, S. D. Product design and development. New York: McGraw-Hill, 1995.

WANGENHEIM, C. G.; WANGENHEIM, A. Raciocínio baseado em casos. São Paulo: Manole, 2003.

WATSON, I.; MARIR, F. Case-based reasoning: a review. The Knowledge Engineering Review, v. 9, n. 4, p. 327-354, 1994.

Recebido 01/12/2006; Aceito 28/06/2009

*

Escola de Engenharia de São Carlos, USP, São Carlos, SP, Brasil

Datas de Publicação

• Publicação nesta coleção
  12 Fev 2010
• Data do Fascículo
  Mar 2010

Histórico

• Aceito
  28 Jun 2009
• Recebido
  01 Dez 2006