Metodologias da Engenharia do Conhecimento - Aula 2/3

Introdução à Engenharia e Gestão do Conhecimento Aula 5 Prof. Roberto Pacheco Roberto C. dos Santos Pacheco [email_address] Professor UNIVERSIDADE FEDERAL DE SANTA CATARINA Programa de Pós-Graduação em Engenharia e Gestão do Conhecimento Florianópolis, Abril de 2006 Neri dos Santos [email_address] Professor Parte II: Engenharia do Conhecimento: Introdução à Engenharia do Conhecimento Francisco Antonio Pereira Fialho [email_address] Professor

PROGRAMAÇÃO GESTÃO DO CONHECIMENTO SOCIEDADE DO CONHECIMENTO ECONOMIA DO CONHECIMENTO ORGANIZAÇÃO DO CONHECIMENTO ENGENHARIA DO CONHECIMENTO ENGENHARIA DO CONHECIMENTO E INTELIGENCIA ARTIFICIAL METODOLOGIAS DA ENGENHARIA DO CONHECIMENTO EC, GESTÃO E MÍDIA MÍDIA E CONHECIMENTO ESCOLA DO FUTURO ORGANIZAÇÕES DO FUTURO MÍDIAS DO FUTURO UNIVERSIDADE FEDERAL DE SANTA CATARINA Programa de Pós-Graduação em Engenharia e Gestão do Conhecimento Florianópolis, Abril de 2006

ENCONTRO DE HOJE GESTÃO DO CONHECIMENTO SOCIEDADE DO CONHECIMENTO ECONOMIA DO CONHECIMENTO ORGANIZAÇÃO DO CONHECIMENTO ENGENHARIA DO CONHECIMENTO ENGENHARIA DO CONHECIMENTO E INTELIGENCIA ARTIFICIAL METODOLOGIAS DA ENGENHARIA DO CONHECIMENTO EC, GESTÃO E MÍDIA MÍDIA E CONHECIMENTO ESCOLA DO FUTURO ORGANIZAÇÕES DO FUTURO MÍDIAS DO FUTURO UNIVERSIDADE FEDERAL DE SANTA CATARINA Programa de Pós-Graduação em Engenharia e Gestão do Conhecimento Florianópolis, Abril de 2006

Agenda

Metodologias

O que são

Por que são necessárias

Quais são as principais metodologias em EC

VITAL

MIKE

Protegé

CommonKADS

Outras

Tarefas genéricas

Métodos de limitação de papéis

Componentes da perícia

Ontologias e OntoLíngua

SPEDE

MOKA

UNIVERSIDADE FEDERAL DE SANTA CATARINA Programa de Pós-Graduação em Engenharia e Gestão do Conhecimento Florianópolis, Abril de 2006 O QUE SÃO METODOLOGIAS EXEMPLOS DE METODOLOGIAS EM EC CommonKADS Por que precisamos de Metodologia em EC Como nasce uma metodologia Pirâmide Metodológica PRINCÍPIOS DA ENGENHARIA DO CONHECIMENTO MODERNA

“ Da mesma forma que a crise de software resultou no estabelecimento da disciplina Engenharia de Software, a situação insatisfatória da construção de Sistemas Baseados em Conhecimento (SBC) tornou clara a necessidade para abordagens metodológicas.

Introdução

Assim, o objetivo da nova disciplina Engenharia do Conhecimento é similar àquele da Engenharia de Software:

tornar o processo de construção de SBC de uma arte em uma disciplina de engenharia.

Isso requer análise do próprio processo de construção e manutenção e o desenvolvimento de métodos, linguagens e ferramentas especializadas ao desenvolvimento de SBCs.”

Toda Metodologia é resultado da composição de diferentes componentes, desde a visão de mundo sobre o domínio para o qual ela se aplica até a utilização das ferramentas que ela dispõe.

Sobre Metodologia

A Pirâmide Metodológica (Schreiber. et al, 2002) – Adaptado de Uso Ferramentas Métodos Teoria Visão de mundo feedback Os blocos componentes de uma metodologia: a visão de mundo ou “slogans”, os conceitos teóricos, os métodos usando a metodologia, as ferramentas para aplicar os metodos, e as experiências através do uso da metodologia. Feedback flui ao longo da pirânide. Quando a visão de mundo muda, os fundamentos caem e é hora de mudar o paradigma. Como a teoria formaliza seus problemas, como estabelece modelos mentais para os desafios a que se direciona. Quais são os princípios científicas da teoria que vai dar base aos modelos de solução para os problemas propostos. Quais serão os procedimentos sistemáticos que podem levar às soluções propostas pela metodologia. Que instrumentos estão à disposição de quem quer aplicar a metodologia A utilização é um dos principais momentos de feedback.

A Pirâmide Metodológica

Cada camada da pirâmide é construída sobre a anterior. A base é a visão de mundo da metodologia, que dão base à compreensão da teoria (“venda”). Esses devem ter base em teoria, métodos, ferramentas e estudos de casos práticos.

As bases conceituais são resultado das lições aprendidas da forma de desenvolver sistemas de conhecimento no passado.

(Schreiber. et al, 2002) Estudos de caso projetos de aplicação Ferramentas CASE Ambiente de implementação Modelo de ciclo de vida, modelos de processo diretrizes, técnicas de elucidação Notações gráficas e textuais planilhas, documentos estruturados Engenharia do conhecimentobaseada em modelo. Reuso de padrões de conhecimento. feedback Uso Ferramentas Métodos Teoria Visão de mundo

Princípios

A Engenharia do Conhecimento moderna é baseada em um conjunto de princípios.

(Schreiber. et al, 2002)

Engenharia do Conhecimento não é um método de “mineração sobre a cabeça de um especialista”, e sim consiste em construir modelos dos diferentes aspectos do conhecimento humanos.

Tradicionalmente, a engenharia do conhecimento era vista como um processo de “extrair” ou “minerar da cabeça do especialista” e transportá-lo em forma computacional para uma máquina.

Essa visão se mostrou uma visão simplesta e ingênua.

Hoje a engenharia do conhecimento é concebida como uma atividade de modelagem.

Um modelo é uma abstração útil de alguma parte da realidade. Modelar é construir uma boa descrição (i.e., bom o suficiente para seu propósito) de somente uns poucos aspectos do conhecimento e deixar de lado o restante.

Neste sentido, modelos são úteis porque todos os detalhes de um conhecimento especializado não são suficientemente acessívels nem necessários aos objetivos de conhecimento na maioria dos projetos. Um modelos permite focar em alguns pontos e ignorar os demais.

Princípios (Schreiber. et al, 2002)

Princípio de nível de conhecimento: na modelagem do conhecimento, primeiro concentre-se na estrutura conceitual do conhecimento e deixe os detalhes de programação para depois.

A maioria dos desenvolvedores de sistemas tem uma tendência compreensível de tomar o sistema computacional como o ponto de referência dominante em suas atividades de análise e projeto. Mas há dois pontos de referência importantes:

o artefato computacional que se deseja construir e, mais importante, o lado humano: a situação de mundo real que a engenharia do conhecimento trata estudando especialista, usuários e seu comportamento no local de trabalho, envolvidos em um contexto organizacional mais amplo de resolução de problemas .

O princípio do nível de conhecimento foi enunciado por Alan Newell (1982), segundo o qual conhecimento deve ser modelado no nível conceitual , de forma independente de constructos computacionais específicos ou de implementação de software. Os conceitos usados na modelagem do conhecimento referem-se e refletem (i.e., modelam ) o domínio do mundo real e são expressos em vocabulário compreensível pelas pessoas envolvidas.

Conhecimento tem uma estrutura interna estável que é analisável por tipos de conhecimento específicos e distinguíveis e por perfis.

Conhecimento, raciocínio e resolução de problemas são fenômenos extremamente ricos. Conhecimento pode ser complexo, mas não é caótico : conhecimento parece ter uma estrutura interna estável , na qual se podem ver padrões similares repetidamente.

Embora a arquitetura de conhecimento é claramente mais complicada do que a que é capturada em sistemas baseados em regras, conhecimento tem estrutura compreensível e essa é um ponto prático para se fazer uma bem-sucedida análise do conhecimento.

Conceitualmente, modelos de nível de conhecimento nos ajudam a compreender o universo de solução de problemas humanos pela elaboração da tipologia de conhecimento .

Um resultado importante da engenharia do conhecimento moderna é que o conhecimento humano pode ser analisado em termos de categorias estáveis e genéricas, padrões e estruturas de conhecimento .

Assim, nós modelamos conhecimento como um todo bem-estruturado funcional, as partes do qual assumem papéis diferentes, restrutos e especializados na resolução humana de problemas.

A concepção do que é conhecimento, então, surge em termos das Ciências da Engenharia.

Um projeto de conhecimento deve ser gerido com a aprendizagem de sua experiência em uma forma controlada por espiral.

O desenvolvimento de sistemas de informação simples ou bem conhecidos geralmente toma uma rota de gestão fixa. Isso ocorre especialmente no chamado “modelo cascata” de desenvolvimento de sistemas. Esse consiste de um número de estágios pré-definidos em uma sequencia previamente conhecida: preparar e planejar o projeto; descobrir os requisitos do cliente; especificar e projetar o sistema; programar, testar e entregá-lo – e nesta ordem somente.

Conhecimento é muito rico e muito difícil para compreendê-lo como confinado uma abordagem rígida .

Prototipagem rápida se tornou, então, muito popular em sistemas de conhecimento pois permite aprender com o que se produz e rapidamente mudar o curso do projeto quando necessário. A falha na prototipagem rápida está na natureza ad hoc difícil de predizer e de gerir .

CommonKADS , então, favorece uma abordagem para gestão de projeto mais configurável e balanceada , mais flexível que o modelo cascata e mais controlável que a prototipagem rápida.

Projetos de conhecimento seguem uma abordagem espiral que capacita a estrutura de aprendizagem , em que os resultados intermediários agem como estágios para os passos a serem tomados na seqüência. Para determinar esses passos, a noção de objetivos e riscos é de suma importância.

UNIVERSIDADE FEDERAL DE SANTA CATARINA Programa de Pós-Graduação em Engenharia e Gestão do Conhecimento Florianópolis, Abril de 2006 O QUE SÃO METODOLOGIAS EXEMPLOS DE METODOLOGIAS EM EC PROTÉGÉ VITAL MIKE CommonKADS

Protégé http://protege.stanford.edul

O que é Protégé

Protégé é uma plataforma em software livre que provê a uma crescente comunidade de usuários um conjunto de ferramentas para construção de modelos de domínio e aplicações baseadas de conhecimento por meio de ontologias.

Em seu núcleo, Protégé implementa um rico conjunto de estruturas de modelagem de conhecimento que apóia a criação, visualização e manipulação de ontologias em vários formatos de representações.

Protégé pode ser configurado para prover apoio amigável ao domínio na criação de modelos de conhecimento e entrada de dados.

Além disso, Protégé pode ser expandido por meio de arquitetura plug-in e API Java para construção de ferramentas e aplicações baseadas em conhecimento.

http://protege.stanford.edu/overview/

Protégé permite formalizar Ontologias

Uma ontologia descreve os conceitos e relações que são importantes em um domínio particular, provendo um vocabulário para aquele domínio bem como uma especificação computadorizada do significado dos termos usados no vocabulário.

Ontologias variam desde taxonomias e classificações, esquemas de base de dados, a teorias totalmente axiomatizadas.

Nos anos recentes ontologias têm sido adotadas em muitos negócios e por muitas comunidades científicas como uma forma de compartilhar, reutilizar e processar conhecimento de domínio.

Ontologias são agora centrais a muitas aplicações tais como os portais científicos, gestão da informação com integração de sistemas, comércio eletrônico e serviços de web semântica.

O que Protégé Oferece

A Plataforma Protégé apóia duas formas de modelar ontologias:

O Editor de Frames-Protégé capacita usuários a construir s popular ontologias que são baseadas em frames, conforme um protocolo aberto de conectividade de bases de conhecimento ( Open Knowledge Base Connectivity protocol (OKBC) .

Neste modelo, uma ontologia consiste de um conjunto de classes organizadas de forma hierárquica para representar os conceitos de um domínio, um conjunto de atributos associados às classes para descrever suas propriedades e relações e um conjunto de instâncias (objetos) – exemplares individuais dos conceitos que guardam os valores específicos e suas propriedades.

O Editor Protégé-OWL capacita usuários a construir ontologias para Web Semântica, em particular na linguagem W3C OWL ( Web Ontology Language ) .

Uma ontologia OWL pode incluir classes, propriedades e suas instâncias. Dada uma ontologia, o formato semântico OWL especifica como derivar as consequencias lógicas, i.e., fatis não literalmente presentes na ontologia, mas cobertos na semântica

Essas derivações podem ser baseadas em um documento único ou em documentos múltiplos combinados por meio de mecanismos OWL (ver OWL Web Ontology Language Guide ).

Referências sobre Protegé

Método Protegé

Eriksson, H., Shahar, Y., Tu, S. W., Puerta, A. R. & Musen, M. A. [1995], ‘Task modeling with reusable problem-solving methods’. Artificial Intelligence 79(2), 293–326

Puerta et al., .A multiple-method Knowledge acquisition shell for the automatic gen eration of knowledge-acquisition tools. Knowledge Acquisition, 4, 171-196. 1992.

VITAL http://www.cs.helsinki.fi/u/linden/research/vital92-95/ http://kmi.open.ac.uk/people/domingue/vital/vital.html 1993

O que é VITAL

VITAL é um projeto de pesquisa e desenvolvimento que tem por objetivo prover apoio metodológico e computacional para o desenvolvimento de grandes aplicações KBS

VITAL tem como novidade a proposição de desenvolver um workbench (bancada) completo baseado em metodologia para todo o ciclo de vida de KBS, desde a especificação de requisitos até a implementação, integrando e aplicando um número de técnicas derivadas dos campos da inteligência artificial, bem como da engenharia de software e da interação homem-máquina (ergonomia)

Conceitos de VITAL

A metodologia de engenharia do Conhecimento VITAL é centrada na noção de produto de processo: "essential and permanent deliverable produced in the course of a KBS project" [Jonker et al, 1991] .

A idéia é que o desenvolvimento de um KBS é facilitado por meio da adoção de uma abordagem estruturada na qual:

O desenvolvimento da apliacção é guiado pela constrção de um processo bem definido e bem documentado;

O perfil de cada processo resultante e seus links com outros são explícitos; e

Existe um conjunto de técnicas consistentes e sistemáticas e de métodos para apoiar a construção de cada produto de processo.

Componentes de VITAL

Especificação de requisitos Documento que provê uma descrição das funcionalidades esperadas da aplicação KBS e as eventuais restrições que devem ser obedecidas.

Modelo Conceitual. Esse produto do processo VITAL provê um modelo de expertise capturando as entidades relevantes do domínio, as tarefas estruturadas, e o comportamento de resolução de problema do especialista.

Modelos de Projeto . Compreendem o modelo de projeto funcional (FDM), o modelo de projeto técnico (TDM). O FDM providencia uma descrição dos objetivos do KBS independente do domínio. O TDM é uma implementação específica (pode ser também um domínio e um KBS específico) mapeando FDM e código executável.

Código Executável. Compreende todos os “componentes de software que podem ser mantidos” embarcados na aplicação (quer tenham sido desenvolvidos ou não para o KBS em questão).

Organização do VITAL WORKBENCH Baloo – Meta-object-management-system desenvolvido em 1992, como interface entre a ferramenta e o OMS. OMS – Object Management System para integração dos dados

Plano de Torre de VITAL Independência entre os componentes, desenvolvimento incremental Facilidade de utilização por ter base em metodologias da ergonomia

Referências sobre VITAL

Método VITAL

Stutt, A.; Motta, E. VITAL - A methodology-based workbench for KBS life cycle support. ESPRIT II, 1994. Project Report.

Shadbolt et al., Constructing Knowledge Based System. IEEE Software, Noviembre, 34-38. 1993.

Fabiano Beppler (doutorado); Márcio Napoli (mestrado); Tiago Fascin (mestrado) MIKE (Model-based and Knowledge Engineering)

Motivação de MIKE

Para evitar que sistemas de conhecimento sofram dos mesmos problemas de produtividade que os sistemas convencionais tiveram em sua primeira fase, por serem desprovidos de metodologia, propõe-se que os desenvolvedores de KBS aprendam com os princípios da Engenharia de Software.

Atividades da Engenharia do Conhecimento EGC MIKE – Model-based and Knowledge Engineering

Edward Feigenbaum (1997) define a atividade do conhecimento como a arte de construir sistemas complexos que representam o conhecimento do mundo.

Basicamente compreende dois períodos:

transferência do conhecimento;

modelagem do conhecimento.

Transferência do Conhecimento EGC MIKE – Model-based and Knowledge Engineering

Durante o período de transferência do conhecimento, muitas ferramentas são utilizadas com a finalidade de tornar rápida a transferência do conhecimento humano (do perito) para os sistemas computacionais.

KBS – Knowledge-Based System.

O grande gargalo no processo de transferência do conhecimento do especialista para os KBS é a elicitação desse conhecimento.

Motivação de MIKE

MIKE é um framework para elucidar, interpretar, formalizar e implementar conhecimento visando o desenvolvimento de sistemas baseados em conhecimento.

Como tal, o objetivo de MIKE é a proposta de um processo modelo e de meios para apoiar o engenheiro de conhecimento.

MIKE objetiva integrar as vantagens dos modelos de ciclo de vida, prototipagem e técnicas de especificação formal em um framework coerente para engenheiros do conhecimento

Princípios de MIKE

Engenharia do Conhecimento baseada em Modelo

EC como processo de modelagem. Desenvolver um SBC não significa transferir conhecimento de um especialista para uma representação adequada em computador e sim a proposição de conhecimento (modelo) pelo observador.

Engenheiro de Conhecimento é um moderador do processo de modelagem. Em MIKE o Eng. Conhecimento não cria o modelo e sim modera o processo de modelagem. Há um hiato de comunicação natural entre especialista e engenheiro, especialmente no que se refere ao processo de solução do primeiro (muitas vezes tácito)

Princípios de MIKE

Engenharia do Conhecimento é um processo Incremental

O objetivo da EC é a construção de modelos. Como tal, se consegue apenas uma aproximação do referencial real a que se aplica.

O processo de modelagem é cíclico. Há sempre refinamento, modificação ou complemento pela revisão contínua.

O processo de modelagem é dependente do observador . O modelo deve ser continuamente confrontado com a realidade e melhorado pelo engenheiro.

Princípios de MIKE

Reduzir o hiato de representação

No nível lingüístico , o conhecimento é descrito em linguagem natural. Ele ocorre após o processo de elucidação do conhecimento , consistindo de entrevistas, protocolos e relatórios verbais. Esses relatórios são interpretados no nível de interpretação de conhecimento , onde se objetiva representar conhecimento ao nível conceitual. O nível conceitual pode ser formalizado (lógica e epistemologicamente). Em MIKE isso é feito com a linguagem KARL

Princípios de MIKE

Reutilização de Modelos Existentes

Deve-se procurar a reutilização de partes do modelo .

Uma das formas de fazê-lo está na separação entre a representação do conhecimento do método de resolução do problema.

O Processo de EC proposto por MIKE

Etapas do MIKE - Elicitation EGC MIKE – Model-based and Knowledge Engineering É a etapa de aquisição do conhecimento junto ao perito, feita através de reuniões e entrevistas estruturadas. Os resultados dessas entrevistas são descrições informais do conhecimento, as quais são armazenadas numa linguagem natural denominando-se protocolo do conhecimento .

Etapas do MIKE - Interpretation EGC MIKE – Model-based and Knowledge Engineering Durante esta fase as estruturas de conhecimento identificadas a partir dos protocolos de conhecimento são representadas de maneira semi-informal no Structure-Model . Nesse modelo de estrutura, são identificados os fluxos de informações e as dependências entre os dados. Essa estrutura facilita a validação dos dados e a comunicação entre o engenheiro do conhecimento e o perito.

Etapas do MIKE - Formalization EGC MIKE – Model-based and Knowledge Engineering O conhecimento, que até esta etapa era armazenado num formato texto e em uma linguagem natural, agora é formalizado e passa a ser representado no formato do modelo KARL*. A formalização do conhecimento ajuda na análise do processo e na identificação de possíveis problemas, pois o modelo KARL é executável, podendo ser testado e avaliado. Esta fase tem como principal resultado a aquisição e a representação das principais exigências funcionais. * KARL - Linguagem para aquisição e representação do conhecimento.

Etapas do MIKE – A Linguagem KARL EGC MIKE – Model-based and Knowledge Engineering A KARL é uma linguagem para aquisição e representação do conhecimento. Permite a representação do conhecimento de maneira precisa de forma a extinguir a ambigüidade. É uma linguagem executável e por isso pode ser prototipada com o objetivo de contemplar as descrições realísticas da funcionalidade desejada como também de avaliar as competências do conhecimento capturado.

Etapas do MIKE - Design EGC MIKE – Model-based and Knowledge Engineering Durante a fase de Design, os requisitos não funcionais, tais como robustez, portabilidade, confiabilidade, eficiência, são considerados exigências. Nesta fase é feito o detalhamento das estruturas de dados e algoritmos de software. O resultado desse detalhamento é o que contempla o Design Model . Nesta etapa é feito um refinamento dos algoritmos e das estruturas adicionais, bem como a captura dos requisitos funcionais e não funcionais do software.

Etapas do MIKE - Implementation EGC MIKE – Model-based and Knowledge Engineering Nesta etapa é feita a implementação do Design Model propriamente dita, além do refinamento de algumas conclusões bem como da introdução de algoritmos adicionais.

MIKE e a Engenharia de Software EGC MIKE – Model-based and Knowledge Engineering

Considerações EGC MIKE – Model-based and Knowledge Engineering A ambigüidade, a falta de precisão e a dificuldade de representação do conhecimento são alguns dos problemas encontrados durante o processo de elicitação do conhecimento. Como esse processo é um dos mais importantes na construção de sistemas baseados em conhecimento, é extremamente importante o uso de processos que assegurem a execução da elicitação bem como a abstração do conhecimento feito pelo engenheiro. A utilização de um processo como o MIKE garante a veracidade e a precisão do conjunto de artefatos levantados pelo engenheiro do conhecimento para implementação do KBS.

Referências sobre MIKE

Método MIKE

Angele, J., Fensel, D., Landes, D., and Studer, R. (1998). Developing knowledge-based systems with MIKE. Journal of Automated Software Engineering.

J. Angele, D. Fensel, D. Landes, S. Neubert, and R. Studer. Model-Based and Incremental Knowledge Engineering:The MIKE Approach. En J. CUENA, ed., Knowledge Oriented Software Design, pp. 139-168, North-Holland, Elsevier. 1993

UNIVERSIDADE FEDERAL DE SANTA CATARINA Programa de Pós-Graduação em Engenharia e Gestão do Conhecimento Florianópolis, Abril de 2006 O QUE SÃO METODOLOGIAS EXEMPLOS DE METODOLOGIAS EM EC Visão Geral Relevância do Contexto Organizacional Exemplo de Modelagem Organizacional CommonKADS Modelo da Organização

Visão Geral do Modelo CommonKADS

Modelo da Organização. Apóia a análise das maiores características da organização, a fim de descobrir problemas e oportunidades para sistemas de conhecimento, estabelecer sua viabilidade e acessar o impacto na organização das ações de conhecimento pretendidas.

Modelo da Tarefa. Tarefas são subpartes relevantes de um processo de negócio. O modelo de tarefa analisa o layout da tarefa global, suas entradas, saídas, pré-condições e critérios de performance, bem como recursos e competências necessárias.

Modelo de Agente. Agentes são executores de uma tarefa. Um agente pode ser humano, um sistema de informação ou qualquer outra entidade capaz de realizar uma tarefa. O modelo de agente descreve as características dos agentes, em particular suas competências, autoridades e restrições para agir. Além disso, relaciona os links de comunicação entre agentes necessários para executar uma tarefa.

Contexto Conceito Artefato Modelo da Organização Modelo da Tarefa Modelo do Agente Modelo do Conhecimento Modelo de Comunicação Modelo de Projeto

Modelo de Conhecimento. O propósito do modelo de conhecimento é explicar em detalhes os tipos e estruturas de conehcimento utilizados para realizar uma tarefa. Permite uma descrição idenpendente de implementação do perfil dos diferentes componentes de conhecimento na resolução de problemas, de uma forma que seja compreensível por seres humanos. Isso torna o modelo de conhecimento importante veículo para comunicação com especialistas e usuários sobre os aspectos da resolução do problema de um sistema de conhecimento, durante tanto desenvolvimento como execução.

Modelo de Comunicação. Dado que muitos agentes podem estar envolvidos em uma tarefa, é importante modelar a transação de comunicação entre os agentes envolvidos. Isso é feito pelo modelo de comunicação, de forma independente de implementação ou de conceito, como ocorre no modelo de conhecimento.

Modelo do Projeto. Os modelos anteriores podem ser vistos como constituintes dos requisitos de especificação de um sistema de conhecimento, dividido em diferentes aspectos. Com base nesses requisitos, o modelo de projeto fornece a especificação técnica do sistema em termos de arquitetura, plataforma de implementação, módulos de software, representações e mecanismos computacionais necessários para implementar as funções descritas nos modelos de comunicação e conhecimento.

Juntos, os modelos da organização, da tarefa e do agente analisam o ambiente organizacional e os fatores críticos ao sucesso de um sistema de conhecimento.

Os modelos do conhecimento e de comunicação produzem uma descrição conceitual das funções de resolução de problema os dados que são tratados e gerados por um sistema de conhecimento.

O modelo de projeto converte esses em uma especificação técnica que é a base para a implementação de um software.

Não é necessário que todos os modelos sejam construídos. Isso dependerá dos objetivos do projeto e das experiências adquiridas quando se executa o projeto. Assim, uma escolha adequada deverá ser feita pelo gerente de projeto. Assim, um projeto de conhecimemento em CommonKADS produz três tipos de produtos:

Documentos do modelo CommonKADS;

Informação de gestão do projeto;

Software do sistema de conhecimento

Sistemas de conhecimento e sua engenharia não são entidades totalmente sem relação com outras formas de sistemas de informação e gestão.

CommonKADS tem influências de outras metodologias, como análise e projeto de sistemas estruturados, orientação a objetos, teoria organizacional, processo de reengenharia e gestão da qualidade.

Um dos exemplos dessa influência está na relação entre a abstração de objetos modelam entidades do mundo real de forma natural, o que é claramente semelhante a um dos princípios do conhecimento.

Ao contrário de sistemas especialistas convencionais, CommonKADS amplia diversas metodologias existentes, o que é útil quando tarefas, processos, domínios ou aplicações se tornam conhecimento intensivo.

Engenharia do Conhecimento

Capítulo 3: A Tarefa e seu Contexto Organizacional

Compreender e tratar apropriadamente o contexto organizacional é um fator crítico de sucesso para os sistemas de conhecimento e para outras medidas de gestão do conhecimento.

Como identificar gargalos de conhecimento e oportunidades em uma organização

Como tratar os aspectos econômicos, técnicos e de viabilidade de projeto em soluções como sistemas de conhecimento.

Como compreender e decidir sobre o impacto organizacional e a necessidade de mudanças quando novas soluções baseadas em sistemas de conhecimento são introduzidas na organização

Como integrar organizações orientadas a conhecimento, local de trabalho e análise de tarefas à análise de informação.

Schreiber, G.; Akkermans, H.; Anjewierden, A.; Hoog, R.; Shadbolt, N.; de Velde, W. V.; and Wielinga, B.. Knowledge Engnineering and Management: the CommonKADS Methodology . MIT Press. Cambridge. Massachussets. 2002

Por que os Aspectos Organizacionais são tão Importantes?

Sistemas de conhecimento são úteis apenas quando:

Realizam uma tarefa que nós demandamos; ou

Nos ajudam a realizar essas tarefas por nós mesmos, como sendo assistentes inteligentes.

É exatamente aí que está a importância do contexto organizacional, pois é nesse que as tarefas se inserem.

Qualquer sistema de informação ou de conhecimento, portanto, só pode funcionar satisfatoriamente se e somente se estiver inserido no contexto organizacional, tanto em nível macro como operacional.

Um sistema de conhecimento funciona como um agente que coopera com diversos atores, tanto humanos como não humanos, tomando conta de somente uma fração das tarefas que são necessárias em uma organização.

Sistemas de conhecimento, assim como qualquer sistema de informação, devem ser vistos como componentes de apoio aos processos de negócio da organização – não menos e nem mais.

Normalmente, os sistemas de conhecimento se inserem bem em abordagens que visem à melhoria de processos organizacionais.

A visão de melhoria de processos é muito mais apropriada que a visão tradicional de automação de tarefas especializadas.

Automação é um equívoco, por duas razões básicas:

Tarefas intensivas em conhecimento são geralmente tão complexas que sua automação plena é simplesmente uma ambição mal-direcionada, que leva a expectativas errôneas e, em última instância, a desapontamentos.

Além disso, ao contrário do que a maioria dos sistemas automáticos, sistemas de conhecimento podem dar suporte ativo ao invés de serem itens de utilização passiva, exatamente por sua capacidade de armazenar conhecimento e racionar sobre ele. São ativos na interação e ação junto ao usuário.

Ao invés de procurar a automação, o engenheiro de conhecimento deve procurar a informatização.

Nesse sentido, sistemas de conhecimento são agentes que ajudam seus usuários em tarefas especializadas, comportando-se como tutores inteligentes.

Nesse contexto, têm papel parcial mas valoroso na melhoria dos processos organizacionais, que resulta de estreita colaboração com os usuários.

É por essa razão, por ter que se manter conectado à missão de apoiar usuários em tarefas intensivas em conhecimento, que o engenheiro de conhecimento deve manter-se conectado ao ambiente organizacional.

Já nos estágios iniciais de desenvolvimento, o engenheiro de conhecimento deve assegurar-se que o sistema de conhecimento vai se inserir de forma apropriada na organização.

Isso se contrapõe com a posição tradicional de desenvolvimento, em que o engenheiro de sistemas se concentra em ter sob controle os aspectos técnicos do projeto.

A maturidade e projeção organizacional dos sistemas de informação e dos sistemas de conhecimento removeu o foco de dificuldades da tecnologia para a visão organizacional.

Muitos outros fatores além da tecnologia são determinantes para o sucesso ou falha de sistemas em uma organização.

Os sistemas devem realizar bem suas tarefas segundo determinados padrões técnicos, mas devem também ser aceitáveis, amigáveis ao usuário final, interoperáveis com outros sistemas de informação e se enquadrar na estrutura, processos e nos sistemas de qualidade da organização como um todo.

A experiência prática com sistemas de conhecimento tem provado que seu sucesso depende de quão bem as questões organizacionais relevantes foram tratadas em seu projeto.

Muitos problemas com automação resultaram não de problemas com a tecnologia, mas da falta de preocupação com os fatores sociais e organizacionais.

Ainda assim, muitas metodologias de desenvolvimento de sistemas estão focadas nos aspectos técnicos e não dão apoio à análise dos elementos organizacionais que determinam sucesso ou falha do projeto.

É nesse sentido que as metodologias de desenvolvimento de sistemas de conhecimento, como o CommonKADS, trazem diretrizes que buscam a análise da organização e da tarefa. Essas estão centradas nos seguintes pontos:

Identificação de problemas e oportunidades.

Decisão sobre as soluções e sobre sua viabilidade.

Melhoria de tarefas e de tarefas relacionadas a conhecimento.

Planejamento para as necessidades de mudanças organizacionais.

Identificação de problemas e oportunidades.

Encontrar áreas promissoras para sistemas de conhecimento ou para outras soluções de gestão do conhecimento. São promissoras se puderem prover mais valor à organização.

Decisão sobre as Soluções e sobre sua Viabilidade.

Determinar se um projeto tem valor em termos de custos esperados, viabilidade tecnológica e atendimento às necessidades e recursos organizacionais.

Melhoria de Tarefas e de Tarefas Relacionadas com Conhecimento.

Analisar a natureza das tarefas envolvidas nos processos de negócio selecionados, com um olho em que conhecimento é utilizado pelos agentes responsáveis para realizá-las com êxito e outro em que melhorias podem ser alcançadas .

Planejamento para necessidades de mudanças nas organizações.

Pesquisar que impactos um sistema de conhecimento proposto tem nos vários aspectos organizacionais e preparar um plano de ação que esteja associado às medidas organizacionais associadas.

Os Principais Passos da Análise Organizacional (Schreiber. et al, 2002)

Os passos da análise organizacional que um analista de conhecimento deve realizar são:

Conduzir um estudo de viabilidade e de escopo, consistido de duas partes:

Identificação de áreas problema/oportunidade e potenciais soluções, colocando-as em uma perspectiva mais ampla na organização.

Dedicir sobre aspectos econômicos, técnicos e de viabilidade de projeto, a fim de selecionar as áreas mais proeminentes a serem alvo de soluções.

Realizar um estudo de impacto e de melhorias junto às áreas de solução definidas, também seguindo dois procedimentos:

Coletando idéias relacionadas às relações entre tarefas, agentes envolvidos e seu uso de conhecimento para o êxito do que realizam, bem como que melhoramentos podem ser feitos.

Dedicir sobre medidas organizacionais e mudanças de tarefas, a fim de assegurar a aceitação organizacional e a integração de uma solução baseada em sistema de conhecimento.

Os Principais Passos da Análise Organizacional (Schreiber. et al, 2002)

Essa seqüência de passos culmina em uma visão compreensível da situação organizacional na qual o sistema de conhecimento deve operar.

Para tal a Metodologia CommonKADS possui o Modelo da Organização , onde se descreve e se analisa o ambiente organizacional.

Para o estudo de impactos e melhoramentos das soluções baseadas em conhecimento, a Metodologia CommonKADS oferece os Modelos de Tarefa e de Agente. Esses revelam partes relevantes da organização. O Modelo de Tarefa focaliza-se nas tarefas relacionadas com conhecimento que guardem relação com o problema que o sistema de conhecimento deve resolver. Essas tarefas são alocadas a agentes, caracterizados no Modelo de Agentes .

Os estudos 1a e 2a anteriores ( ver lâmina anterior ) estão orientados às tarefas de modelagem e análise, enquanto os estudos 1b e 2b integram os resultados do modelo para expressarem o propósito da tomada de decisão empresarial.

O estudo do contexto organizacional, portanto, é resultado da combinação de três modelos da Metodologia CommonKADS: Modelo da Organização, Modelo de Tarefa e Modelo de Agente.

Estudo de Viabilidade: Modelando a Organização (Schreiber. et al, 2002)

A literatura em análise organizacional, teoria da administração, melhoria de processos organizacionais, reengenharia e diversos outros campos correlatos é vasta e abundante.

Para o propósito de identificar aplicações de sistemas de conhecimento que adicionem valor à organização e outras soluções em gestão do conhecimento, não é necessário tomar a totalidade dessas abordagens.

Engenheiros do conhecimento estão interessados em compreender as organizações sob a ótica e de orientação a conhecimento .

Assim, o Modelo de Organização do CommonKADS toma elementos e experiências de várias fontes – incluindo teoria organizacional, análise de processos organizacionais, gestão da informação – e os integra em pacote coerente e compreensivo, direcionado à orientação de conhecimento na organização.

O Modelo da Organização descreve a organização em uma forma estruturada e sistêmica. Diferentes aspectos, tais como estrutura organizacional, processos, equipe e recursos tomam parte e interagem com quem deseja introduzir novas soluções de conhecimento.

Esses diferentes aspectos são representados como componentes do Modelo da Organização . Devem ser descritos tanto em sua situação atual como futura.

Estudo de Viabilidade: Modelando a Organização (Schreiber. et al, 2002)

A comparação entre as descrições atual e futura permite aferir valor, viabilidade e aceitação de novas soluções orientadas a conhecimento.

Além disso, estabelece-se um plano de ações bem fundamentado para as medidas organizacionais e para os melhoramentos que vão bem além do processo de desenvolvimento de sistemas.

O Modelo da Organização possui uma visão esquemática, com 4 componentes:

Problemas e Oportunidades (OM-1) ,

Descrição da área Foco na Organização (OM-2) ;

Diagrama de Processos (OM-3) e

Ativos de Conhecimento (OM-4).

Para cada componente, a Metodologia CommonKADS determina uma série de planilhas (e.g., OMs 1 a 4, no caso do Modelo da Organização) que orientam o analista de conhecimento.

Modelo da Organização (Schreiber. et al, 2002, pg. 29)

Contexto Organizacional, Problemas e Portfólio de Soluções (Schreiber. et al, 2002)

No primeiro passo, o analista de conhecimento está focado em problemas e oportunidades, vistos em um contexto mais amplo da organização.

Por contexto mais amplo entende-se a compreensão de itens como missão organizacional, objetivos, estratégicas, cadeia de valor e fatores de influência externos à organização. Em uma primeira abordagem assume-se esse contexto como invariante.

Oportunidades, problemas e soluções orientadas a conhecimento devem ser sempre julgadas dentro da perspectiva mais ampla do negócio, o que faz com seja importante estabelecer uma compreensão explícita desses elementos de contexto.

Para tal, a Metodologia CommonKADS estabelece uma planilha que é numerada como OM-1 (Organizational Model 1), que explica os vários aspectos que devem ser considerados e ajuda a especificar esta parte do modelo da organização.

Pode-se interpretar essa atividade como a tarefa de cobrir a parte de visão do estudo da organização. O portfólio de problemas-oportunidades e as soluções potenciais de conhecimento podem ser criadas por entrevistas com membros chave da equipe da organização (talvez também consumidores!), brainstorming, reuniões com os gerentes, etc.

Contexto Organizacional, Problemas e Portfólio de Soluções (Schreiber. et al, 2002)

É importante identificar os diversos atores ( stakeholders) que possam ter interesse no projeto, incluindo-se:

Provedores de conhecimento . Especialistas que detém conhecimento em determinada área.

Usuários de conhecimento. São as pessoas que necessitam utilizar o conhecimento para realizar seu trabalho de forma exitosa.

Tomadores de Decisão. Os gestores que estão em posição de tomarem decisões que afetam o trabalho do provedor de conhecimento ou dos usuários do conhecimento.

Identificar essas pessoas e seus papéis nos estágios iniciais ajuda a que rapidamente se defina o foco nos processos do negócio, problemas e oportunidades.

Geralmente, provedores de conhecimento, usuários e tomadores de decisão são pessoas bem diferentes com diferentes interesses. Entrevistá-los ajuda a compreender o que interessa a cada um na relação com o projeto de conhecimento.

Visões divergentes e conflitos de interesse são comuns em organizações, mas é necessário compreendê-los. Sem a compreensão uma boa solução de conhecimento não é nem mesmo possível.

Contexto Organizacional, Problemas e Portfólio de Soluções (Schreiber. et al, 2002) Liste soluções possíveis para os problemas e oportunidades percebidos, como sugerido nas entrevistas e discussões, considerando as características da organização verificadas anteriormente. SOLUÇÕES Indique, de forma concisa, as características chave ao contexto organizacional mais amplo, tal que coloque a lista de problemas e oportunidades em uma perspectiva apropriada. Características importantes a considerar são: 1. Missão, visão e objetivos da organização 2. Fatores externos à organização que devem ser tratados considerados no projeto 3. Estratégia da organização 4. Sua cadeia de valor e principais geradores de valor. CONTEXTO ORGANIZACIONAL Faça uma lista de problemas e oportunidades percebidas, baseada em entrevistas, brainstorming, encontros e discussões com gerentes, etc. PROBLEMAS E OPORTUNIDADES Planilha de Problemas e Oportunidades – OM1 Modelo da Organização

Engenharia do Conhecimento EXEMPLO Serviços de Seguridade Social Schreiber, G.; Akkermans, H.; Anjewierden, A.; Hoog, R.; Shadbolt, N.; de Velde, W. V.; and Wielinga, B.. Knowledge Engnineering and Management: the CommonKADS Methodology . MIT Press. Cambridge. Massachussets. 2002 pg. 36

Estudo de Caso: Modelo da Organização – Serviços de Seguridade Social (Schreiber. et al, 2002)

Na Holanda, a administração de uma variedade de serviços se seguridade social é realizada pela municipalidade. Os mais importantes são benefícios de auxílio geral. Essa categoria está no final da linha dos tipos de benefícios, de forma que, se nenhuma outra modalidade for aplicável, a pessoa pode opter por essa.

Quando se iniciou o projeto, na municipalidade de Amsterdam, aproximadamente 60 mil pessoas foram apoiadas por benefícios gerais.

A fim de se qualificar para esse suporte financeiro, cada candidato é entrevistado em amplo detalhamento.

As regras são codificadas ou podem ser derivadas de vários volumes de leis e regulamentos.

Em Amsterdam, tem-se acumulado um considerável arquivo de casos (backlog - em estágio crescente) de clientes, surgido nos últimos anos. O resultado é a formação de longas filas nos escritórios, bem como um tempo expressivo entre o pedido e a decisão final.

Há uma preocupação acentuada dos responsáveis pela administração da municipalidade, pois esse arquivo tem afetado a eficiência do trabalho.

Além da preocupação com a eficiência, os clientes têm se queixado muito do atendimento, queixas essas que já chamaram a atenção da mídia local.

Nesse contexto, o secretário do Diretório sugeriu o uso de um sistema de conhecimento para ajudar a reduzir o arquivo de pendências.

É muito importante enfatizar a hipótese inicial porque ela demonstra o quão crucial é a caracterização do modelo da organização. Uma relação imediata de problema/oportunidade que foi derivada é a seguinte:

Dada a complexidade da legislação e documentação aplicável à seguridade social, a equipe de especialistas necessita de um longo tempo para chegar a uma decisão. Se for possível apoiar essas pessoas com sistemas de conhecimento que armazenem o conhecimento necessário para uma tomada de decisão legal, o processo de decisão será acelerado e, assim, mais e mais clientes atendidos ao mesmo tempo, reduzindo de forma significativa o arquivo de pedidos.

Portanto, desde o início se tem uma clara idéia sobre o domínio do problema, direção de sua solução e benefícios para a organização como um todo. Embora essa parte do estudo de caso esteja na forma narrativa, é relativamente óbvio montar o primeiro componente do Modelo da Organização, caracterizado pela Planilha OM-1.

TAREFA. Monte a Planilha OM-1 da organização de seguridade social de Amsterdam, com base nos relatos do caso aqui descrito.

Introdução à Engenharia e Gestão do Conhecimento Aula 7 – SEGUNDA PARTE Roberto C. dos Santos Pacheco [email_address] Professor UNIVERSIDADE FEDERAL DE SANTA CATARINA Programa de Pós-Graduação em Engenharia e Gestão do Conhecimento Florianópolis, Maio de 2005 Parte II: Engenharia do Conhecimento Neri dos Santos [email_address] Professor

Engenharia do Conhecimento

Capítulo 3: A Tarefa e seu Contexto Organizacional

Compreender e tratar apropriadamente o contexto organizacional é um fator crítico de sucesso para os sistemas de conhecimento e para outras medidas de gestão do conhecimento.

Como identificar gargalos de conhecimento e oportunidades em uma organização

Como tratar os aspectos econômicos, técnicos e de viabilidade de projeto em soluções como sistemas de conhecimento.

Como compreender e decidir sobre o impacto organizacional e a necessidade de mudanças quando novas soluções baseadas em sistemas de conhecimento são introduzidas na organização

Como integrar organizações orientadas a conhecimento, local de trabalho e análise de tarefas à análise de informação.

Schreiber, G.; Akkermans, H.; Anjewierden, A.; Hoog, R.; Shadbolt, N.; de Velde, W. V.; and Wielinga, B.. Knowledge Engnineering and Management: the CommonKADS Methodology . MIT Press. Cambridge. Massachussets. 2002

MODELO DA ORGANIZAÇÃO - Descrição da Área de Foco na Organização – OM2 (Schreiber. et al, 2002) Descrição da área foco da organização alvo das soluções de conhecimento.

Descrição da Área de Foco na Organização – OM2

Trata-se de cobrir os aspectos que tratam de como os processos de negócio da organização são estruturados, que equipe está envolvida, que recursos são utilizados e demais itens relacionados.

Todos esses componentes do Modelo da Organização podem se alterar (por isso são chamados componentes variantes ) como resultado da introdução de um sistema de conhecimento.

Como um apoio à análise dessa parte do modelo organizacional, a Metodologia CommonKADS propõe uma planilha específica, numerada como OM-2 .

Nessa planilha, explica-se que componentes organizacionais são importantes de se levar em consideração.

Para cada área problema-oportunidade deve ser montada uma planilha OM-2 correspondente. Essa lista de planilhas OM-2, por sua vez, debe ser definida a partir da lista de problemas-oportunidades que for registrada na planilha OM-1.

O componente denominado “Processo” na Planilha OM-2 é muito importante para o processo de análise da organização em CommonKADS. Para tal, é importante trabalhar com diagramas de atividade de processos de negócio da UML , utilizando esses diagramas como parte do preenchimento da planilha OM-2.

Descrição de aspectos Organizacionais que impactam ou são afetados pelas soluções de conhecimento. (Schreiber. et al, 2002, pg. 31) Deve-se estar atento às regras não escritas, incluindo estilos de trabalho e comunicação (“a forma com que trabalhamos aqui…”), que estão relacionados com habilidades sociais e interpessoais (não ligadas a conhecimento), e às relações formais, informais e às redes. CULTURA E PODER Representa um recurso especial explorado no processo de negócio. Devido à sua importância estratégica, é colocado à parte. A descrição de seus componentes se dá em detalhes na Planilha OM-4. CONHECIMENTO Descreve os recursos que são utilizados para o processo de negócio. Esses podem cobrir diferentes tipos, como: (a) sistemas de informação ou outros recursos computacionais; (b) equipamento ou materiais; (c) tecnologia, patentes ou direitos. RECURSOS Indica a equipe envolvida, os interessados, incluindo tomadores de decisão, provedores e beneficiários de conhecimento (“clientes”). Esses atores não são necessariamente pessoas, mas sim papéis desempenhados na organização (diretor, consultor, etc.) PESSOAS Diagrama dos processos de negócios (UML) considerados. Um processo é uma parte relevante da cadeia de valor que está sob análise. É decomposto em tarefas que são detalhadas na Planilha OM-3. PROCESSO Organograma da organização ou da parte considerada no projeto de conhecimento. ESTRUTURA Planilha de Aspectos Variantes – OM2 Modelo da Organização

Descrição de Processo – Diagrama UML (Schreiber. et al, 2002, pg. 32)

Engenharia do Conhecimento EXEMPLO - CONTINUAÇÃO Serviços de Seguridade Social Schreiber, G.; Akkermans, H.; Anjewierden, A.; Hoog, R.; Shadbolt, N.; de Velde, W. V.; and Wielinga, B.. Knowledge Engnineering and Management: the CommonKADS Methodology . MIT Press. Cambridge. Massachussets. 2002 pg. 36-39

Estudo de Caso: Modelo da Organização – Serviços de Seguridade Social – OM2 (Schreiber. et al, 2002)

Para estabelecer os componentes variantes no caso da seguridade social da Holanda, é importante conhecer os elementos de estrutura, pessoas, cultura e poder da organização, bem como recursos e processos de conhecimento.

Estrutura. A estrutura formal da organização segue hierarquia composta por um escritório central e por suas ramificações locais, em cada uma das 16 localidades da municipalidade de Amsterdam. A estrutura de cada escritório local é a mesma. O escritório central tem um misto de departamentos meio e fim. Além disso, o diagrama mostra a existência de um computador central na municipalidade de Amsterdam, embora não seja parte dos serviços fim da organização (linha pontilhada). Contudo, é importante incluir essa conexão, dado que o computador central desempenha um considerável volume de trabalho no serviço de seguridade social e (naquela época) toda instituição municipal era formalmente solicitada a utilizar esse centro para todo seu processamento computacional.

Pessoas. Em organizações complexas, há muitos tipos de pessoas, com diferentes papéis organizacionais, requerendo diferentes estilos de especialidades.

Dada um resumo do projeto (ver o componente problema-oportunidade de OM-1), somente uma área muito limitada é considerada, sendo a maioria funcionários diretamente envolvidos com o processo de tomada de decisão.

O maior papel exercido por essas pessoas no nosso caso está relacionado no diagrama de estrutura organizacional.

Estudo de Caso: Modelo da Organização – Serviços de Seguridade Social – OM2

(Schreiber. et al, 2002) Pessoas Estrutura Estudo de Caso: Modelo da Organização – Serviços de Seguridade Social – OM2

Cultura e Poder. A força das relações entre as pessoas da organização deve indicar não somente relações formais de autoridade entre pessoas mas também relações informais de influências.

Mapear esses aspectos não é uma tarefa simples, especialmente porque as relações informais entre atores são difíceis de detectar. Três tipos de relacões de poder são identificáveis: relações formais, relações informais fortes e relações informais fracas . As relações formais têm base na hierarquia organizacional.

Por exemplo, diretor de localidade e diretor de escritório central que têm autoridade sobre chefes e testers de seu escritório. Relações informais fortes crescem lentamente com o tempo. Um exemplo pode estar nas reuniões freqüentes entre especialistas em regulamentos do escritório central e testers dos escritórios locais, em que os primeiros aproveitam os encontros para lançar campanha de controle de qualidade. Isso pode ser feito até mesmo sem a interferência do diretor do escritório local, apesar de sua autoridade formal.

Finalmente, relações informais fracas são as mais difíceis de descobrir, porque refletem links ocasionais mas muito importantes entre pessoas da organização. Essa influência é exercida principalmente por encontros informais e chamadas telefônicas.

Estudo de Caso: Modelo da Organização – Serviços de Seguridade Social – OM2

Recursos. No presente projeto os seguintes recursos foram selecionados como relevantes:

Computadores . No serviço como um todo, no tempo do projeto, somente um número limite de computadores estavam disponiveis. Toda a capacidade computacional era feita pelo computador central. Em cada escritório local havia poucos terminais conectados ao computador central. Em alguns escritórios locais, experimentos locais com computadores pessoais tinham iniciado a tomar parte do trabalho rotineiro, tais como produção de cartas e notificações.

Espaço do Escritório. Alguns escritórios locais dispõem de equipamentos insuficientes para tratar o trabalho gerado por seus clientes.

Processo, conhecimento. Como se pode deduzir da descrição do projeto, o principal foco foi o conhecimento para o processo de tomada de decisão sobre os benefícios dos serviços de seguridade social.

Geralmente, o uso flexível do Modelo da Organização e suas técnicas de representação dá os melhores resultados. Não é nem sempre útil nem necessário preencher todos os campos de todos os componentes do modelo organizacional e suas planilhas. Isso deve ser feito somente se a informação tiver relevância às conclusões e tenha implicações para ações. Contudo, essa seletividade deve ser uma decisão consciente do engenheiro de conhecimento, dado que as planilhas fornecem diretrizes para checklists compreensíveis.

Além disso, a forma de representar a informação coletada geralmente varia. Textos pequenos nos campos da matriz, por exemplo, são úteis, mas pequenos diagramas ou figuras são mais claros e efetivos. Assim, o engenheiro de conhecimento deve estar livre para escolher a forma mais apropriada. O critério deve ser sempre optar pelo que for tornar a comunicação mais efetiva com as pessoas responsáveis pelo estudo.

MODELO DA ORGANIZAÇÃO - Descrição dos Processos – OM3 (Schreiber. et al, 2002) Detalhando o processo de negócio da organização

Descrição dos Processos de Negócio – OM3

O processo também é melhor e mais detalhadamente descrito com o uso de uma planilha em separado. O processo de negócio é dividido em tarefas menores, porque um sistema de conhecimento conduz uma tarefa específica – e esse tem que se enquadrar de forma apropriada no processo como um todo.

Geralmente, algumas adaptações nos processos são necessárias, geralmente por modificações nas tarefas ou por combinações que os conectem de forma diferente.

Para investigar esse aspecto, a metodologia CommonKADS tem uma planilha específica, numerada OM-3 , para especificar detalhes das tarefas que compõem um processo.

Deve-se procurar decifrar o quanto intensivas em conhecimento são essas tarefas e como o conhecimento é utilizado. Pode ser difícil estabelecer o grau de dependência de conhecimento das tarefas nesse ponto da análise, mas a identificação dos tipos de conhecimento nas organizações (também componente CommonKADS) é um facilitador.

Outra informação importante é a relevância de cada tarefa, que pode ser descrita em uma escala cardinal entre 1 e 5. Não há regras rígidas para isso e essa tarefa pode ser difícil, mas é tipicamente uma combinação de esforço, recursos, criticalidade e complexidade das tarefas.

O processo de negócio é modelado ao nível de detalhe que nos capacita a tomar decisões sobre tarefas (ex: construir modelo de conhecimento para automatizar ou explicar aquela tarefa).

Descrição dos Processos de Negócio – OM3 Indicação de quão relevante é a tarefa (e.g., escala de 5 pontos em termos de frequencia, custos, recursos ou criticalidade da missão Booleano que indica se a tarefa é considera intensiva em conhecimento ou não Lista de recursos de conhecimento utilizado nessa tarefa Alguma localização na estrutura da organização (ver OM-2) Um certo agente ou humano (ver “pessoas” em OM-2) ou um software (ver “recursos” em OM-2) Nome da tarefa (alguma parte do processo em OM-2) Identificador da tarefa Relevância Intensivo? Ativo de Conhecimento Onde? Realizada por Tarefa No Modelo da Organização Planilha de Detalhamento de Processos – OM-3

Engenharia do Conhecimento EXEMPLO - CONTINUAÇÃO Serviços de Seguridade Social Schreiber, G.; Akkermans, H.; Anjewierden, A.; Hoog, R.; Shadbolt, N.; de Velde, W. V.; and Wielinga, B.. Knowledge Engnineering and Management: the CommonKADS Methodology . MIT Press. Cambridge. Massachussets. 2002 pg. 36-39

Estudo de Caso: Modelo da Organização – Detalhamento de Processos – OM3 (Schreiber. et al, 2002)

Dividindo processo em tarefas. Com base nas entrevistas com o pessoal chave da organização, entre eles secretária da diretoria, as seguintes partes principais do processo geral (tarefas) foram identificadas:

Atendimento . Essa tarefa se refere à obtenção de informação relevantes sobre um cliente, por exemplo, idade, endereço, fontes adicionais de proventos, vários aspectos da situação pessoal do cliente. Contato direto pessoa a pessoa é normal nesse tipo de tarefa.

Arquivamento . Manter e dar manutenção a arquivos e documentos para todos os clientes ao longo do ciclo de vida dos serviços de seguridade social.

Tomada de Decisão . Tomar a decisão, com base nos dados sobre a situação pessoal do cliente (como obtido no Atendimento) e nas leis e regras aplicáveis, se o cliente está qualificado aos benefícios, bem como decidir sobre o total de dinheiro que ele ou ela deverá receber

Notificação . Informar o cliente sobre as decisões tomadas (sem notificação por escrito, a decisão não tem valor legal).

Relatório . Escrever um relatório interno sobre o cliente. Esse serve como entrada para o pagamento.

Pagamento . Realizar o pagamento ao cliente.

Controle de Qualidade . Controlar se as decisões tomadas estão corretas na visão das leis e regulamentos. Essa tarefa de controle é realizada “pós-fato”. É baseada em casos amostrais da tarefa de tomada de decisão, segundo registrado no relatório de tarefas.

Estudo de Caso: Modelo da Organização – Detalhamento de Processos – OM3

Algumas tarefas (tais como Arquivamento) ocorrem em vários momentos do processo. Há uma distinção entre o processo primário e as tarefas de apoio (são os dois retângulos maiores na figura).

O foco inicial do projeto estava na tarefa de tomada de decisão, mas agora se tornou claro o fato de que ela está diretamente conectada às tarefas de atendimento e notificação e que, além disso, há uma possibilidade de que haja conexão também com a tarefa de arquivamento.

Para modelar esses aspectos, é útil utilizar o Diagrama de estados da UML .

(Schreiber. et al, 2002) – pp. 40-41

MODELO DA ORGANIZAÇÃO – Ativos de Conhecimento – OM4 (Schreiber. et al, 2002) Detalhando do elemento mais importante da organização para efeitos da Engenharia e da Gestão do Conhecimento

MODELO DA ORGANIZAÇÃO – Ativos de Conhecimento – OM4 OM-2: Aspectos Organizacionais x Soluções de conhecimento OM-3: Processos e Tarefas que os compõem

ATIVOS DE CONHECIMENTO. Elemento mais importante para o processo de gestão e engenharia de conhecimento, é analisado em detalhe na Planilha OM-4 do Modelo da Organização. Essa provê a especificação do componente Conhecimento do Modelo de Organização do CommonKADS. Essas descrições são retomadas tanto no Modelo de Tarefa como, claro, no Modelo Conhecimento . Uma das vantagens dessa abordagem por partes é a flexibilidade que se dá à gestão do projeto de conhecimento.

Componente Conhecimento da Organização – OM4

A Planilha de Ativos de Conhecimento OM-4 é apenas uma análise de primeira ordem. A perspectiva que se tem aqui é que esses conhecimentos são importantes como ativos, que são utilizados ativamente pelos trabalhadores dentro da organização para o propósito de uma tarefa ou processo específico.

Uma questão relevante nesse estudo é destacar dimensões em que os ativos de conhecimento possam ser melhorados, na forma, acessibilidade em tempo ou espaço, ou na qualidade. Essa análise não é somente importante para a engenharia de sistemas de conhecimento, mas talvez para ações de gestão de conhecimento em geral.

(Sim ou Não; comentário) (Sim ou Não; comentário) (Sim ou Não; comentário) (Sim ou Não; comentário) Tarefa (conforme Planilha OM-3) Agente (Planilha OM-3) Nome (Planilha OM-3) Na qualidade adequada? No tempo correto? Lugar Correto? Forma correta? Usado em Possuído por Ativo de Conhecimento Modelo da Organização Planilha de Ativos de Conhecimento – OM-4

Estudo de Caso: Modelo da Organização – Ativos de Conhecimento – OM-4 (Schreiber. et al, 2002)

Retornando ao estudo de caso da Seguridade Social em Amsterdam, já se tornaram claros alguns pontos referentes aos ativos de conhecimento quando da análise de processo.

Somente algumas das tarefas são intensivas em conhecimento. São elas: Atendimento, Tomada de decisão e Controle de Qualidade .

No Atendimento outras habilidades são fundamentais, particularmente comunicação e relacionamento interpessoal.

No caso da Tomada de decisão , dado que o foco do projeto inicial era acelerar esse processo, foi natural o passo de se investigar em mais detalhes o conhecimento que dá bases à tomada de decisão.

Também foi natural para os analistas verificar as tarefas de Atendimento e Notificação , dado que essas têm relação de dependências com o processo de tomada de decisão.

Depois de algumas etapas iniciais de aquisição de conhecimento ficou claro que haviam pelo menos dois aspectos ligados à tomada de decisão que não ficaram bem compreendidos e, portanto, comprometer a construção ou funcionamento do sistema de conhecimento que se visualizava.

Primeiro, os clientes algumas vezes mentem sobre seus dados a fim de conseguir maiores benefícios. Detectar esse fato é uma habilidade altamente dependente dos tipos de pistas não verbais. As pessoas envolvidas em Atendimento eram muito boas em interpretar essas pistas.

Um sistema de conhecimento, contudo, obviamente terá muita dificuldade em distinguir entre um dado verdadeiro e um dado (levemente) falso.

Segundo, os atendentes têm uma (compreensível) tendência a, algumas vezes, ajustar os dados dos clientes sempre que eles sentem que é justo ter um determinado benefício, mas as regras oficiais não cobrem casos especiais. Novamente, um sistema de conhecimento perderia inteiramente esse ponto de ajuste nos dados do cliente. Poderia produzir sugestões corretas, mas que não levariam em conta circunstâncias especiais. Isso faria com que parte das proposições fossem difíceis de ser aceitas pelo tomador de decisão.

Tanto a inverdade como o caso especial são áreas delicadas do processo de tomada de decisão.

Estão fora do alcance de um sistema de conhecimento e, consequentemente, restringem seu escopo e usabilidade.

Finalmente, dado que o ponto de partida do projeto era a tomada de decisão, procederam-se estudos visando a estimar o volume de trabalho real necessário em cada etapa do processo. Durante duas semanas, os analistas acompanharam de perto o trabalho de pessoas em escritórios locais.

Nessas análises, foi verificado quão freqüentemente ocorrem problemas de tomada de decisão por conta da complexidade dos regulamentos e como isso se refletia na média geral de trabalho.

Esse aspecto era resultado do arquivamento em papel que à época a seguridade social utilizava. Muito tempo era gasto para encontrar arquivos perdidos de clientes, resolver ou contornar as mais variadas regras e procedimentos burocráticos.

A fim de se definir as relevâncias relativas das tarefas (Planilha OM-3), essas observações eram de fundamental importância. Elas produzem uma medida quantitativa clara do significado relativo das tarefas.

Se tomarmos como indicador os custos envolvidos no processo, é evidente que os condutores de custo e ineficiência são as tarefas de Arquivamento e Relatório e não a tomada de decisão.

O resultado mais surpreendente da análise é que a carga de trabalho não se deve à complexidade da tomada de decisão.

Mais de 60% do tempo é dispendido com as tarefas de arquivamento e relatório.

Ainda que o processo de tomada de decisão pudesse ser totalmente automatizado (o que é totalmente irrealista, dada a natureza dos ativos de conhecimento), o máximo que se ganharia seria 10% do custo total do processo.

Muitos melhoramentos modestos (mais realísticos e mais fáceis de alcançar, dado que são na ordem de apenas 10%) em arquivamento e relatório já produziriam como resultado um ganho semelhante para o processo geral da organização.

Portanto, é mais provável que o foco nessas tarefas resultará em um processo total mais rápido e na redução dos estoques de casos a atender.

MODELO DA ORGANIZAÇÃO Tomada de Decisão sobre a Viabilidade – OM5 (Schreiber. et al, 2002) Tomada de Decisão sobre a Viabilidade – OM5

Tomada de Decisão sobre a Viabilidade – OM5

As Planilhas OM-1, OM-2, OM-3 e OM-4 representam a totalidade dos componentes do Modelo da Organização na Metodologia CommonKADS. Como tal, permitem que o projeto de conhecimento contemple a visão geral da organização, nas áreas de seu escopo.

O passo seguinte consiste em sintetizar todos os elementos chave desse modelo em um documento, com base nos compromissos e decisões de gestão que deverão ser tomadas. Nesse estágio do projeto do sistema de conhecimento o tomador de decisão está focado nos seguintes aspectos:

Qual é a área de oportunidades mais promissora para aplicações, e qual é a melhor direção de solução?

Qual é a relação custo-benefício (viabilidade do negócio) ?

Há disponibilidade de tecnologia necessária para essas soluções e com que acessibilidade (viabilidade técnica) ?

Quais são as ações de projeto que devem ser tomadas a seguir (viabilidade de projeto)?

A Metodologia CommonKADS sugere a Planilha OM-5 para tratar desses aspectos.

Tomada de Decisão Sobre a Viabilidade – OM5a

Para uma dada área de problema/oportunidade e para uma solução sugerida, as seguintes questões devem ser respondidas:

Quão complexo, em termos de conhecimento estocado e processo de raciocínio a ser conduzido, é a tarefa a ser realizada pela solução de conhecimento considerada? Existem métodos e técnicas no estado-da-arte disponíveis e adequadas?

Há aspectos críticos envolvidos, relativos a tempo, qualidade, recursos necessários ou de outra natureza? Se sim, como tratá-los?

Estão claras as medidas de sucesso e como se testará a validade, qualidade e o grau de satisfação da solução?

Qual é a complexidade de relação com o usuário final (interfaces com usuário)? Há técnicas no estado-da-arte disponíveis e adequadas?

Qual é a complexidade de relação com outros sistemas de informação e outros recursos possíveis (interoperabilidade, integração de sistemas)? Há métodos e técnicas no estado-da-arte disponíveis e adequadas?

Há riscos e incertezas tecnológicas adicionais?

VIABILIDADE TÉCNICA

Que benefícios são esperados pel organização da solução considerada? Tanto benefícios econômicos como benefícios do negócio tangíveis devem ser identificados.

Qual é a extensão do valor adicional esperado?

O que é esperado em termos de custos da solução?

Como isso se compara com soluções alternativas possíveis?

Há necessidade de mudança organizacional?

Qual é a extensão dos riscos econômicos e de negócio e das incertezas envolvidas na direção de solução considerada?

VIABILIDADE DO NEGÓCIO Modelo da Organização Checklist para Documento para Decisão sobre Viabilidade - PLANILHA OM-5 PRIMEIRA PARTE

Tomada de Decisão Sobre a Viabilidade – OM5b

Foco : qual é o foco recomendado na área de problema-oportunidade identificada?

Solução Alvo qual é a direção de solução recomendada para essa área foco?

Quais são os resultados, custos e benefícios esperados?

Quais são as ações de projeto necessárias para se chegar lá?

Riscos . Se as circunstâncias dentro e fora da organização mudarem, sob que condições é aconselhável reconsiderar as decisões propostas?

AÇÕES PROPOSTAS

Há um compromisso adequado dos atores envolvidos (gerentes, especialisas, usuários, clientes, membros da equipe de projeto) para os passos seguintes do projeto?

Os recursos necessários em termos de tempo, orçamento, equipamento e equipe estão disponíveis?

Há conhecimento necessário e outras competências disponíveis?

As expectativas com relação ao projeto e seus resultados são realistas?

O projeto da organização e suas comunicações internas e externas são adequadas?

Há riscos ou incertezas adicionais ao projeto?

VIABILIDADE DO PROJETO Modelo da Organização Checklist para Documento para Decisão sobre Viabilidade - PLANILHA OM-5 SEGUNDA PARTE

Estudo de Caso: Modelo da Organização – Decisão sobre a Viabilidade – OM5 (Schreiber. et al, 2002)

Viabilidade do Negócio. No caso da seguridade social de Amsterdam, ficou claro que a construção de um sistema de conhecimento para tomada de decisão não irá, por si só, resolver o problema. Benefícios maiores são alcançados pela aceleração do processo como um todo, podendo-se esperar mais foco no melhoramento das tarefas de Arquivamento e Relatórios.

Indicadores quantitativos foram levantados na organização. Uma solução baseda em conhecimento seria limitada com relação à mudança necessária (e esperada) na organização. Iria requerer, também, uma estrutura de PC mais descentralizada, o que implicaria em mudanças nos escritórios locais.

Além disso, haveria a mudança no poder das pessoas, com os envolvidos com Atendimento perdendo sua capacidade de resolver casos especiais.

Se a decisão for a de se focar em Arquivo e Relatório, o impacto na organização tende a ser maior. O diagrama de processos identifica que vários departamentos desempenham um papel nessas tarefas, além delas ocorrerem em diferentes lugares do processo geral. Mesmo o centro de computação externo, fora do controle da organização, deveria ser envolvido.

Estudo de Caso: Modelo da Organização – Decisão sobre a Viabilidade – OM5 (Schreiber. et al, 2002)

Viabilidade Técnica. Os principais riscos tecnológicos estão associados em como o sistema de conhecimento trataria adequadamente os casos especiais de tomada de decisão (informações falsas e exceções às regras). É um exemplo muito interessante de conhecimento tácito nas organizações, difícil de explicar ou de formalizar computacionalmente. A solução sugerida não implica em tal risco.

Viabilidade do projeto. Para a solução via sistema de conhecimento, o risco tecnológico combinado com os benefícios limitados em termos de economia de tempo e custos traz preocupações sobre se é aconselhável contunuar com a sugestão inicial. Por outro lado, a solução com base em Arquivo e Relatório necessitaria assegurar-se da participação e compromisso de vários atores ou necessitaria restringir as mudanças de procedimentos a uma área mais restrita da organização.

Ações Propostas. Com base nos resultados do Modelo de Organização, a melhor proposta é redirecionar a solução inicial da área de tomada de decisão, simplificando workflow e procedimentos de arquivo e relatórios. Assim, propõe-se evitar o desenvolvimento do sistema de conhecimento inicial e se partir para as análise de gargalos na tarefas de arquivo, tratando mais efetivamente com o que está causando o acúmulo de casos na organização.