Criando Uma Arquitetura de Memória Corporativa Baseada em Um Modelo de Negócio

Nstor Adolfo Mamani Macedo
CRIANDO UMA ARQUITETURA DE MEMRIA CORPORATIVA BASEADA EM UM MODELO DE NEGCIO
Tese de Doutorado
Tese apresentada ao Programa de Ps-graduao em Informtica da PUC-Rio como requisito parcial para obteno do ttulo de Doutor em Informtica. Orientador: Julio Cesar Sampaio do Prado Leite Co-orientador: Teresia Diana Lewe van Aduard de Macedo-Soares
Rio de Janeiro Julho de 2003
Nstor Adolfo Mamani Macedo Criando uma Arquitetura de Memria Corporativa baseada em um Modelo de Negcio
Tese apresentada como requisito parcial para obteno do grau de Doutor pelo Programa de Ps-graduao em Informtica do Departamento de Informtica do Centro Tcnico Cientfico da PUC-Rio. Aprovada pela Comisso Examinadora abaixo assinada.
Prof. Julio Cesar Sampaio do Prado Leite Orientador Departamento de Informtica PUC-Rio Prof. Carlos Jos Pereira de Lucena Departamento de Informtica PUC-Rio
Prof. Karin Koogan Breitman Departamento de Informtica PUC-Rio
Prof. Luiz Marcio Cysneiros York University Toronto Ontario - Canada
Prof. Alvaro Cesar Pereira Barbosa Universidade Federal do Esprito Santo UFES
Prof. Ney Augusto Dumont "!#"$%& ')(0 0 $1 "%2 3% 0 547689A@CBA
Rio de Janeiro, 03 de julho de 2003
Todos os direitos reservados. proibida a reproduo total ou parcial do trabalho sem autorizao da universidade, do autor e do orientador.
Nstor Adolfo Mamani Macedo Graduou-se em Cincias Contbeis na Universidad Inca Garci-laso de la Vega (UIGV-Peru) e em Cincia da Computao na Universidad Nacional Mayor de San Marcos (UNMSM-Peru). Nesta ltima tambm obteve a Licenciatura em Cincia da Computao. Mestre em Administrao pela Escuela de Administracin de Negcios para Graduados (ESAN-Peru) e Mestre em Informtica pela PUC-Rio. Realizou trabalhos de consultoria em administrao, finanas e sistemas de informao em diversas empresas e instituies no Peru.
Ficha Catalogrfica Mamani Macedo, Nstor Adolfo
Criando uma arquitetura de memria corporativa baseada em um modelo de negcio/ Nstor Adolfo Mamani Macedo; orientador: Julio Cesar Sampaio do Prado Leite; co-orientador: Teresia Diana Lewe van Aduard de MacedoSoares. Rio de Janeiro: PUC, Departamento de Informtica, 2003.
172 p.: il. ; 30,0 cm
1. Tese (doutorado) Pontifcia Universidade Catlica do Rio de Janeiro, Departamento de Informtica.
Inclui referncias bibliogrficas.
1.Informtica Teses. 2. Gesto do Conhecimento. 3. Memrias corporativas. 4. Modelos de negcio. 5. Sistemas de informao. 6. Ontologias e agentes. I. Leite, Julio Cesar Sampaio do Prado, Macedo-Soares, Teresia Diana Lewe van Aduard de. II. Pontifcia Universidade Catlica do Rio de Janeiro. Departamento de Informtica. IV. Ttulo. CCD: 004
Em memria de meu pai.
Agradecimentos
Ao meu orientador Professor Julio Cesar Sampaio do Prado Leite pelo estmulo e confiana na realizao deste trabalho na rea de Gesto do Conhecimento. minha co-orientadora Professora Teresia Diana Lewe van Aduard de MacedoSoares pelo apoio e ensinamentos na rea de estratgia de negcios. Ao CNPq e PUC-Rio, pelos auxlios concedidos, sem os quais este trabalho no poderia ter sido realizado. Ao Professor Carlos Jos Pereira de Lucena por ter me dado a oportunidade de aprender novos conhecimentos sobre ontologias e agentes. Aos Professores da Comisso Examinadora. Ao amigo Srgio Crtes pelo apoio dado, primeiro durante o Mestrado e depois no percurso do Doutorado. Aos amigos Fausto Maranho e Luis Antonio Pereira, pelo apoio durante grande parte do doutorado e com quem compartilhei a nossa lembrada sala 420. Aos meus colegas da PUC-Rio. A todos os professores e funcionrios do Departamento pelos ensinamentos e ajuda recebida. Aos Professores Roberto Avila e Agripino Garcia da UNMSM (Lima, Peru) pela
motivao para seguir estudos de ps-graduao no Brasil.
Resumo
Mamani-Macedo, Nstor Adolfo: Leite, Julio Cesar Sampaio do Prado, Macedo-Soares, Teresia Diana Lewe van Aduard de. Criando uma Arquitetura de Memria Corporativa baseada em um Modelo de Negcio. Rio de Janeiro, 2003. 145p. Tese de Doutorado Departamento de Informtica, Pontifcia Universidade Catlica do Rio de Janeiro. O presente trabalho uma proposta para a criao de uma arquitetura geral de memria corporativa. A mesma tem trs camadas: fontes, middleware e repositrios. Primeiro, criou-se um modelo conceitual de negcio baseado em teorias de administrao de negcios e organizadas sob uma abordagem de ontologias, esse modelo denominou-se de Organizational Baseline (OB). Segundo, utilizou-se as abordagens de sistemas multiagentes como meio para organizar nossa proposta de arquitetura. O OB o principal repositrio onde se armazena informao relevante da organizao, a qual extrada a partir dos sistemas legados, bancos de dados, sites na internet ou mesmo elicitadas dos seres humanos por meio de entrevistas e formulrios. O modelo conceitual est baseado nas abordagens de anlise estratgica positioning e emphasizing efficiency, junto com a anlise de funes e o estudo do gerenciamento da qualidade total.
Palavras-chave
Informtica Teses, Gesto do Conhecimento, Memrias Corporativas, Modelos de Negcio, Sistemas de Informao, Ontologias e Agentes.
Abstract
Mamani-Macedo, Nstor Adolfo; Leite, Julio Cesar Sampaio do Prado; Macedo-Soares, Teresia Diana Lewe van Aduard de. Building an Architecture Strategic Corporate Memory based on a Business Model. Rio de Janeiro, 2003. 145p. Phd. Thesis Departamento de Informtica, Pontifcia Universidade Catlica do Rio de Janeiro.
This work presents a proposal for building corporate memory architecture. It has three layers: sources, middleware and repositories. First, we create an
conceptual enterprise model, named Organizational Baseline (OB), based on theories of business management and organized in accordance with an approach of ontology. Second, we use multi agents system as a means to organize our proposal of architecture. The OB is the main component, where we store whole relevant information for the organization; it can be extracted from legacy systems, databases, Internet sites or human beings. The conceptual enterprise model is based on constructs elicited from positioning and emphasizing efficiency views of strategic analysis, together with function analysis and total quality management.
Keywords
Computer Science Thesis, Knowledge Management, Corporate Memory, Business Model, Information System, Ontology and Agents.
Sumrio
1. Introduo 1.1. Motivao 1.2. Problemas 1.3. Objetivo da Tese 1.4. Organizao da Tese 2. Estratgia Proposta 3. Reviso da Literatura 3.1. Know More Abecker et al. 3.2. Experience Factory Basili et al. 3.3. AskMe Enterprise AskMe Corporation 3.4. XpertRule Knowledge Builder
15 15 19 23 26 28 31 31 32 33 35 35 36 40 40 41 42 44
Attar Software Limited
3.5. QuestMap The Soft Bicycle Company 3.6. Avaliao das propostas e produtos 4. Referencial Terico 4.1. Gesto do Conhecimento 4.1.1. Uma aproximao definio de Conhecimento 4.1.2. O que Gesto do Conhecimento 4.2. Estratgia de Negcios
4.2.1. A abordagem positioning ou de Estrutura-Conduta-Desempenho 45 4.2.1.1. O Modelo de Porter 4.2.1.2. O Modelo Ambiental 4.2.2. A abordagem emphasizing efficiency ou a que enfatiza a eficincia 4.2.2.1. A viso resource-based view 4.2.2.2. O framework dynamic capabilities 4.3. A anlise de processos e o TQM 4.4. As Metforas de Morgan 4.4.1. A Organizao vista como Mquina 4.4.2. A Organizao vista como Organismo 4.4.3. A Organizao vista como Crebro 4.4.4. A Organizao vista como Cultura 49 49 51 52 53 54 54 55 55 45 47
4.4.5. A Organizao vista como Sistema Poltico 4.4.6. A Organizao vista como Priso Psquica 4.4.7. A Organizao vista como Fluxo e Transformao 4.4.8. A Organizao vista como Instrumento de Dominao 4.5. Ontologias 4.5.1. Definies 4.5.2. Componentes de uma Ontologia 4.5.3. Tipos de Ontologia 4.5.4. Ontologia da Organizao Empresarial 4.5.5. Mtodos para a Descrio de Ontologias 4.5.5.1. TOVE (Toronto Virtual Enterprise) 4.5.5.2. Methodology for Building Ontologies 4.5.5.3. SENSUS 4.5.5.4. A Metodologia de Bernaras et al. 4.5.5.5. Methontology 4.6. Arquiteturas de Software 4.6.1. Definio 4.6.2. Caractersticas 4.6.3. O Processo de Criao de uma Arquitetura 4.6.4. Princpios Arquiteturais 4.6.5. Estilos Arquiteturais 4.7. A Tecnologia de Agentes 4.7.1. Agentes Conceitos 4.7.2. Propriedades 4.7.3. Tipos de Agentes 4.7.4. Sistemas Multi-Agentes 4.7.5. A Arquitetura de um MAS 4.7.5.1. O Processo de Matchmaking 4.7.5.2. O Processo de Brokering 4.8. Metodologia MESSAGE 4.8.1. O Diagrama da Organizao 4.8.2. O Diagrama do Domnio de Informao 4.8.3. O Diagrama de Meta/Tarefa 4.8.4. O Diagrama de Agente/Papel
55 56 56 57 57 58 59 61 61 63 63 63 64 64 65 65 66 66 67 67 68 69 70 71 72 74 75 76 77 78 78 79 79 79
4.8.5. O Diagrama de Interao 4.8.6. A Arquitetura do Agente MESSAGE 4.9. A Tcnica do CBR 5. Resultados da Estratgia Proposta 5.1. A Ontologia Empresarial orientada Estratgia de Negcios 5.1.1. Identificando o Propsito 5.1.2. O Nvel de Formalidade 5.1.3. O Escopo da Ontologia 5.1.4. Criando a Ontologia 5.1.5. Avaliao 5.1.6. Documentao 5.2. O Modelo de Negcio O Organizational Baseline 5.3. A Arquitetura Genrica do SCM (Strategic Corporate Memory) 5.3.1. A Camada de Fontes 5.3.2. A Camada Middleware ou de servios 5.3.3. A Camada de Repositrios 5.4. Desenvolvendo a Arquitetura de Software (Middleware) 5.4.1. O Diagrama Organizacional do SCM 5.4.2. O Diagrama de Meta / Tarefa 5.4.3. O Diagrama Agente / Papel 5.4.4. O Diagrama de Interao 5.4.5. Estruturando os Resultados de acordo aos diagramas organizacional, meta / tarefa, agente / papel e interao 5.4.6. O Diagrama de Domnio 5.5. Descrio dos Componentes da Arquitetura de Software
80 80 82 84 84 85 86 87 87 95 95 96 100 102 103 104 107 108 109 113 114
115 116 118
5.5.1. O Componente Agente Plataforma de Controle e Comunicao 121 5.5.1.1. O Facilitador de Diretorio (DF) 5.5.1.2. O Sistema de Gerenciamento de Agentes (AMS) 5.5.1.3. O Canal de Comunicao de Agentes (ACC) 5.5.1.4. A Comunicao de Agentes 5.5.1.5. Negociao de Agentes 5.5.1.6. Protocolos de Negociao 5.5.2. O Componente Agente Interface 5.5.3. O Componente Agente Usurio 123 123 124 124 126 126 127 131
5.5.4. O Componente Agente Descobrimento 5.5.5. O Componente Busca
133 136
5.5.6. O Componente Agente Armazenamento e Disseminao do LOG 138 5.5.7. O Componente Agente Armazenamento de Lies Aprendidas 140 5.5.7.1. Estruturando a Base de Experincias 5.5.7.2. Operaes do Componente Agente de Lies Aprendidas 6. Apresentao do Prottipo 6.1. O Caso da Multicom 6.2. Os Servios do SCM 6.2.1. Descrio do Prottipo: O Servio de Busca 6.2.2. Descrio do Prottipo: O Servio de Disseminao 7. Concluses, Contribuies e Trabalhos Futuros 7.1. Concluses 7.2. Contribuies 7.3 Trabalhos Futuros 8. Referncias Bibliogrficas 141 143 145 146 146 148 152 158 158 163 164 166
Lista de figuras
Figura 1.1 - Memria Organizacional Figura 2.1 - Metodologia para o desenvolvimento da Arquitetura Figura 2.2 - O Contexto do Organizacional Baseline
24 28 29
Figura 4.1 - A Organizao e seus ambientes (adaptado de [Stoner85]) 44 Figura 4.2 - Cadeia do Valor Figura 4.3 - Interao entre agentes no processo Marchmaking Figura 4.4 - Interao entre agentes no processo Brokering Figura 4.5 - Arquitetura em camadas do agente MESSAGE Figura 5.1 - Ontologia da Organizao e do Ambiente Organizacional 50 76 77 81 89
Figura 5.2 - Ontologia das Foras Competitivas e da Anlise do Negcio 92 Figura 5.3 - Ontologia da Estratgia Global e dos Processos Figura 5.4 - Ontologia das Funes Figura 5.5 - Os conceitos da Ontologia do Negcio no Protg Figura 5.6 - O Arquivo RDF Schema da Ontologia (vista parcial) Figura 5.7 - O Modelo E-R do Organizacional Baseline do SCM Figura 5.8 - Arquitetura de Camadas do SCM Figura 5.9 - Viso Arquitetural do Strategic Corporate Memory Figura 5.10 - Viso Estrutural dos Repositrios Figura 5.11 - Diagrama do SCM dentro da Organizao Figura 5.12 - Diagrama de Familiaridade do SCM Figura 5.13 - Requisitos No Funcionais do SCM Figura 5.14 - Requisitos No Funcionais: Preciso da Informao Figura 5.15 - Requisitos No Funcionais: Preciso da Escrita Figura 5.16 - Requisitos Funcionais e No Funcionais: Uma primeira aproximao para a determinao dos Componentes do SCM Figura 5.17 - Tarefa: Elicitar Conhecimento Figura 5.18 - Tarefa: Preparar o Questionrio 111 111 111 93 94 96 98 99 101 103 106 108 109 109 110 110
Figura 5.19 - Outra Viso: Os servios do SCM (requisitos funcionais) 112 Figura 5.20 - Diagrama Estrutural de Delegao 113
Figura 5.21 - Diagrama de Interao entre os agentes Extrator e Busca 114 Figura 5.22 - A Viso de Projeto do SCM Figura 5.23 - A Viso de Domnio do SCM Figura 5.24 - O Processo de Consulta do SCM Figura 5.25 - O Processo de Disseminao Automtica do SCM Figura 5.26 - Os Componentes da Arquitetura de Software do SCM Figura 5.27 - O Protocolo FIPA-iterated-contract-net Figura 5.28 - O Componente Agente Interface Figura 5.29 - O Componente Agente Usurio Figura 5.30 - O Componente Agente de Descobrimento Figura 5.31 - O Componente Agente de Busca 115 116 117 117 119 127 128 132 135 137
Figura 5.32 - O Componente Agente Armazenamento e Disseminao 139 Figura 5.33 - O Componente Agente Armazenamento de Lies Aprendidas Figura 6.1 - Uso do SCM Figura 6.2 - Estrutura do repositrio Ontologia do negcio Figura 6.3 - Instncias da Ontologia do negcio Figura 6.4 - O Servio de Busca Figura 6.5 - Formulrio da Entidade Companhia (Interface) Figura 6.6 -Tela de Confirmao dos Dados Ingressados Figura 6.7 - Registros log do SCM Figura 6.8 - Estrutura do Arquivo LOG Figura 6.9 - Estrutura da Tabela Usurio Figura 6.10 - Instncias de usurio Figura 6.11 - e-Mail recebido pelo Consultor Srgio Cortes Figura 6.12 - e-Mail recebido pelo Gerente de TI Fausto Maranho 144 149 150 150 151 153 154 155 155 156 156 157 157
Lista de Tabelas
Tabela 1.1 - Vantagens decorrentes do uso do conhecimento Tabela 3.1 Quadro Comparativo: Ferramentas de Gesto do Conhecimento Tabela 4.1 - Tipos de Agentes Tabela 4.2 - Formas de consulta temporal de um agente Tabela 4.3 - Funes dos agentes no processo Matchmaking Tabela 4.4 - Funes dos agentes no processo Brokering Tabela 4.5 - Conjunto de ndices definidos para a medida sim Tabela 5.1 - O conceito Companhia e as metforas de Morgan Tabela 5.2 - Uma Instncia do Conceito Companhia Tabela 5.3 - O Conceito Concorrncia e as metforas de Morgan Tabela 5.4 Uma instancia do Conceito Concorrentes Tabela 5.5 Conceito Objetivos Tabela 5.6 Esquema Agente / Papel para o Agente Extrator Tabela 5.7 Atos Comunicativos na Especificao FIPA Tabela 5.8 Estrutura do Registro log Tabela 5.9 Exemplo de um problema e seu contexto Tabela 5.10 A Base de Casos, seus atributos e relevncia dado o problema Tabela 5.11 Recuperao de um caso dado um problema
21
38 72 73 76 77 83 90 91 92 93 94 114 125 138 142
143 143
1 Introduo
1.1 Motivao Como resultado da globalizao da economia percebe-se que o ambiente que rodeia as organizaes est caracterizado pela mudana contnua de regulamentaes, tecnologia e mercado. Para acompanhar essas mudanas, as organizaes precisam evoluir rapidamente e com segurana. Entretanto, essa evoluo requer que estas saibam aprimorar a sua tomada de decises nesse contexto de turbulncia, o que obriga a existncia de informaes confiveis, atuais e de fcil acesso aos tomadores de deciso. Para lidar com este ambiente, Xu et al. (2003) propem um sistema de radar corporativo para adquirir informaes estratgicas, porm no apontando questes da sua implementao. Na literatura de estratgia de negcios (Alpander & Lee, 1995; Lewis, 1996; Van de Ven & Poole, 1995; Vollman, 1996) existe o consenso de que a mudana contnua necessita ser gerenciada com estratgias dinmicas, o qual enfatizado por Day et al.(1997) quando ressalta a importncia do reconhecimento explicito deste dinamismo na formulao da estratgia competitiva. Uma viso estratgica dinmica passa por um adequado entendimento da concorrncia atual e futura, e pelo reconhecimento da influncia ou do impacto, das ameaas e oportunidades do ambiente externo sobre as organizaes. As deficincias refletem-se nas oportunidades que deixaram de ser atendidas e nos erros estratgicos cometidos. claro que a qualidade da tomada de decises estratgicas est baseada na qualidade da informao disponvel. No entanto, existem dificuldades para que uma organizao possa disponibilizar a sua informao estratgica, de uma forma estruturada e de fcil acesso, diretoria e aos executivos, com o intuito de garantir uma efetiva tomada de decises. Isto se d, principalmente, em funo do fato de que a informao no-estruturada, de natureza crtica e em muitos casos, de grande volume. Como resultado, faz-se necessrio que as organizaes possuam modelos e ferramentas que facilitem tanto a aquisio e o armazenamento da
Criando uma Arquitetura de Memria Corporativa baseada em um Modelo de Negcio
16
informao, quanto seu compartilhamento e disseminao, facilitando assim, sua analise e seu gerenciamento. No livro The Knowledge-Creating Company, Nonaka & Takeuchi, (1995) discutem os fatores sociais que influenciam o processo de criao de conhecimento. A premissa ou hiptese subjacente ao seu trabalho que o conhecimento humano criado e expandido em termos de quantidade e qualidade por meio da interao social entre o conhecimento tcito e o conhecimento explcito. Obviamente, o conhecimento explicito mais fcil de elicitar porque est, em alguma medida, mais ou menos estruturado e pode ser encontrado em bancos de dados de Recursos Humanos, Finanas, Contabilidade; o conhecimento tcito mais difcil de elicitar embora alguns tipos possam ser encontrados em sistemas especialistas, sistemas de informao baseados em questes, arquivos de melhores prticas ou de lies aprendidas (Abecker et al., 1998). Tem-se notado tambm que muita informao e conhecimento relevantes encontram-se dispersos na organizao, seja em documentos impressos, meios magnticos ou simplesmente na cabea dos seus membros, pela existncia de grupos formais e informais, dificultando seu acesso e disseminao oportuna. Assim sendo, crtico formular um modelo organizacional que inclua construtos que possam ajudar a empresa a aprimorar sua tomada de decises, seu desenvolvimento organizacional e consequntemente seu aprendizado. O aprendizado organizacional refere-se s melhoras surgidas da experincia no desempenho das tarefas organizacionais (Argyris & Schon, 1978). Documentos como os de gerenciamento da qualidade total (Total Quality Management TQM) e ISO 9000 podem ser tratados de forma independente, mas fazendo parte do modelo como um todo. Nos ltimos anos, como resultado da revoluo tecnolgica, os requisitos para que uma organizao sobreviva e atinja o sucesso mudaram. Revalorizou-se o papel do trabalhador na organizao, de forma tal que hoje se fala dele como o ativo mais valioso e importante a ser tomado em conta. Ele possui o Know-How (competncias e capacidades) para fazer as coisas atravs do conhecimento adquirido por meio de treinamentos e da sua experincia no dia-a-dia. Ao mesmo tempo, um nmero cada vez maior de empresas perceberam o quanto importante saber o que elas sabem e como aprender, para serem capazes de tirar o mximo proveito de seus ativos de conhecimento. Assim, a capacidade de gerenciar,
17
disseminar e criar novos conhecimentos com eficincia, eficcia e economia fundamental para que uma organizao se coloque em posio de vantagem competitiva em relao aos seus concorrentes. Fica evidente que em um mercado cada vez mais competitivo o sucesso nos negcios depende, basicamente, da qualidade do conhecimento que a empresa possui. Nesse sentido, o conhecimento institucionalmente organizado deve colaborar para uma melhora na tomada de decises, refletida na forma de aes poltico-econmicas e administrativas. Por outro lado, cabe ressaltar que existem outras reas do conhecimento humano que tambm precisam desse tipo de informao e conhecimento, embora com objetivos diferentes. A Engenharia de Software, em alguns casos, tem apresentado srios problemas de desenvolvimento, uma vez que alguns projetistas tm ignorado a importncia das questes organizacionais no projeto de sistemas de informao ... (assim)... muitas das dificuldades encontradas ocorreram, no em funo de limitaes na tecnologia, mas em funo do descaso com os requisitos organizacionais, (Dobson & Strens, 1994, p. 158). A crescente importncia das abordagens socio-tcnicos para a elicitao dos requisitos de informao evidenciada pela literatura publicada nos ltimos anos, especialmente pelos artigos apresentados nas conferncias da rea tal como ICRE (International Conference on Requirement Engineering), RE (IEEE International Symposium on Requirement Engineering), WER (Workshop em Engenharia de Requisitos), IDEAS (Workshop Iberoamericano de Engenharia de Requisitos e Ambientes de Software). Estas abordagens argumentam que a busca para estabelecer requisitos de informao no pode ser reduzida a um processo racional ou produo de especificao tcnica ... especialmente na atual turbulncia organizacional e de ambientes inter-organizacionais (Carroll, 1997). A Engenharia de Requisitos, enquanto sub-rea da Engenharia de Software, uma disciplina que procura sistematizar o processo de definio de requisitos por meio da utilizao de uma combinao de mtodos, tcnicas e ferramentas. A definio de requisitos a atividade inicial do processo de desenvolvimento de software e exerce um grande impacto na qualidade do produto final. Assim, do ponto de vista da Engenharia de Requisitos, o contexto organizacional o ambiente de onde so obtidos os requisitos para definio dos sistemas de informao e de software. Vale ressaltar, que antes de iniciar a elicitao de requisitos de qualquer sistema importante que o engenheiro de requisitos tenha
18
uma viso global da organizao, enfatizando-se aspectos como o ambiente organizacional, legislao, concorrncia, etc., com o objetivo de visualizar suas ligaes com outros sistemas e com as estratgias e tticas da organizao. A seguir, apresentado como as diferentes definies de Engenharia de Requisitos salientam a relevncia do contexto do sistema, reconhecendo o envolvimento dos aspectos tcnicos e sociais, explicita ou implicitamente (Jirotka & Goguen, 1994):
Sommerville (1989) diz que a aquisio e anlise de requisitos o processo de estabelecer os servios que o sistema deve fornecer e as restries sob as quais deve operar. Davis (1990) sugere que a Engenharia de Requisitos a anlise, documentao e evoluo contnua das necessidades do usurio e do comportamento externo do sistema a ser criado. Goguen (1992) declara que os requisitos so propriedades que um sistema deve ter a fim de satisfazer as necessidades do ambiente no qual este ser utilizado. Leite (1994) destaca que o processo de definio de requisitos ocorre em um contexto, denominado o Universo de Informaes (UdI), que o contexto no qual o software ser desenvolvido e operado.
A informao do contexto est embutida nas estruturas, rotinas e procedimentos da organizao; em seu organograma; em suas historias, mitos, linguagens e cultura; nas suas atitudes individuais e de grupo; em suas redes sociais formais e informais; e assim por diante. Morgan (1996) trata desta questo em Imagens da Organizao. Acredita-se que os esforos envolvidos para a elicitao dessa informao so valiosos, pois o que se procura aprimorar a elicitao de requisitos organizacionais, bem como os requisitos funcionais e no funcionais, melhorando assim o processo de desenvolvimento dos sistemas de informao. Carroll (1997) observa que necessrio reconhecer que o problema bsico na Engenharia de Requisitos que trata-se de um problema de engenharia total de sistemas, o qual envolve, sob todos os pontos de vista, todos os requisitos do sistema a desenvolver (estratgico, organizacional, financeiro, operacional, tecnolgico, comercial e ambiental). Nessa linha de pensamento, Jarke et al. (1998) apresentam uma proposta interessante, vinculando os aspectos
19
organizacionais (polticas e metas) aos requisitos nos nveis estratgico, ttico e operacional, usando cenrios. de supor que a existncia de um modelo organizacional de negcio possa ser de grande ajuda na elicitao de requisitos, em particular dos requisitos organizacionais. Esse modelo de negcio seria a base para a criao de um baseline organizacional onde se armazenasse esse tipo de informao. O baseline na realidade um repositrio de conhecimento, fazendo a funo de uma memria organizacional.
1.2 Problemas Diversos autores, com perspectivas diferentes, salientam a importncia da organizao dispor de informaes estratgicas, tanto do ambiente externo e interno como de suas competncias e experincias, com o propsito de auxili-las no desenvolvimento de adequadas estratgias de negcios em ambientes de mudana contnua, disseminao do conhecimento e elicitao de requisitos
organizacionais. Essa preocupao pela gesto desses ativos intangveis compartilhada tanto pela rea de negcios como da engenharia de software, pois ambas esto interessadas em possuir informaes e conhecimentos relevantes sobre a organizao. No nosso ponto de vista, o conhecimento quando elicitado e armazenado transforma-se em informao; essa premissa norteia o presente trabalho. A gesto dos ativos intangveis chamada na literatura de Gesto do Conhecimento. Embora no exista uma definio exata, um entendimento ou conceituao bastante difundido que a gesto do conhecimento o processo atravs do qual as organizaes geram valor a partir de seus ativos intelectuais e de conhecimento, onde conhecimento, em uma viso restrita, pode ser definido como o know-how que possui a organizao, o qual reflete-se nas suas habilidades e capacidades, as mesmas que vo lhe ajudar a atingir uma vantagem competitiva sustentvel. No entanto, importante ressaltar que o conceito de gesto do conhecimento tem um sentido mais amplo, pois envolve tanto aspectos gerenciais, os quais no sero tratados aqui, como aspectos tecnolgicos, o caso das ferramentas que podem ser utilizadas para ajudar na obteno do sucesso
20
dessa gesto. Na literatura (Souza, 2002) encontram-se algumas definies de gesto do conhecimento, as quais so destacadas a seguir:
Sveiby (1997) diz que gesto do conhecimento o nome dado ao conjunto de prticas que visam manuteno do conhecimento nas organizaes. Murray (1996) declara que a gesto do conhecimento uma estratgia que transforma bens intelectuais da organizao informaes registradas e o talento dos seus membros em maior produtividade, novos valores e aumento de competitividade. Malhotra (2002) define a gesto do conhecimento como: Uma viso, baseada no conhecimento dos processos de negcio da organizao, para alavancar a capacidade de processamento de informaes avanadas e tecnologias de comunicao, via transformao da informao em ao por meio da criatividade e inovao dos seres humanos, para afetar a competncia da organizao e sua sobrevivncia em um crescente de imprevisibilidade.
Por outro lado, estudiosos do nvel de Davenport & Prusak (1998) tambm no definem o termo gesto do conhecimento, mas declaram que as atividades principais desta so a criao, o acmulo e a transferncia do mesmo. Liebowitz (1999) define a transferncia como o ato de transformar experincias e know-how de pessoas e grupos em conhecimento organizacional. Uma forma de operacionalizar o processo de Gesto do Conhecimento mediante a criao de um Sistema de Gesto do Conhecimento, o qual definido pela Gartner Group (1998) como: um processo e uma infra-estrutura que visam apoiar a gerao, coleta, assimilao e utilizao tima do conhecimento. A primeira parte dessa definio esta orientada gesto administrativa e a segunda aos recursos utilizados, sendo um deles as pessoas envolvidas e o outro as tecnologias de informao utilizadas. Entre as tecnologias temos a criao de ferramentas que ajudem ao suporte de todo esse processo. Embora seja conhecida e aceita a importncia de saber como manter, gerenciar e compartilhar o conhecimento, poucas organizaes contam com um adequado sistema de gesto do conhecimento estratgico, o qual inclua um instrumento que faa a funo de memria organizacional, pois os sistemas existentes so na maioria dos casos aplicaes de suporte aos processos de negcio ou aos seus processos de apoio. No entanto, nos ltimos anos, algumas grandes empresas de porte como Xerox, Ford, Buckman Labs, Texas Instruments,
21
Hoffman-LaRoche e Honeywell tm comeado a usar seu ativo mais valioso e at ento sub-utilizado: o conhecimento coletivo dos seus empregados, atravs de ferramentas que ajudam a gerenciar esse conhecimento, resultando em substanciais melhorias nos seus processos, conforme mostra a Tabela 1.1. Vale ressaltar que estes esforos esto orientados basicamente ao conhecimento operacional e, em alguma medida, ao nvel ttico, mas dando pouca importncia ao aspecto estratgico (AskMe, 2001).
Companhia Xerox
Explicao Acesso s lies aprendidas dos tcnicos
Resultados nos Processos 5-10% poupana nos custos de mo de obra e suprimentos (componentes) US$ 1.25 bilho em poupana A venda de novos produtos aumentou em 50%. Respostas s consultas dos clientes diminuiu a horas, antes era contabilizado em dias Ganhos de US$ 500 milhes em um ano ao obter uma capacidade de planta ociosa.
Ford Buckman Labs
Acesso s melhores prticas Permite encontrar aos empregados com
colegas
experincia e fazer perguntas Texas Instruments HoffmanLaRoche Acesso s melhores prticas
Captura
acesso
O tempo de aprovao do FDA (Federal Drugs Administration) reduziu-se de trs anos a 9 meses. Aumento de 46% na taxa de propostas ganhas. Os custos foram reduzidos em 35% aproximadamente.
conhecimento
relacionado
previamente aprovado Honeywell Cria, captura, compartilha e utiliza conhecimento organizacional
Tabela 1.1 Vantagens decorrentes do uso do conhecimento (AskMe, 2001)
Todas essas condies impem a necessidade da existncia de uma memria corporativa que esteja baseada em um modelo organizacional que permita expressar os aspectos citados, principalmente os referentes a situaes estratgicas. No entanto, observa-se que a rea de modelagem organizacional carece de modelos que atendam essas caractersticas especficas. Uma forma de satisfazer essa necessidade de contar com um instrumento de memria corporativa que facilite o armazenamento e recuperao da informao estratgica o estabelecimento prvio de um modelo de negcio que envolva as questes anteriormente referenciadas. Na literatura de memrias corporativas (AskMe, 2001; Abecker et al., 1998; Basili & McGarry, 1997; Attar, 2003; Gdss, 2003) percebe-se que estas tm negligenciado ou dado pouca importncia utilizao de modelos de negcio que
22
ajudem a lidar com essa problemtica e atendam satisfatoriamente a esses requisitos. Estes tm sido, fundamentalmente, repositrios de documentos e de dados orientados aos processos. Vale enfatizar que a operacionalizao de uma memria corporativa no uma tarefa trivial, pois conhecimento relevante tem que ser identificado, modelado e armazenado. No mbito acadmico, no entanto, tm-se desenvolvido algumas propostas (Chiu, 2003; Fiorini et al., 1996), as quais, embora tenham utilizado muitos conceitos disseminados pela mdia como Gerenciamento da Qualidade Total (TQM-Total Quality Management), Reengenharia de Negcios e Planejamento Estratgico, tm ignorado a existncia de abordagens mais especificas sobre como as organizaes se comportam e interagem com seu ambiente externo e interno, e como esse conhecimento poderia facilitar a elicitao dessas entidades e atributos relevantes organizao. Duas das abordagens mais conhecidas e estudadas com certa nfase no mbito acadmico e de negcios, so a de posicionamento -positioning (Porter, 1980; Porter, 1985) e a que enfatiza a eficincia emphasizing efficiency (Day et al., 1997; Teece et al., 1997), as quais tentam explicar, a partir de uma tica estratgica, como as organizaes podem alcanar uma vantagem competitiva no mercado. Nos ltimos anos, surgiu dentro desta ltima perspectiva o framework Dynamic Capabilities de Teece et al. (1997), o qual ressalta a explorao das existentes competncias internas e externas especificas firma em ambientes de mudana contnua, salientando a importncia da gesto do conhecimento organizacional. Outra abordagem no menos importante a de Imagens da Organizao (Morgan, 1996) a qual olha organizao sob as metforas de mquina, organismo, crebro, cultura, sistema poltico, priso psquica, fluxo-e-transformao, bem como de instrumento de dominao. Uma das vantagens de possuir uma memria corporativa como parte de um sistema de gesto do conhecimento que esta encoraja o aprendizado organizacional. Isso resultado do fato que a memria corporativa como um todo, no s armazena construtos da rea de negcios como tambm armazena lies aprendidas, fazendo com que os membros da organizao aprendam com a mesma. Isto corroborado por Tsang (1997) quando afirma que as lies aprendidas no passado, se apropriadamente armazenadas na memria
organizacional, so uma importante fonte de conhecimento para que os membros
23
da organizao possam obt-la. Nessa mesma linha Simon (1991) afirma que toda aprendizagem toma lugar dentro da cabea do ser humano e como uma organizao pode somente aprender por meio de seus membros, conclui que o vnculo entre o aprendizado individual e organizacional ocupa uma posio crtica em qualquer teoria de aprendizagem organizacional. Finalmente, Walsh &
Ungson (1999), declaram que a memria organizacional ou corporativa se refere informao armazenada a partir da histria da organizao e que pode ser recuperada para suportar decises do presente. No entanto, o aprendizado conduzir automaticamente a um melhor desempenho s quando o conhecimento obtido seja exato (Tsang, 1997) e isto depende de uma srie de fatores, tais como os mtodos usados para coletar e analisar os dados, o sistema de interpretao existente na organizao (Daft & Weick, 1984) e seu arcabouo ou frame de referncia. (Shrivastava & Schneider, 1984).
1.3 Objetivo da Tese Como descrito na seo anterior um sistema de gesto do conhecimento tem dois componentes: o componente gerencial ou administrativo e o componente tecnolgico. Tem-se notado tambm, que embora as ferramentas de suporte ao processo de gesto do conhecimento negligenciem os aspectos estratgicos focando principalmente o aspecto operacional e o tratamento de documentos, estas contriburam para que as organizaes alcancem resultados altamente positivos. Por exemplo, s o acesso s melhores prticas pelos funcionrios da Ford, representaram economias de US$.1.25 bilhes segundo dados da AskMe Corporation (vide Tabela 1.1). O objetivo desta tese propor uma arquitetura de memria corporativa com nfase nas questes estratgicas, da o nome de Memria Corporativa Estratgica (Strategic Corporate Memory SCM), a qual leva em considerao a situao de competitividade do mercado global. Argumenta-se que os avanos de modelagem tanto na Engenharia de Software como na Engenharia de Requisitos, podem servir de base para a proposta de uma arquitetura de Memria Corporativa adequada s condies de mudana contnua.
24
A arquitetura do SCM ter como componente principal o Organizational Baseline (Mamani-Macedo & Leite, 2001), o qual o repositrio de conhecimento que visa satisfazer esse leque de necessidades de informao, com estrutura baseada no modelo conceitual do negcio. A modelagem (abstrao) do modelo do negcio ser conduzida tendo como fonte de inspirao as diferentes abordagens da anlise estratgica, notadamente as vises positioning (Porter, 1980; Porter, 1985) e emphasizing efficiency (Day et al., 1997; Teece at al., 1997), utilizando-se, portanto, uma viso integrada dessas propostas e enriquecida com uma anlise dos processos e funes sob uma orientao de qualidade total e das metforas sobre as imagens da organizao (Morgan, 1996). Junto ao baseline organizacional tambm ser criado um repositrio de casos com experincias passadas. Ambos repositrios facilitaro, assim, o compartilhamento do conhecimento e experincias em todos os nveis hierrquicos da organizao, promovendo tanto a criao de novo conhecimento como a melhora das habilidades e capacidades de seus membros, conforme apresentado na Figura 1.1.
Organizao Tomada de Decises
Competitiva Estratgia Dinmica
Elicitao de Requisitos Organizational Baseline Case Base

Informao estratgica (cultura, DO, TQM pensamentos, atitudes, valores, ambiente) estruturada e no estruturada, obtida do ambiente externo e interno
DO: Desenvolvimento Organizacional TQM: Total Quality Management (Gerenciamento da Qualidade Total)
Disseminao do Conhecimento
Figura 1.1 Memria Organizacional
Para a organizao do modelo do negcio ser utilizada uma abordagem baseada em ontologias, dado que esta tecnologia tem sido considerada apropriada para o gerenciamento do conhecimento (Hendriks & Vriens, 1999). Uma
ontologia geralmente vista como uma especificao da conceituao do conhecimento de um domnio (Gruber, 1993). Na presente tese, cada uma das vises representa um ponto de vista da organizao, de cuja anlise obtiveram-se
25
ontologias parciais do negcio, pois cada viso traz um conhecimento embutido na mesma. Essas ontologias parciais, como dito antes, foram enriquecidas com a anlise de funes e processos, e com as metforas de Morgan. Da integrao de todas elas obteve-se o Organizational Baseline. Como o SCM vai armazenar informaes do tipo estratgico e em alguns casos informaes de tipo ttico e operacional quando relevantes, seu pblico alvo so tanto os membros da alta direo das empresas, gerentes de linha, executivos e analistas de negcio da rea de gesto administrativa, bem como os engenheiros de requisitos e de software na rea de informtica. Os primeiros, que ocupam cargos gerenciais, com o propsito de satisfazer questes de negcios e os segundos, engenheiros de requisitos e de software, com a inteno de que o SCM contribua a elicitao de requisitos organizacionais, pois como se sabe todo sistema de software tem um componente tecnolgico e social (Jirotka & Goguen, 1994). As questes que a ontologia empresarial tenta responder so as referentes estratgia de negcios, processos e funes, com o intuito de que esse conhecimento possa ajudar a melhorar a competitividade das organizaes em ambientes de mudana contnua, assim como aprimorar o conhecimento organizacional dos engenheiros de requisitos e de software. Estratgias sobre como o SCM pode ser vinculado aos requisitos dos sistemas de aplicao podem ser encontradas em Fiorini (1995) e Mamani-Macedo (1999). Para a implementao da arquitetura ser utilizada uma abordagem baseada em agentes e de sistemas multi-agentes (Multi Agent System MAS). Esta adequada quando se quer desenvolver um sistema que tenha as caractersticas exigidas pelo SCM, tais como, aparente inteligncia, habilidade social, capacidade de aprendizado, adaptabilidade e capacidade de tomada de decises orientada s metas. Estas caractersticas so coincidentes com os mecanismos de varredura (scanning): sensor, filtragem, prova e rejeio, que prope Xu et al. (2003) para um sistema de radar corporativo. Finalmente, as contribuies de nossa pesquisa so: Criao de um modelo conceitual de negcio baseado em teorias da administrao, que sirva de base para a estruturao do Organizational Baseline, repositrio principal da memria corporativa estratgica;
26
Criao de uma arquitetura de software de memria corporativa estratgica em trs camadas: fontes, servios de software e repositrios; Apoiar a operacionalizao de um sistema de gesto de conhecimento fornecendo uma arquitetura de ferramenta de memria corporativa que implemente as caractersticas requeridas pelo SCM, tais como aquisio, armazenamento, compartilhamento e disseminao.
A arquitetura ser validada, por meio de um prottipo onde ser mostrado as vantagens da proposta apresentada, em particular as caractersticas de aquisio, busca e disseminao. Para povoar os dados do prottipo ser utilizado um estudo de caso extrado do livro Imagens da Organizao de G. Morgan (1996), com o prottipo e esses dados estaremos mostrando que os objetivos propostos foram atingidos, pois, como dito antes, sero apresentados alm da aquisio duas das caractersticas principais de nossa proposta de arquitetura, os servios de busca e disseminao.
1.4 Organizao da Tese A tese est organizada da seguinte forma: Neste captulo foram apresentadas as motivaes para a pesquisa, seus objetivos, as questes consideradas como tpicos em aberto no contexto das memrias corporativas (problemas), as contribuies esperadas para resolver algumas destas questes e, finalmente esta seo sobre a organizao da tese. No Captulo 2, ser apresentada a metodologia utilizada, tanto aquela empregada na criao do Organizational Baseline como aquela utilizada na construo da arquitetura. No Captulo 3 sero apresentados os resultados relevantes da reviso da literatura sobre memrias corporativas, tanto as propostas surgidas no meio acadmico como na indstria. Neste ltimo caso, mostraremos alguns produtos que existem no mercado, pertinentes de Gesto do Conhecimento. No Captulo 4 explicado o referencial terico utilizado, incluindo todas as definies conceituais que consideramos necessrias para o desenvolvimento do presente trabalho, tais como: as teorias de estratgia de negcios (abordagens
27
positioning e resource-based view) e as metforas de Morgan; a conceituao da Gesto do Conhecimento, a tecnologia de ontologias (utilizada para organizar os construtos extrados do passo anterior) e a abordagem de agentes (para a implementao de nossa proposta). No Captulo 5, so apresentados os resultados da pesquisa, destacando-se (1) o Modelo de Negcio base do Organizational Baseline; (2) a arquitetura proposta com sua representao grfica, funcionalidades e componentes; e (3) a especificao dos agentes de software com sua representao grfica e sua documentao. No Captulo 6, apresentado uma viso do prottipo desenvolvido para demonstrao de nossa tese. Finalmente, o captulo 7 contem uma sntese das contribuies, sugestes para trabalhos futuros e algumas consideraes finais.
2 Estratgia Proposta
Entende-se por estratgia um plano de ao ou mtodo cuidadosamente trabalhado com o intuito de atingir um determinado objetivo. Assim, uma representao diagramtica da metodologia utilizada nesta fase apresentada, a seguir, na Figura 2.1:
Tecnologia de Ontologias Teorias de Administrao Modelo ER Tecnologia Agentes
ANALISAR
Ontologia do Negcio Organizational Baseline

Arquitetura da
CRIAR
PROJETAR Memria Corporativa
IMPLEMENTAR Prottipo
ER: Entidade-Relacionamento
Figura 2.1 Metodologia para o desenvolvimento da Arquitetura
As etapas de nossa estratgia ou metodologia para construo da arquitetura proposta so descritos a continuao: Analisar O primeiro passo foi analisar e estudar as teorias pertinentes anlise estratgica, necessrias para a elicitao de construtos relevantes organizao. Para este fim, foram utilizadas as seguintes teorias da administrao de negcios:
a gesto do conhecimento nas suas vertentes gerencial e tecnolgica; as vises positioning e emphasizing efficiency para a anlise estratgica; a anlise de funes e processos; o gerenciamento da qualidade total (Total Quality Management - TQM) e, em forma ortogonal a todas as anteriores; as metforas de Morgan.
29
A organizao de tais construtos foi feita por meio da utilizao da tecnologia de ontologias. Criar O segundo passo foi o de criar um modelo de negcio como base para a construo do repositrio de conhecimento, denominado o Organizational Baseline (Mamani-Macedo & Leite, 2001), o qual tinha que incluir informaes estratgicas, tticas e operacionais relevantes, sejam estes, conhecimentos tcito ou explcito e o armazenamento de casos de experincias passadas. Para a construo do Organizational Baseline utilizou-se a viso do Requirements Baseline (Leite et al., 1997), o modelo de Entidade-Relacionamento e a ontologia elicitada na etapa anterior. O contexto do baseline, como mostrado na Figura 2.2, est formado pela perspectiva funcional (reas funcionais) e a perspectiva de processo, assim o baseline atualizado tanto no tempo de execuo dos processos, como por efeito do feedback como decorrncia de mudanas no ambiente, manuteno do baseline.
Organizational Baseline (Strategic Corporate Memory)
Feedback
rea 1 rea 2 rea 3
Processo Verso
Tempo de Manuteno
Figura 2.2: O Contexto do Organizacional Baseline
Tempo de Execuo
Na figura apresentada mostra-se ambas evolues, do processo fornecendo indicadores, e das reas funcionais que so permeadas pelas mudanas no ambiente. Ao mesmo tempo mudanas nas reas funcionais afetam os processos, originando novas verses destes, afetando a informao contida no baseline. Ambos eixos, so enriquecidos pelo feedback (retroalimentao) contnuo. Desde outra tica, os processos em tempo de execuo originam informaes e
30
experincias que devem ser capturadas no baseline. A figura mostra, tambm, que a mudana contnua do ambiente causa que o baseline necessite de uma manuteno dinmica. Projetar O terceiro passo foi de projetar a arquitetura genrica do SCM, a qual foi desenvolvida em trs camadas: de fontes, middleware ou de servios de software e de repositrios. A arquitetura proposta tambm apresenta detalhes dos seus principais componentes de software, bem como das suas principais
funcionalidades. Para projetar a arquitetura empregou-se a metodologia MESSAGE (Eurescom, 2001) que uma abordagem orientada a agentes e a sistemas multiagentes. Implementar O quarto passo foi, construir um prottipo com a aplicao da arquitetura da memria corporativa, o qual incluiu o mdulo de busca e o mdulo de atualizao do Organizational Baseline, tendo entre as suas funcionalidades as de criao do log da aplicao, a atualizao dos indexes (tanto do log como de leitura do log ponteiro de posicionamento) e a disseminao dessas mudanas entre os usurios previamente cadastrados e que precisam desse tipo de informao. O prottipo foi desenvolvido utilizando-se a linguagem de programao Java, como banco de dados utilizou-se o sistema de armazenamento relacional MSAccess. Os dados utilizados para efeitos de mostrar o funcionamento do prottipo foram extrados e adaptados de um estudo de caso apresentado por Morgan (1996).
3 Reviso da Literatura
No meio acadmico e na indstria tm-se desenvolvido diversas propostas e produtos de memrias corporativas como uma forma de operacionalizar a gesto do conhecimento. Entre os exemplos oriundos do meio acadmico podemos citar: o Know More de Abecker et al. (1998) e a Fbrica de Experincias de Basili & McGarry (1997). Como exemplos de produtos comerciais podemos citar o AskMe Enterprise (AskMe, 2001), XpertRule Knowledge Builder (Attar, 2003) e o QuestMap (Gdss, 2003). A seguir apresentada uma descrio de todos esses sistemas assim, como uma avaliao e comparao entre os mesmos.
3.1 Know More (Abecker et al., 2003) Esta proposta est orientada ao usurio que executa tarefas de conhecimento em um processo organizacional. Em geral, as tarefas de conhecimento, tambm chamadas de tarefas intensivas em conhecimento, so complexas, difceis e importantes por natureza e para a sua execuo necessria a participao de especialistas que possuam tanto habilidades quanto capacidades. Entre as capacidades se destaca o conhecimento. Dadas as caractersticas destas tarefas, uma completa automao, ou mesmo uma partilha em subtarefas usualmente no factvel, uma vez que no existe nenhuma seqncia de tarefas predeterminadas, que se executadas, garanta o resultado desejado. Para lidar com esta problemtica, a abordagem de Abecker et al. modela e executa os processos e tarefas, atuando assim sobre o nvel de aplicao. Logo, quando um trabalhador reconhece uma necessidade de informao, uma consulta memria organizacional (OM) realizada. A abordagem tem outros dois nveis, o nvel de objetos, que est caracterizado por uma variedade de fontes heterogneas de informao e o nvel de descrio de conhecimento, que permite o mapeamento do nvel de aplicao ao nvel de objetos, utilizando-se de trs tipos de ontologias: ontologia da empresa (estrutura empresarial), ontologia do domnio (especfico ao
32
tema sob estudo) e ontologia da informao (genrico s fontes de informao documentos). Vale ressaltar, que esta proposta est orientada recuperao de documentos e localizao de pessoas especialistas em um determinado tpico.
3.2 Experience Factory (Basili et al., 1997) Esta abordagem define um framework para o gerenciamento de experincias e reconhece a necessidade da existncia de um orgo separado que trabalhe com a organizao de projetos para o gerenciamento dessas experincias. Esta proposta tem sido aplicada com sucesso nos projetos de desenvolvimento de software da NASA por mais de 25 anos. O modelo da Fbrica de Experincias esta alinhado organizao do projeto. Assim, os dados produzidos como resultado da execuo do planejamento do projeto so capturados pela fbrica de experincias, para sua anlise, sntese e empacotamento em uma base de experincias, a qual vai dar suporte ao negcio quando forem planejados outros projetos similares no futuro. A fbrica de experincias permite tratar os seguintes tipos de problemas: Encontrar a pessoa adequada ou o especialista para solucionar um problema; Criar modelos baseados na experincia para melhorar a estimativa de custos; Identificar padres e agir sobre eles; Capturar, organizar e disseminar lies aprendidas; Reusar todas as categorias ou tipos de experincia documentada, por ex. propostas, oramentos, etc.
Neste sentido, a Fbrica de Experincias faz uso de uma espcie de Raciocnio Baseado em Casos (Case-Based Reasoning CBR) (Wangenheim von & Rodriguez, 2000), orientado ao domnio de Engenharia de Software.
33
3.3 O AskMe Enterprise - AskMe Corporation (AskMe, 2001) Este produto uma soluo de software que oferece, segundo os seus desenvolvedores, uma maneira comprovada para capturar, gerenciar e reutilizar o conhecimento dos funcionrios, bem como o armazenamento e recuperao de experincias passadas na forma de documentos. Utiliza-se de uma srie de algoritmos para casamento probabilstico de padres, busca de conhecimento e inferncia, com o intuito de:
Compartilhar as melhores prticas da empresa; Promover a inovao, antes que a re-inveno; Incrementar a produtividade dos seus funcionrios que realizam tarefas
intensivas em conhecimento;
Melhorar a profundidade e amplitude das habilidades dos trabalhadores; Dar respostas rpidas a questes do negcio, melhorando a tomada de
decises;
Criar, automaticamente, uma base de conhecimento a partir do capital
intelectual existente visando ganhar uma vantagem competitiva sustentvel.
O objetivo amplo deste produto ajudar as corporaes a otimizarem a entrega de conhecimento especifico ao domnio, em qualquer local dentro da organizao, quando procurado pelos funcionrios, sem importar se esse conhecimento j foi documentado ou no. Esta abordagem de entrega de conhecimento especfico ao problema denominada de Gerncia da Cadeia de Conhecimento (KCM-Knowledge Chain Management). Usualmente, uma cadeia de conhecimento gerada quando os funcionrios: se consultam entre si para resolver problemas de negcios; compartilham informao acerca dos processos internos ou dos competidores externos; procuram informao na intranet; ou participam de reunies formais com outros colaboradores. Os objetivos especficos do AskMe Enterprise so:
34
(1) gerenciar e otimizar as cadeias de conhecimento para dinamizar os processos internos e a tomada de decises; (2) equipar os funcionrios com a informao que eles precisam para que faam seus trabalhos eficientemente; (3) capturar essas trocas de conhecimento de modo que o desempenho dos funcionrios possam ser melhorados no futuro. A ferramenta AskMe Enterprise formada por trs camadas, sendo uma de integrao, outra de servios e o repositrio de dados. A camada de integrao, permite a ligao atual infraestrutura de tecnologia de informao e s aplicaes existentes, como portais, mquinas de busca e diretrios corporativos. Inclu ferramentas de conexo a essas aplicaes, bem como ao gerenciador de documentos, ao criador automtico de perfis e aos plug-ins de configurao, como por exemplo de e-mails. A camada de servios, tem como funcionalidades:
A Minerao de Conhecimento: Permite aos gerentes de negcios fazer
inferncias e tomar decises, baseado no conhecimento compatilhado na organizao;

O Compartilhamento de Conhecimento: Facilita o descobrimento de
solues a problemas de negcios, fornecendo ferramentas que ajudam a compartilhar eficientemente o know how e as melhores prticas dos usurios;
A Gerncia de Aplicaes: Permite que o pblico alvo (gerentes), faa o
gerenciamento de taxonomias de conhecimento, usurios e contedo, assim como tambm sua conduo e uso;
A
Administrao do Sistema: Fornece as ferramentas para o
monitoramento e a manuteno do sistema.
A camada de repositrio de dados onde se armazena a taxonmia do conhecimento, os perfis dos especialistas e os diversos documentos (textos, artigos ou mensagens) que foram trocados entre os empregados.
35
3.4 XpertRule Knowledge Builder
Attar Software Limited (Attar, 2003)
Trata-se de um ambiente para o desenvolvimento e uso de aplicaes e componentes baseados em conhecimento, incorporando regras, experincias, know-how, procedimentos, polticas e regulamentos, sob o nome de Regras de Negcio. Esta ferramenta tenta automatizar qualquer funo (atividade) baseada em conhecimento dentro da organizao, como por exemplo: Fazer recomendaes e dar conselhos sobre produtos, servios e cursos de ao, facilitando o compartilhamento de conhecimento e reforando as melhores prticas; Pesquisar defeitos nas aplicaes de suporte e de ajuda aos clientes, facilitando a captura do conhecimento dos defeitos e seus diagnsticos, com o intuito de dar suporte aos usurios internos e clientes; Monitorar e Avaliar Condies e os seus Riscos, por exemplo na rea de manufatura e nos processos, onde poderia se detectar antecipadamente os sinais de advertncia de falhas; Workflow, as regras podem ajudar a decidir sobre as prximas aes e tarefas, baseadas nos atuais eventos e na data disponvel. O Knowledge Builder utiliza para a representao dessas regras rvores de deciso e tabelas de casos. As rvores de deciso esto relacionadas a um resultado ou deciso, dado um conjunto de atributos. As tabelas de casos contm uma lista de exemplos ou regras mostrando como um resultado ou deciso se relaciona a uma combinao de valores de atributos. A ferramenta permite que um atributo dentro de uma rvore de deciso ou tabela possa ser representada por outra rvore de deciso ou tabela. Esta representao chamada de encadeamento de conhecimento.
3.5 O QuestMap - The Soft Bicycle Company (Gdss, 2003) Trata-se de uma ferramenta que tenta capturar o conhecimento informal e torn-lo explicito. O componente chave desta proposta o uso de um sistema de interfaces de usurio (telas) que capturam as questes e idias-chave durante as
36
reunies (presenciais ou virtuais), criando um entendimento compartilhado na equipe de trabalho. Este sistema tem os seguintes componentes: de Captura: Um facilitador escreve sobre um teclado ou sobre um quadro ou flipchart (browser); de Estrutura: Utiliza-se o modelo de conversao IBIS (Issue Based Information System) de Conklin & Begeman (1987), o qual classifica qualquer conversao em quatro elementos simples: questes, idias, prs e contras; Interface do Usurio: um sistema de software de hipertexto, o qual suporta a estrutura do QuestMap; Banco de dados: Armazena os mapas de discusso prvios, possibilitando a busca e navegao dentro desta base de conhecimento informal.
3.6 Avaliao das propostas e dos produtos A seguir se far uma breve anlise dos diferentes propostas e produtos de memrias corporativas: O Know More est orientado basicamente a suportar os processos de negcio com tarefas intensivas em conhecimento. Este produto faz uso de ontologias para mapear os processos aos objetos (repositrios de dados), fornecendo os links de onde possvel encontrar informao relevante a essas tarefas (documentos), no fornecendo informao especfica. As ontologias ao nvel de tratamento da informao esto relativamente bem definidas, no entanto as ontologias ao nvel da estrutura empresarial e do domnio esto em alto nvel de abstrao. A Fbrica de Experincias de Basili & McGarry, est orientada a capturar conhecimento exclusivamente de projetos de software, sob a forma de casos. No entanto, a abordagem poderia se estender a outro tipo de reas. No trata, por exemplo, de informao do tipo estratgico. O AskMe Enterprise, est voltada principalmente para a busca de documentos e pessoas, no tratando de forma explicita tpicos estratgicos. Mas os documentos ou as pessoas podem conter ou possuir esse tipo de informao.
37
O XpertRule Knowledge Builder, tenta formalizar as regras de negcio sob a forma de rvores de deciso, capturando tanto conhecimento formal quanto informal que possa ser representado em regras. No trata tambm aspectos estratgicos de uma forma estruturada. O QuestMap similar ao XpertRule ao tentar capturar o conhecimento informal por meio de uma seqncia de passos, uma espcie de regras baseadas no modelo de conversao IBIS. Como no caso do XpertRule no do a devida importncia a questes estratgicas, pois s acessa seus prprios repositrios de dados onde armazena os mapas de discusso. Na Tabela 3.1 mostra-se um quadro comparativo das diferentes propostas antes mencionadas. Nela observa-se que quase todas as ferramentas esto orientadas principalmente ao nvel ttico. Isso no quer dizer que estas ferramentas no tratem com aspectos estratgicos, seno que a nfase no est nesses aspectos. Nesse sentido, o SCM est orientado basicamente ao nvel estratgico, pela base terica utilizada na criao do seu principal repositrio, o Organizational Baseline (OB). Encontra-se tambm que o KnowMore a nica ferramenta que modela explicitamente os processos de negcio. Tanto a proposta da Fabrica de Experincias como o SCM, se bem elicitam informaes dos processos no a tratam no detalhe do KnowMore. De todas as ferramentas, a que melhor lida com as regras de negcio o XpertRule, o QuestMap utiliza uma espcie de regras a efeitos de tratar processos de raciocnio. Nenhuma das ferramentas estudadas utiliza algum modelo de negcio para armazenar informao estratgica, esta a maior vantagem do SCM, o qual operacionaliza esse modelo na forma de um repositrio de conhecimento, o OB. No uso de ontologias destaca-se o KnowMore, o AskMe utiliza taxonomias, no caso do SCM esta utiliza uma ontologia do domnio orientado estratgia de negcios. Todas as ferramentas de uma ou outra forma tratam com a gesto de documentos, mas algumas delas esto restringidas aos documentos digitais que as mesmas geram como o caso do QuestMap e XperRule. Uma das caractersticas do AskMe a localizao de pessoas, esta parcialmente tratada pelo KnowMore e a Fabrica de Experincias, a arquitetura do SCM considera esta caracterstica quando modela aos usurios.
38
Nenhuma das ferramentas estudadas faz gesto de conceitos de estratgia de negcios, como se o faz o SCM, isto se deveria ao fato que todas elas no consideram a existncia de um modelo de negcio. Outra caracterstica do SCM que esta proativa, o AskMe na sua ltima verso introduz esta caracterstica para o caso das lies aprendidas. Finalmente, todas elas incluindo, evidentemente, o SCM fomentam o aprendizado organizacional.
Memria Organizacional Caractersticas Orientao

. Usurios (nvel ttico) . Executivos e Eng.. de Requisitos Foco . Global (qualquer organizao) . Especifico (Engen. de Software)
Academia KnowMore Fab.Exp. AskMe
Indstria XpertRule QuestMap SCM

TM
V 1 + ou V V X X X V V V X X V
V V 2 4a + ou + ou X V + ou X X V X V V X X V
3
V 6 + ou V X X V X X + ou X X X V
7
V 8 + ou V X X + ou 9 V X + ou X X X V
10
+ ou 11 V V + ou V X V V V V V V V
12
V X X + ou 4b V 4c + ou V V X + ou 5 V
Modela
. Processos e Tarefas . Toda a Organizao . Regras de Negcio . Lies Aprendidas
Faz uso de Ontologias com nfase em:

. Gesto de documentos . Localizao de pessoas . Gesto de conceitos
Ferramenta
. Proativa . Fomenta o aprendizado
LEGENDA V: Cumpre a caracterstica X: No cumpre a caracter. + ou - : Cumpre mais ou menos a caracterstica
Tabela 3.1 Quadro Comparativo: Ferramentas de Gesto do Conhecimento

1
Orientado aos usurios a nvel ttico-operacional, mas que fazem uso intensivo de conhecimento. Portanto podem ser includos executivos de nvel intermdio e eventualmente engenheiros de requisitos, quando o precisarem. 2 A Fabrica de Experincias uma proposta orientada a capturar conhecimento na rea de Engenharia de Software, portanto, focada a executivos dessa rea. 3 Os processos no so tratados no detalhe como se so tratados pelo KnowMore. 4a Trata informao estratgica quando contida em documentos ou quando possuda pelos funcionrios. Fornece plug-ins para fazer vnculos com outros repositrios ou portais. 4b Regras simples que classificam as solicitudes de informao baseados na origem, contexto e tempo esperado de resposta. 4c Estas podem disparar uma notificao ou encaminhar a solicitude a um determinado especialista ou iniciar um processo de aprovao automatizado (por ex. de lies aprendidas). 5 Focado nas melhores prticas, a ferramenta comunica as pessoas interessadas, previamente cadastradas, as atualizaes havidas no repositrio de lies aprendidas. Faz uso de taxonomias. 6 A nfase esta no nvel ttico, mas pode ser, eventualmente, utilizado no nvel estratgico pelos executivos. 7 Documentos digitais gerados pela prpria ferramenta. 8 Esta ferramenta de grande utilidade para capturar conhecimento informal, embora tenha uma orientao s regras, seu uso adequado para capturar processos de raciocnio. 9 No trata regras de negcio, mas bem captura os processos de raciocnio na forma de regras.
39
Faz gesto de documentos digitais gerados pela prpria ferramenta. A arquitetura est orientada ao nvel executivo estratgico, mas isso no impede, como que deve ser, tambm ser utilizada nos nveis tticos. 12 Captura informaes dos processos, indicadores e benchmarking, mas no com o detalhe do KnowMore.
11
10
4 Referencial Terico
Para a realizao do presente trabalho foram utilizadas diferentes abordagens provenientes de diferentes reas do conhecimento. Primeiro, estudouse os conceitos e variaes (vis) da gesto do conhecimento, nas suas vertentes gerencial e tecnolgica, dado que a criao de uma memria corporativa uma forma de operacionalizar o processo de gesto do conhecimento. A seguir, com base na estratgia de negcios, analisou-se a escola estrutura-conduta-desempenho (positioning modelo de Porter e modelo ambiental) e a viso que enfatiza a eficincia (emphasizing efficiency resource-based view e dynamic capabilities). Estudou-se, tambm, a anlise de funes e processos, o TQM (Total Quality Management) e as metforas de Morgan (1996), como elementos base de onde elicitar os conceitos e atributos relevantes para a construo do modelo de negcio da memria corporativa. Para modelar esse conhecimento elicitado, empregou-se a tecnologia de Ontologias e o modelo de EntidadeRelacionamento. Para a criao dos componentes de software que faro parte da arquitetura utilizou-se a tecnologia de agentes. A seguir descreveremos cada uma dessas teorias, vises, tecnologias e modelos, com o intuito de melhorar o entendimento dos captulos subseqentes.
4.1 Gesto do Conhecimento um fato conhecido que na ltima dcada (anos 90) as organizaes tm reconhecido que o seu ativo mais importante so os seus funcionrios, os quais possuem o know-how ou conhecimento organizacional tcito. Assim sendo, de natureza crtica a elicitao desse conhecimento organizacional para torn-lo explicito na organizao. O conhecimento explicito mantm-se geralmente nos manuais de procedimentos e funes da organizao. A seguir apresentada uma breve explicao da rea de gesto do conhecimento, com base nos estudos realizados pelo grupo de Knowledge
41
Management (KM) da Graduate School of Business, University of Texas at Austin (2003) (UT-Austin). 4.1.1 Uma aproximao definio de Conhecimento De acordo com a definio encontrada no Merrian-Webster's Dictionary (Merrian Webster, 2003), conhecimento (1) o fato ou condio de conhecer alguma coisa com a familiaridade adquirida com a experincia ou associao cognitiva, (2) entendimento de uma cincia, arte ou tcnica. (3) o fato ou a condio de estar ciente de algo, (4) a soma daquilo que conhecido: o corpo das verdades, informaes e princpios adquiridos pela humanidade. O conhecimento pode, tambm, ser descrito como um conjunto de modelos que descrevem vrias propriedades e comportamentos dentro de um domnio especfico. O conhecimento, assim, pode estar registrado no crebro da pessoa ou armazenado nos processos organizacionais, produtos, sistemas e documentos. A definio de conhecimento estabelecida pelo grupo de KM da UT-Austin, afirma que conhecimentos so as idias ou entendimentos que uma entidade possui, utilizadas para a tomada de uma ao efetiva com o intuito de atingir os objetivos da entidade. Este conhecimento especifico a entidade que o criou. Uma organizao ou suas reas funcionais so exemplos de entidades. Atualmente, em funo da rpida mudana no ambiente organizacional das empresas, resultante principalmente, das inovaes tecnolgicas nas
comunicaes, o conhecimento tornou-se, na prtica, o nico recurso para a obteno de vantagens competitivas sustentveis. Portanto, este ativo deve ser elicitado, armazenado, protegido, cultivado e compartilhado entre os membros da organizao. A empresa que aproveitara seu capital intelectual pode aplicar esses ativos intangveis aos desafios e oportunidades do negcio que se
apresentarem. Assim, a adequada utilizao do conhecimento organizacional (explicito e implcito) junto com o potencial das habilidades individuais, competncias, pensamentos, inovaes e idias permitiro que a organizao possa competir mais efetivamente. evidente que muito conhecimento vital do funcionamento das empresas esto com os indivduos da organizao, e que o grande desafio torn-lo disponvel. Mas ao mesmo tempo, muitas companhias no percebem que possuem
42
sua prpria base de conhecimento e o demonstram claramente quando esse conhecimento perdido pelo surgimento de atritos entre seus membros ou por problemas de ordem financeira. A gesto do conhecimento envolve,
necessariamente, no apenas compromissos ou aspectos gerenciais, como tambm, recursos financeiros para torn-la vivel, seja na forma de um programa de desenvolvimento organizacional que motive o compartilhamento do conhecimento entre seus membros ou mediante o desenvolvimento ou aquisio de ferramentas que suportem o processo de gesto de conhecimento.
4.1.2 O Que Gesto do Conhecimento ? Gesto do Conhecimento o processo de encontrar, elicitar, selecionar, organizar, armazenar, proteger, compartilhar, disseminar e apresentar o conhecimento em uma forma que melhore a compreenso em determinada rea de interesse. A gesto do conhecimento ajuda a organizao a ganhar intuio e entendimento a partir de sua prpria experincia. As atividades de gesto do conhecimento contribuem para que a organizao se foque na aquisio, armazenamento e utilizao do conhecimento na soluo de problemas, no aprendizado organizacional dinmico, no planejamento estratgico e na tomada de decises. Tambm protege aos ativos intelectuais de sua deteriorao, bem como agrega inteligncia organizao, fornecendo-lhe uma crescente flexibilidade. Em muitas empresas tm-se constatado que estas no sabem o que elas sabem". Essa situao pode conduzir duplicao de esforos, consumindo tempo e dinheiro. Assim, deduz-se que as organizaes devem perguntar a si mesmas duas importantes questes: (UT-Austin, 2003) (1) Quais so nossos ativos de conhecimento? (2) Como devemos gerenciar esses ativos para obter o mximo retorno?
Segundo o grupo de KM da UT-Austin, no existe uma resposta certa ou errada a essas questes. Esta depende de diferentes fatores, como o tipo de organizao, sua cultura e suas necessidades especficas. No entanto, uma efetiva gesto do conhecimento foca-se em solues que envolvam a empresa como um todo, incluindo a sua organizao, pessoas e tecnologia. evidente que os
43
computadores e os sistemas de comunicao so adequados na captura, transformao e distribuio do conhecimento altamente estruturado,
independente da sua dinmica ou evoluo. Portanto, a tecnologia alavanca uma adequada gesto do conhecimento na organizao, podendo esse conhecimento ser utilizado para aprimorar sua tomada de decises, alocar recursos, gerenciar sistemas, acessar e promover o processo de elicitao do know-how, tudo isso com o intuito de aprimorar o seu desempenho global e como uma maneira de desenvolver seu ncleo de competncias estratgicas distintivas. Assim, qualquer organizao pode efetivamente usar a gesto do conhecimento para se desenvolver e melhorar seu desempenho, controle e efetividade. Uma das abordagens da anlise estratgica que estuda o uso dos recursos intelectuais (competncias) como uma forma de obter vantagem competitiva o resource-based view, a qual enfatizada pelo framework das capacidades dinmicas (dynamic capabilities), que uma evoluo da baseada em recursos, esta argumenta que no basta acumular ativos de conhecimento, pois o
importante que a organizao tenha a capacidade de gesto destes para coordenar e recolocar efetivamente as competncias internas e externas (Teece, 1997). O termo dinmico, refere-se capacidade da organizao de renovar as suas competncias, de forma a atingir uma congruncia com as mudanas que acontecem no ambiente de negcios. O termo capacidades, enfatiza o papel chave da gesto estratgica na adaptao, integrao, e re-configurao das habilidades, recursos e competncias funcionais organizacionais, internas e externas, para casar com os requisitos de um ambiente em mudana contnua. Um aspecto estratgico a identificao e o desenvolvimento de competncias difceis de imitar ou copiar, as quais suportem a criao de produtos e servios valiosos. Em outras palavras, o objetivo como obter vantagem competitiva por meio dessas competncias distintivas. A implementao da gesto do conhecimento nas organizaes tem duas vias, uma gerencial vinculada gesto, desde o ponto de vista administrativo, e outra tecnolgica, a qual busca operacionalizar o processo de gesto do conhecimento por meio de sistemas e ferramentas de software, as quais suportem as atividades de elicitao, seleo, refinamento, compartilhamento e
disseminao oportuna aos membros da organizao, quando necessitado. Uma forma de operacionalizar o processo de gesto do conhecimento por meio da
44
criao de um sistema de memria corporativa orientado estratgia de negcios, o qual possua os repositrios necessrios para armazenar os ativos intelectuais da organizao.
4.2 Estratgia de Negcios A escolha de uma estratgia de negcios uma tarefa necessria para a formulao de qualquer estratgia global de negcios. No desenvolvimento de um plano estratgico, no entanto, podem-se encontrar os seguintes problemas: Incerteza no ambiente; Falta de informao; Informao pouco confivel; Falta de uma equipe suficientemente preparada.
AMBIENTE INDIRETO
Aspecto Scio - Cultural Foras Competitivas no Setor

Clientes de Atividade Empresarial Concorrncia
Aspecto Poltico
Processos
Finanas
AMBIENTE DIRETO Novos Aspecto Tecnolgico
Rec.Humanos
AMBIENTE Marketing INTERNO Interfuncionais

Empresas de Produtos Substitutos
Logstica/ Produo
Concorrntes
rgos de Apoio
Fornecedores
da Atividade Empresarial Aspecto econmico
Figura 4.1 A Organizao e seus ambientes - adaptado de Stoner (1986)
O primeiro passo do planejamento estratgico a anlise do ambiente indireto, o segundo, a anlise do ambiente direto, que inclui a anlise do setor onde esta desenvolve suas atividades operacionais, e o terceiro, a anlise do micro ambiente, vide Figura 4.1. Os dois primeiros passos levam determinao das oportunidades e dos riscos do negcio e o terceiro conduz determinao dos pontos fortes e de melhoria da empresa. Como conseqncia da anlise destes resultados, define-se ou redefine-se a atividade empresarial da organizao. Em todos os nveis est presente o conceito de qualidade em seu senso mais amplo de
45
busca de melhoria contnua de todos os produtos e processos da empresa dentro de um enfoque estratgico, o qual muitos chamam de qualidade total. Baseada em Mamani-Macedo et al. (1992) e Aybar et al. (1989). Esse processo de planejamento estratgico pode ser realizado de acordo com, pelo menos, duas abordagens distintas de gesto estratgica de negcios: as vises positioning (estrutura-conduta-desempenho) e de emphasizing
efficiency (enfatizando a eficincia), a primeira, orientada anlise do ambiente direto (modelo de Porter) e ambiente indireto (modelo ambiental), a segunda, orientada ao ambiente interno.
4.2.1 A Abordagem positioning ou de Estrutura-Conduta-Desempenho Os proponentes desta viso afirmam que o desempenho da organizao est influenciada, basicamente, pela estrutura da indstria, a qual delineia uma conduta (estratgia) que se reflete no desempenho da indstria, em geral, e da organizao em particular. Destacam-se dois modelos:
4.2.1.1 O Modelo de Porter Baseado na teoria da organizao industrial de Mason (Chabert, 1998), enfatiza a importncia da anlise da estrutura da indstria para o melhor entendimento da estratgia da organizao e do seu desempenho. Porter argumenta que o grau de competio na indstria, vai alm do comportamento dos seus prprios competidores. Assim, prope que a anlise estratgica seja baseada nas seguintes cinco foras competitivas: da concorrncia, a das empresas com produtos substitutos, a dos clientes (compradores), a dos fornecedores e os possveis novos concorrentes, chamados de novos entrantes. Esta anlise denominada por Porter, como a Anlise das Foras Competitivas, conforme explicada no seu livro Estratgia Competitiva (Porter, 1980). Porter tambm ressalta a importncia da anlise do setor, dai sua incluso no modelo de negcio proposto. a) Anlise do Setor: A anlise setorial, tem por objetivo estabelecer as caractersticas principais do setor para o qual se orienta a empresa, em
46
termos de explorao ou produo. Por exemplo, de que maneira o setor ao qual pertence a empresa est contribuindo para o desenvolvimento do pas? Quais polticas de apoio ao setor, adotadas pelo governo contribuem para o desenvolvimento empresarial? De que maneira o aspecto legal vigente a beneficia ou, pelo contrario, a prejudica? A anlise do setor pode-se realizar ou dar sob os seguintes aspectos: importaes, exportaes, investimentos estrangeiros e transferncia tecnolgica. b) Clientes: Deve analisar-se tanto os atuais clientes como, tambm, aos
potenciais clientes e s condies que imperam no mercado, com o objetivo de captar aqueles que podem representar lucro para a empresa. importante notar que os clientes possuem um poder de negociao frente a seus fornecedores e, portanto, podem influir na rentabilidade potencial da empresa. Assim, estes podem forar a diminuies de preos, maiores servios e melhores condies de pagamento. c) Fornecedores: Os fornecedores so os que provm bens ou servios organizao, e tm tambm um poder sobre esta, o qual pode-se refletir na possibilidade de aumentar seus preos, de reduzir a qualidade, ou em casos extremos de reduzir as quantidades vendidas a um cliente em concreto. Fazendo uma analogia ao enfoque de sistemas, os fornecedores, atravs de seus produtos/servios, so a entrada para o processo de transformao que realiza a empresa, para logo oferecer o resultado deste aos seus clientes. d) Concorrncia: O objetivo da anlise do concorrente desenvolver um perfil da natureza e do sucesso das mudanas de estratgia, que cada concorrente fez no passado e que poderia fazer no futuro; da provvel resposta de cada concorrente gama de possveis movimentos estratgicos que outras empresas pudessem iniciar e; a reao provvel de cada concorrente frente s mudanas que no setor e no entorno pudessem acontecer. Existem quatro componentes bsicos para o diagnstico de um concorrente: os seus objetivos futuros, os seus supostos de atuao (premissas), a sua estratgia atual e as suas capacidades.
47
e) Produtos Substitutos: Os produtos substitutos so os produtos que desempenham a mesma funo para o mesmo grupo de consumidores, mas que se sustentam em uma tecnologia diferente. Os riscos de ingressos de produtos substitutos depende de duas condies: quando mais atrativo o preo comparativo do produto substituto; quando os custos pela mudana do produto da indstria por seu substituto so relativamente baixos.
A presena de produtos substitutos est determinada pelas inovaes tecnolgicas resultantes de trabalhos de pesquisa e desenvolvimento que se realizam permanentemente na indstria. f) Novos Entrantes: So aquelas empresas que esto prestes a ingressar no mesmo setor onde a organizao desenvolve suas atividades
empresariais, e que esta no conhece com certeza nem com que capacidade ou fora, estes iro se comportar. A ameaa de novos entrantes potenciais deve motivar empresa, no sentido de melhorar permanentemente suas formas de oferecimento de bens e servios a seus clientes, assim como de inovar ou criar novas formas ou alternativas de servio, melhorar a apresentao de seus produtos e dar facilidades de financiamento. Embora tal estratgia, no inicio, acarrete custos e investimentos, depois de algum tempo, estes devem reverter-se em lucros para a empresa, quando a qualidade e garantia dos produtos forem mantidas.
4.2.1.2 O Modelo Ambiental O modelo ambiental tenta avaliar de forma objetiva a situao atual das diversas variveis do ambiente, que se encontram fora do controle da direo da organizao, mas que tm uma influncia muito importante para o
desenvolvimento das operaes empresariais. Os fatores estudados neste modelo so: (Austin, 1990), (Aybar et al.,1989) a) Aspecto Social/Cultural: A sociedade e a cultura fixam as fronteiras de ao de uma organizao, exercendo sua influncia na maneira como esta
48
funcionar, assim como no modo de agir de seus gerentes e funcionrios, os quais atuaro dependendo de sua procedncia geogrfica, clima, nvel social e educacional, dentre outros. Por outro lado, a sociedade tende a agrupar-se em famlias, as quais influem sobre as organizaes atravs do mercado de consumidores e do mercado do trabalho. Uma anlise geral das necessidades desse mercado de consumidores ir ajudar a determinar as oportunidades iniciais de se manter no negcio. b) Aspecto Econmico: A influncia das variveis econmicas no desenvolvimento empresarial tais como: o Produto Interno Bruto, a inflao, a taxa de juros, o tipo de cmbio, as reservas internacionais, o dficit fiscal, afetam o desenvolvimento das empresas e, principalmente, o mercado. Aqui, tambm, deve-se considerar os impactos que da economia mundial refletem na empresa (globalizao). c) Aspecto Poltico: A poltica do governo outra varivel que influi na empresa, podendo restringi-la ou perturbar seu desempenho, dependendo da flexibilidade ou rigidez das leis. Assim, da ideologia dominante no grupo ou partido que detenha o governo do pas, se do os denominados instrumentos de poltica, que so de diversas ndoles, tais como a poltica fiscal, a poltica de emprego, a poltica cambial, a poltica de alfndega, a poltica monetria e a poltica industrial, entre outros. d) Aspecto Tecnolgico: Desde sempre, e especialmente nos ltimos anos, observa-se que a tecnologia tem um papel relevante nos diferentes nveis de deciso: estratgico, ttico e operacional. A tecnologia pode ser vista como uma ferramenta que alavanca, quando bem estruturada, a obteno de vantagens competitivas, o qual se reflete na produtividade, rentabilidade e desenvolvimento de novos mercados e produtos. As mudanas de tecnologia so um problema que deve-se contemplar e tratar nas empresas, porque implicam custos, tais como os custos de aquisio, de treinamento e de disseminao.
49
4.2.2 A Abordagem emphasizing efficiency ou a que enfatiza a eficincia Esta abordagem tem dois frameworks, o resource-based view e a sua evoluo, o dynamic capabilities.
4.2.2.1 A Viso resource-based view Os proponentes da perspetiva baseada em recursos, chamada resourcebased view, (Day et al, 1997, Rumelt et al., 1991, Wernerfelt, 1984), vinculam o desempenho superior aos recursos da organizao. Estes recursos so uma combinao de ativos e competncias que refletem a historia da organizao, e como tal, podem limitar a sua habilidade para a mudana. Os ativos e competncias determinam como efetivamente a companhia desenvolve e executa as suas atividades funcionais. Em outras palavras, um conjunto crtico de ativos e capacidades so subjacentes vantagem posicional da firma. Assim, a fim de atingir uma posio favorvel no mercado, a organizao deve fazer o esforo de entender e mapear os seus recursos. A literatura classifica estes recursos em duas categorias: Ativos Superiores, referem-se aos recursos com qualidade tangvel que podem ser etiquetados com um preo (valorizados) e, como tais, so contabilizados em termos monetrios; e Ativos ou Aspectos Distintivos de Competncia, que contribuem integrao dos ativos superiores da organizao ( a colagem que os mantm unidos). Cada uma dessas competncias representa um complexo pacote de habilidades e conhecimento, sendo operacionalizadas pelos processos organizacionais do negcio, servindo na coordenao das suas atividades e na utilizao dos seus ativos, com o intuito de continuamente aprender e melhorar. As competncias no so fceis de mensurar nem de atribuirlhes um preo, sendo mais um patrimnio cultural da organizao. Alm disso, a maioria delas refere-se a conhecimento tcito, o qual pode ser classificado nas seguintes quatro dimenses (Day et al., 1997): Conhecimento dos empregados; Conhecimento embutido nos sistemas (software, banco de dados, e processos formais); Sistemas de gerenciamento do conhecimento;
50
Polticas de informao. Para efeitos de anlise, esses ativos e competncias podem ser elicitados tomando como base as funes de uma organizao, as quais so: a) Organizao: A estrutura organizacional de uma empresa depende do tamanho, nmero de funcionrios, tipo de negcio (varejo, atacado, comercial, industrial ou de servios), tipo de organizao (centralizada, descentralizada ou matricial). A estrutura organizacional pode ser por funes ou por processos e por produtos ou mercados. b) Marketing: Compreende o estudo da oferta e demanda dos produtos da empresa sob anlise, suas estimativas e a escolha dos segmentos potenciais de mercado. Assim, Kotler (1988) a define como: a anlise, planejamento, implementao e controle de programas destinados a produzir intercmbios convenientes com determinado pblico, a fim de obter ganhos pessoais ou comuns. Depende grandemente da adaptao e coordenao do produto, preo, publicidade e praa, para lograrem uma reao efetiva, dando uma definio bem mais abrangente e bastante aceita no meio acadmico e na indstria.
Cadeia de Valor do Produtor
Cadeia de Valor do Fornecedor
Cadeia de Valor da Empresa
Cadeia de Valor do Canal
Cadeia de Valor de Comprador
Sistema de Valores
INFRA-ESTRUTURA DA EMPRESA ATIVIDADES DE APOIO GERENCIA DE RECURSOS HUMANOS DESENVOLVIMENTO DE TECNOLOGIA AQUISIO
LUCRO
LOGISTCA INTERNA OPERAES LOGSTICA EXTERNA MARKETING & VENDAS SERVIO
ATIVIDADES PRIMRIAS
Figura 4.2 Cadeia do Valor (Porter, 1985)
c) Produo: O nvel de desempenho de uma empresa mede-se, basicamente, por meio da sua produtividade na gerao de bens ou servios, e depende da sua organizao, planos, nvel tecnolgico,
51
financiamento, matrias primas, mo-de-obra e muitos outros aspectos. Note-se que da problemtica de gerenciar com qualidade os processos de logstica na produo de bens, (vide Figura 4.2), surgiu a idia de ampliar este conceito a todos os processos da organizao, denominando essa abordagem de qualidade total. A gerncia deste tipo de organizao, orientada qualidade total, realizada atravs da gesto por processos (de negcios), a qual leva implcito o conceito de gesto de processo. d) Finanas: O objetivo das finanas em uma empresa est orientado a desenvolver roteiros e aes com a finalidade de conseguir o mximo rendimento dos ativos sob sua responsabilidade. Isto passa por obter recursos monetrios ou quase-monetrios, das diversas fontes de financiamento, procurando sempre os menores juros e os prazos mais longos, para aplic-los na aquisio de matrias-primas, remunerao da mo-de-obra, pagamentos dos servios bsicos, e em oferecer facilidades de crdito a seus clientes. e) Recursos Humanos: Como evidente, o sucesso da firma depende do pessoal em quem se confia a execuo das diversas operaes para que esta alcance os seus objetivos. Portanto, deve-se pr uma nfase especial nos funcionrios, oferecendo-lhes um ambiente adequado para o desenvolvimento das suas habilidades e capacidades. No entanto, isto deve estar acompanhado de estratgias adequadas de motivao, tais como: remunerao justa, treinamento e prmios, visando sempre o enriquecimento do trabalho.
4.2.2.2 O framework dynamic capabilities O framework do dynamic capabilities uma evoluo do resource-based view, enfatizando a caracterstica dinmica das capacidades que uma organizao deve possuir para lidar com um ambiente em mudana contnua. As batalhas competitivas globais nas indstrias de alta tecnologia, por ex. as de semicondutores e software, tm demonstrado a necessidade de uma extenso ao paradigma de recursos. As companhias ganhadoras no mercado global tm sido aquelas que demonstraram respostas oportunas, e uma rpida e flexvel inovao
52
de produto, acoplado com a capacidade efetiva de coordenar e recolocar as competncias internas e externas da organizao nas diferentes reas que as precisarem, caracterizando, assim, o uso dinmico destas. Teece et al. (1997) definem as capacidades dinmicas como a habilidade da firma para integrar, criar e re-configurar as competncias internas e externas para acompanhar o ambiente em mudana contnua. As capacidades dinmicas, assim, refletem a habilidade da organizao para atingir novas e inovadoras formas de vantagem competitiva dadas as dependncias e condies do mercado (LeonardBarton, 1992). Este framework define como competncias aos ativos intelectuais especficos empresa, mas que esto ensamblados ou imersos em conjuntos integrados e estendendo-se alm dos indivduos e grupos que existem na organizao, permitindo a realizao de atividades distintivas (rotinas e processos). Tais competncias so tipicamente viabilizadas atravs de mltiplas linhas de produto e podem se estender a parceiros externos na forma de alianas estratgicas.
4.3 A anlise de processos e o TQM Tendo como premissa que uma organizao somente alcanar o sucesso se possuir adequados nveis de qualidade na execuo de suas atividades de produo, de apoio e de negcio, surge a necessidade de avaliar e analisar os processos sob a tica da qualidade total, visando encontrar os pontos fortes e de melhoria no seu percurso, sua misso, objetivos e procedimentos, com o propsito de implementar medidas corretivas e de consolidao, conforme seja o caso. Na atualidade, com os mercados altamente competitivos, fundamental que as organizaes entendam o conceito de qualidade, embora este seja um termo bastante abstrato e subjetivo, pois depende do ponto de vista e da abordagem. Diferentes definies podem ser encontradas na literatura, no entanto, acredita-se que a definio de qualidade total a seguir preenche adequadamente a idia de qualidade sob um enfoque global: Qualidade Total uma estratgia que visa satisfazer os requisitos dos clientes externos, assim como dos acionistas, a um custo adequado, levando em conta o meio ambiente. Para tanto, requer liderana gerencial e envolvimento das pessoas, de todos os nveis da organizao, em um
53
esforo conjunto e integrado de melhoria contnua e inovao dos processos, produtos e servios, sustentado e motivado por uma cultura organizacional apropriada para este fim e profundamente enraizada.[(Macedo-Soares & Chamone, 1994) em (Fiorini, 1995)]. Uma abordagem de gerenciamento que, justamente, visa atingir esse objetivo a de Gesto por Processos ou de Gerenciamento da Qualidade Total (TQM - Total Quality Management), a qual est orientada a garantir que os processos-chave do negcio sejam monitorados, acompanhados e melhorados permanentemente. Esta definida por Magalhes (1993) como o conjunto de estratgias que envolvem toda a organizao, tratando a questo de qualidade como um objetivo estratgico a ser alcanado atravs do melhoramento contnuo de produtos e servios, em funo de especificaes, necessidades e expectativas dos clientes. Esta abordagem tem embutido o conceito de cadeia de valor, proposto por Porter (1985), vide Figura 4.2, a qual define-se como os diferentes passos pelos quais passa um produto ou servio antes de chegar s mos do cliente, de modo que em cada passo cabe agregar valor ao produto/servio. A gesto por processos requer tcnicas especficas de gesto de processos orientadas soluo de problemas, a melhoria de processos e, a identificao e documentao de processos chave.
4.4 As Metforas de Morgan Do ponto de vista da Modelagem Empresarial, a anlise organizacional pode ser uma importante fonte para identificar as diversas entidades e os atributos relevantes ao negcio. No entanto, a anlise organizacional tem evoludo desde aquela viso que enxergava a organizao como uma estrutura esttica e isolada, para uma mais ampla, que considera o contexto onde esta atua e as suas interrelaes com o ambiente, bem como o seu comportamento. Nesse sentido, em Morgan (1996) encontra-se uma proposta interessante para olhar organizao sob diferentes ticas ou vises, que ele chama de metforas: Mquina, Organismo, Crebro, Cultura, Sistema Poltico, Priso Psquica, Fluxo e Transformao, e Instrumento de Dominao.
54
Cada uma dessas metforas fornece uma abordagem especfica de anlise organizacional, mas todas elas em conjunto oferecem uma viso mais rica e abrangente da organizao, fazendo com que a anlise do conjunto seja maior que a soma das anlises parciais.
4.4.1 A Organizao vista como Mquina Esta metfora est sustentada na teoria clssica da administrao e na administrao cientfica. Os tericos clssicos, ao projetarem as organizaes, agiram exatamente como se estivessem projetando uma mquina. No caso da administrao cientfica, defendeu-se o uso de estudos de tempos e movimentos como meio de analisar e padronizar as atitudes de trabalho. Este tipo de organizaes so chamadas burocracias e so consideradas como sendo mais eficazes em ambientes estveis ou protegidos, e menos eficazes em ambientes turbulentos e competitivos, como os vividos na atualidade (2003). As organizaes burocrticas, de forma geral, tm maior dificuldade em se adaptarem a situaes de mudana, porque so planejadas para atingir objetivos predeterminados e no para a inovao.
4.4.2 A Organizao vista como Organismo A idia de que as organizaes so parecidas com organismos vivos dirigiu a ateno para assuntos mais genricos, tais como sobrevivncia, eficcia organizacional e a sua relao com o ambiente. Isto levou a compreender a importncia das necessidades sociais no local de trabalho e como os grupos de trabalho podiam satisfazer essas necessidades. Descobriu-se tambm, que a organizao informal podia existir junto organizao formal, concebida pela viso mecanicista. O enfoque de sistemas, definido inicialmente por Bertalanffy (1950), sustenta-se no princpio de que as organizaes vistas como organismos, so entes abertos ao meio ambiente e devem, portanto, atingir uma relao apropriada com este, caso queiram sobreviver. Este enfoque preocupa-se com a atividade ambiental imediata, definida pelas interaes organizacionais diretas (clientes,
55
fornecedores, organizaes governamentais e no governamentais), bem como do contexto mais amplo ou ambiente mediato (aspectos sociais, econmicos polticos e tecnolgicos), conforme definido anos depois em Porter (1985) e Day et al. (1997).
4.4.3 A Organizao vista como Crebro Esta metfora parte da premissa que a organizao, de modo similar ao crebro, um sistema de processamento de informaes capaz de aprender a aprender, e que ambos podem ser concebidos para refletir os princpios hologrficos. Isto significa que a organizao toda pode ser contida em todas as suas partes ou funes ou unidades que a compem, de maneira que a partir de cada uma delas esta possa ser reconstruda, pois cada uma das partes poderia representar o todo. 4.4.4 A Organizao vista como Cultura A metfora da cultura foca a ateno no lado humano da organizao, ressaltando o significado simblico de cada aspecto virtual da vida organizacional. Estes aspectos podem ser a linguagem, normas, folclore, cerimnias e outras prticas sociais que comunicam ou expressam ideologias-chave, bem como os valores e crenas que guiam a ao. Da o interesse por administrar a cultura corporativa, como se esta fosse o elemento de ligao normativo (amlgama) que mantm a organizao unida. Nesse sentido, as crenas e as idias que as organizaes possuem de si mesmas, bem como daquilo que pensam fazer com respeito a seu meio ambiente, influenciam sobremaneira na materializao de seus objetivos, encorajando-os tambm para a formulao e o estabelecimento da sua estratgia empresarial. 4.4.5 A Organizao vista como Sistema Poltico diferena de outras vises que olham s organizaes como empreendimentos interligados e racionais que perseguem um objetivo comum, a metfora poltica encoraja olhar as organizaes como redes de pessoas
56
interdependentes com interesses divergentes que se unem com o propsito de satisfazer as suas necessidades bsicas (ganhar dinheiro), desenvolver uma carreira profissional ou de perseguir metas fora de seus trabalhos (lazer, religio). No mbito organizacional, os interesses explicam-se em termos de tarefas, carreira e vida pessoal; a primeira tem a ver com o cargo atual do empregado, o segundo com as questes de personalidade, atitude, crenas, etc. e o terceiro com o seu relacionamento com o mundo exterior.
4.4.6 A Organizao vista como Priso Psquica Esta metfora sugere que as organizaes so fenmenos psquicos, ou seja, o produto de processos conscientes e inconscientes, no qual as pessoas podem ficar prisioneiras das imagens, idias, pensamentos e aes que esses processos acabam gerando. Assim, pressupostos falsos, crenas preestabelecidas, regras operacionais sem questionamento e numerosas outras premissas e prticas podem combinar-se para formar pontos de vista muito estreitos do mundo, fornecendo tanto uma base como uma limitao para aes organizadas. Pois, enquanto criam um modo de enxergar, sugerindo uma forma de agir, tendem tambm a gerar maneiras de no ver e de eliminar a possibilidade de aes associadas a vises alternativas da realidade.
4.4.7 A Organizao vista como Fluxo e Transformao Morgan destaca que uma organizao que realmente queira entender o seu ambiente, deve comear primeiro a tentar entender-se a si mesma, uma vez que a compreenso do ambiente sempre uma projeo de si prpria. Para isto, baseiase na teoria da autopoiesis (Maturana & Varela, 1980), a qual argumenta que o fato do sistema interagir com seu ambiente facilita a sua prpria auto-reproduo. De acordo com esta tica, muitas organizaes se encontram com srios problemas de lidar com o mundo exterior por no reconhecerem que este uma parte de seus respectivos ambientes. Nesse sentido, deve-se considerar que as organizaes mudam e se transformam em conjunto com seu meio ambiente (fornecedores, clientes, trabalhadores, coletividade, concorrncia, entre outras),
57
levando a compreender que o padro de organizao que se vai revelando com o passar do tempo evolutivo.
4.4.8 A Organizao vista como Instrumento de Dominao Morgan afirma que o real valor desta perspectiva que a mesma demonstra que at as formas mais racionais e democrticas de organizao podem resultar em modelos de dominao..., por exemplo, objetivos racionais de maior rentabilidade ou de crescimento organizacional provocam, no poucas vezes, impactos negativos intrnsecos nas organizaes, tanto nos empregados como no seu ambiente, embora estes no sejam necessariamente intencionais. Assim, uma maior rentabilidade pode significar um maior esforo dos funcionrios, o qual no necessariamente implique uma melhoria nas suas remuneraes. Em outros termos, aquilo que racional desde o ponto de vista da organizao pode ser catastrfico na tica do funcionrio.
4.5 Ontologias Um sistema de memria corporativa (SCM) um tipo de sistema baseado em conhecimento (Knowledge Based System - KBS) e, portanto no seu desenvolvimento surgiro problemas de: Aquisio de conhecimento; Conceituao; Formalizao; Implementao e; Manuteno. Para lidar com as trs primeiras utiliza-se a abordagem ontolgica, onde uma ontologia define um conhecimento do domnio de uma maneira genrica tal que o entendimento do mesmo aceito pela comunidade desse domnio. Em outras palavras, uma Ontologia especifica um conhecimento conceitual para uma determinada rea do conhecimento, sendo a essncia do conhecimento desse domnio. A justificativa para a utilizao de ontologias que esta permite a
58
reutilizao
desses
conceitos,
facilitando
ao
mesmo
tempo
seu
compartilhamento e disseminao (Van Heijst et al., 1996).
Do ponto de vista da apresentao, uma ontologia pode ser:
Altamente informal
quando realizada em linguagem natural, ex.
glossrios; Semi-informal
quando esta em uma forma restrita e
estruturada de linguagem natural, ex. glossrios estruturados que incluem atributos; Semi-Formal
quando est em uma linguagem definida
formalmente e artificial, ex. Ontolingua (Fikes et al. 1997); Rigorosamente Formal
quando est em uma linguagem com
semntica formal, com teoremas e provas de tais propriedades, como completude e validade, ex. TOVE (Grninger & Fox, 1996).
4.5.1 Definies Na literatura encontram-se muitas definies de ontologias. A seguir apresentam-se algumas delas:
Uma ontologia uma especificao explicita de uma conceituao. (Gruber, 1993).
Uma ontologia pode ser vista como: (Guarino & Giaretta, 1995) uma especificao de uma conceituao uma disciplina filosfica um sistema conceitual informal uma conta semntica formal uma representao de um sistema conceitual via uma teoria lgica o vocabulrio utilizado por uma teoria lgica uma meta-especificao de uma teoria lgica
59
Uma ontologia define os termos bsicos e os seus relacionamentos, compreendendo o vocabulrio de uma rea-tpico, bem como as regras para combinar esses termos, e os relacionamentos para definir extenses a esse vocabulrio. (Neches et al., 1991)
Uma ontologia um conjunto de termos estruturado hierarquicamente para descrever um domnio que pode ser utilizado como fundamento para uma base de conhecimento. (Swartout et al. 1997)
Uma ontologia prov os meios para descrever explicitamente a conceituao que est por atrs do conhecimento representado em uma base de conhecimento. (Bernaras et al. 1996)
Entretanto, para efeitos do presente trabalho utilizaremos a seguinte definio:

Uma ontologia uma especificao explcita e formal de uma conceituao compartilhada, pelas seguintes razes: (Studer et al., 1998)
Formal, implica que pode ser interpretado pelo computador; Explcito, quer dizer que os conceitos, propriedades, relacionamentos, funes, restries e axiomas so explicitamente definidos; Compartilhada, significa que um conhecimento consensual; e Conceituao, nos diz que um modelo abstrato de algum fenmeno do mundo real.
Uma questo relevante de mencionar que a abordagem ontolgica traz o compromisso de um acordo para o uso do vocabulrio de uma maneira coerente e consistente.
4.5.2 Componentes de uma Ontologia Os principais elementos de uma ontologia so conceitos, relacionamentos e axiomas. Os conceitos so a sua unidade bsica e esto vinculados entre si atravs de uma rede de relacionamentos. A ontologia formada por um grupo de
60
conceitos e cada conceito tem um conjunto de propriedades que so denominados de atributos. Ex. o conceito Fornecedor tem como atributos cdigo, nome, endereo. Os axiomas so regras que prevalecem em uma dada ontologia (Martinez-Bejar, 2000, Fernandez-Breis et al., 2002, Fernandez-Breis et al., 2001), so sentenas que so sempre verdadeiras. Ex. Funcionrio.idade igual a data_de_hoje menos Funcionrio.data_de_nascimento. Os axiomas podem ser estruturais, por ex. A is_a B e no estruturais, por ex. F=m.a (Fora igual a massa pela acelerao). Os relacionamentos so qualquer subconjunto de um produto de n conjuntos, ou seja R: C1xC2x ... x Cn. Alguns tipos de relacionamentos ontolgicos so: Taxonomia: - especializa conceitos e usa noes de classe e sub-classe em uma hierarquia is-a. Este relacionamento tem as propriedades de ser no-reflexiva, transitiva e assimtrica. Ex. Estudante e Funcionrio um tipo de Pessoa. Mereologia: - um relacionamento part-of e possui as propriedades de ser no-reflexiva, no-transitiva e assimtrica. Isto quer dizer que um conceito parte de outro conceito, e pode apresentar-se em pares de: membro/conjunto, parte/todo, local/rea, fase/processo e parte/objeto. Ex. O Pisto parte do Motor e por sua vez o Motor parte do Carro. Temporal ou Cronolgica: - um relacionamento de precedncia entre os conceitos relacionados, por ex. Trocar_Lampada s acontece depois que Lampada_Queimada. Este relacionamento possui as propriedades de ser no-reflexiva, transitiva e assimtrica. Permite o estabelecimento de relacionamentos temporais entre conceitos, e particularmente til para a modelagem de tarefas. Topologia: um relacionamento connect-to que define a teoria das conexes entre conceitos, por ex. A se conecta a B. Possui as propriedades de ser reflexiva, no transitiva e simtrica. Se A se conecta a B, ento B se conecta a A. Este relacionamento til quando se quer extrair da ontologia que outros conceitos esto relacionados a um determinado conceito. No entanto na modelagem de sistemas muito mais relevante o conceito de influncia, o que seria tambm uma conexo, mas s em um sentido. No presente trabalho se utiliza esta
61
ltima conceituao. Assim, A afeta B, mas B no afeta A ou B afetada por A.
Alguns autores consideram como mais um componente as instncias, que so elementos de um conceito.
4.5.3 Tipos de Ontologia As ontologias podem ser classificadas de acordo com o seu contedo em: Ontologia do Domnio, quando se elicita os termos de uma rea especifica, por exemplo a ontologia da rea de marketing; Ontologia da Tarefa, quando se elicita os termos relevantes a uma atividade especfica, por exemplo a ontologia do procedimento de compras e; Ontologia de uso Geral, quando se elicita termos de uso comum como coisas, eventos, tempo espao, comportamento, funo (Mizoguchi et al., 1995). Por outro lado, a ontologia pode tambm ser classificada de acordo com questes da sua conceituao como: Ontologia da Representao, a qual elcita os termos para formalizar um certo tpico, por exemplo os formalismos para recuperao do conhecimento; Ontologia Genrica, quando esta reutilizvel atravs de vrios domnios; Ontologia do Domnio, reutilizvel no domnio e; Ontologia da Aplicao, quando somente utilizvel em uma aplicao especfica. (Van Heijst et al., 1997).
4.5.4 Ontologia da Organizao Empresarial No campo da organizao e da empresa encontra-se um conjunto de ontologias para a modelagem empresarial. Entre estas temos: (Uschold e Grninger, 1996) Meta-Ontologia: Define os conceitos de Entidade, Relacionamento, Papel, Ator e Estado (de casos); Ontologia de Atividades e Processos: Inclui os conceitos de Atividade, Recurso, Plano e Capacidade; Ontologia da Organizao: Define os conceitos de Unidade
Organizacional, Entidade, Controle e Posse;
62
Ontologia da Estratgia: Define os conceitos de Propsito, Estratgia, Meta e Suposies; Ontologia de Marketing: Define os conceitos de Venda, Produto, Vendedor, Cliente e Mercado.
Observa-se que as trs primeiras esto conceitualizadas para um nvel de anlise alto e mdio, enquanto as duas ltimas so orientadas definio de uma ontologia para tpicos especficos como so Estratgia e Marketing, no tratando detalhes de mais baixo nvel, como por exemplo os atributos destas entidades, itens que so relevantes para uma ontologia a nvel de estratgia de negcios que sirva de base para a criao de uma memria corporativa estratgica. Justamente esta ausncia, da existncia de uma ontologia nesse nvel de detalhe e abrangncia, motivou o estudo de uma srie de teorias e abordagens da anlise estratgica, as quais foram analisadas sob a abordagem ontolgica, tendo como resultado a definio de um conjunto de conceitos, atributos e os seus relacionamentos que foram, logo, utilizados na criao da base de conhecimento da memria estratgica. Neste ponto relevante enfatizar algumas caractersticas das Ontologias: (Faquhar em ontolingua@hpp.stanford.edu electronic mailing list (Gomez-Perez, 1999) Uma ontologia expressa o consenso do conhecimento de uma comunidade de pessoas em um domnio; As pessoas utilizam a ontologia como uma referncia de termos definidos em forma precisa; Uma ontologia fornece uma linguagem suficientemente expressiva para que as pessoas possam dizer aquilo que eles querem dizer; Uma ontologia estvel; Uma ontologia pode ser utilizada para resolver uma variedade de problemas desse domnio; Uma ontologia pode ser utilizada como ponto de partida para a construo de mltiplas aplicaes.
63
4.5.5 Mtodos para a Descrio de Ontologias Entre os mtodos mais representativas para a descrio de ontologias temos: (Fernandez-Lopez, 1999) TOVE TOronto Virtual Enterprise (Grninger & Fox, 1996); Methodology for Building Ontologies (Uschold & King, 1995); SENSUS: (Swartout et al., 1997); A Metodologia de Bernaras et al., (1996); Methontology (Gomez-Perez, 1998). 4.5.5.1 TOVE (Toronto Virtual Enterprise): (Grninger & Fox, 1996) Este mtodo esta baseado na experincia do desenvolvimento da ontologia do projeto TOVE, o qual modelou o domnio dos processos e atividades do negcio. O mtodo envolve previamente a criao de um modelo lgico de conhecimento que precisa ser especificado por meio da ontologia. Grninger e Fox propem o seguinte roteiro:
Definir um conjunto de Cenrios de Motivao; Definir um conjunto de Questes de Competncia Informais que a
ontologia deve responder a fim de suportar os cenrios de motivao;

Definir a Terminologia da ontologia para o qual utiliza-se uma Lgica de
Primeira Ordem (First-Order Logic);

Redefinir
formalmente as Questes de Competncia usando a
terminologia e a lgica de primeira ordem;

Definir a semntica e as restries sobre a terminologia usando a lgica
de primeira ordem.
4.5.5.2 Methodology for Building Ontologies (Uschold & King, 1995) Este mtodo esta baseado sobre as experincias no desenvolvimento do Enterprise Ontology, uma ontologia para modelagem de negcios. O mtodo
64
estabelece um conjunto de linhas de ao para o desenvolvimento de ontologias, tendo estas a seguinte seqncia:
Identificar o propsito e escopo; Criao da ontologia; Captura da ontologia; Codificao da ontologia; Integrao das ontologias existentes; Avaliao; Documentao; Diretrizes para cada fase.
4.5.5.3 SENSUS (Swartout et al., 1997) A metodologia SENSUS utiliza como facilitador uma ontologia do mesmo nome desenvolvida pelo ISI (Information Sciences Institute - University of Southern California). Esta ontologia baseada em linguagem natural e fornece uma ampla estrutura conceitual, consta de mais ou menos 70,000 itens os quais representam objetos, entidades, qualidades e relacionamentos. Portanto, a ontologia SENSUS fornece uma base de conceitos estruturada hierarquicamente, a mesma que suporta trabalhos de traduo via mquina. O roteiro deste mtodo o seguinte:
Identificar os termos base (semente); Vincular os termos base ontologia SENSUS (manualmente); Incluir os ns que esto na rota raiz; Agregar todas as sub-rvores envolvidas, utilizando a heurstica: se
muitos ns em uma sub-rvore so relevantes, ento os outros ns na sub-rvore tambm so relevantes.
4.5.5.4 A Metodologia de Bernaras et al. (1996) Esta proposta de metodologia tem origem no projeto Esprit KACTUS (1996). Um dos objetivos deste projeto era investigar quo fatvel era o re-uso de conhecimento em sistemas tcnicos complexos e o papel que podiam cumprir as
65
ontologias para suporta-las. O mtodo sugere a criao de uma ontologia preliminar para o seu posterior refinamento e aumento com novas definies. A seguir detalha-se o processo: Especificao da aplicao sob estudo, para a qual se cria a ontologia; Projeto preliminar baseado em categorias ontolgicas relevantes de alto nvel. Pode-se optar pelo reuso quando existirem ontologias de aplicao j prontas, ou pela criao de uma nova desde o scratch (inicio) quando o reuso no seja possvel; Refinar e estruturar a ontologia do domnio, a mesma que foi definida no passo anterior.
4.5.5.5 Methontology (Gomez-Perez98) Este mtodo foi desenvolvido pelo Laboratrio de Inteligncia Artificial da Universidad Politecnica de Madrid, Espanha. O Methontology permite a construo de ontologias no nvel de conhecimento e para sua realizao prope trs camadas de atividades:
Gerncia: Inclui o Planejamento, Controle e Segurana da Qualidade; Desenvolvimento: Inclui a Especificao, Conceituao, Formalizao,
Implementao e Manuteno;
Suporte: Inclui a Aquisio de Conhecimento, Integrao, Avaliao,
Documentao e Gerncia de Configurao.
4.6 Arquiteturas de Software conhecido que o tamanho e a complexidade dos sistemas de software gera problemas no desenho da arquitetura, indo alm das questes de algoritmos e da estrutura de dados. A arquitetura de software inclui aspectos estruturais como: (Garlan & Shaw, 1994) a organizao total do sistema e a criao de uma estrutura de controle; a existncia de protocolos de comunicao, sincronizao e acesso aos dados; a atribuio de funcionalidades aos elementos do projeto;
66
a sua distribuio fsica; a composio dos elementos do projeto; o seu escalonamento e desempenho; a seleo entre alternativas de projeto. 4.6.1 Definio Segundo Myron Ahn (Hohmann, 2003) uma arquitetura de software a soma de mdulos no triviais, processos e dados, as suas estruturas e relacionamentos, fornecendo uma viso de como estes podem ser estendidos e modificados, conhecendo as tecnologias sobre as quais dependem, tudo isso com o intuito de deduzir as suas exatas capacidades e flexibilidade, possibilitando a formao de um plano para a implementao ou modificao do sistema.
4.6.2 Caractersticas Em geral, utilizam-se arquiteturas porque uma boa arquitetura um elemento chave para o sucesso do sistema no longo prazo. Assim, entre as suas caractersticas desejadas temos: (Hohmann, 2003) Fomentar a longevidade: A maioria das arquiteturas vivem mais que as equipes que a criaram; Estabilidade: Assegura-se que uma mnima quantidade de re-trabalho seja necessria quando as funcionalidades do sistema precisem ser estendidas; Suportar uma Mudana Gradativa e Natural: Facilitando uma mudana natural do sistema; Lucrativa: Assegura que a estrutura de custos associada a sua sustentabilidade seja razovel, isso acontece quando for bem feita; Favorecer a Limitao do escopo: Influenciando naquilo que deve estar dentro e fora do sistema.
As arquiteturas tambm favorecem criao de uma estrutura social na organizao de desenvolvimento de software, pois alavanca os pontos fortes da
67
equipe que criou a arquitetura e minimiza os seus pontos fracos. Assim mesmo, tambm pode criar uma vantagem competitiva sustentvel no tempo, quando a arquitetura tecnicamente sofisticada e difcil de duplicar.
4.6.3 O Processo de Criao de uma Arquitetura Segundo Hohmann (2003) qualquer arquitetura de software comea com a apresentao das intenes do projeto por parte da equipe de desenvolvimento. Essa verso inicial pode-se ver como um ser humano quando criana, todo completo, mas imaturo e possivelmente instvel. No decorrer do tempo a arquitetura amadurece e se robustece, na medida que seus usurios e criadores ganham confiana, sendo tudo isso um processo iterativo. Isto nos induz a pensar que a criao de uma arquitetura deve estar baseada em uma abordagem pragmtica, sustentada em padres arquiteturais provados e refinados. Onde provado significa que este tem sido utilizado efetivamente em no poucas aplicaes e refinado significa que algum se ocupou de pesquisar, entender, codificar e documentar esse padro, de tal maneira que possa ser comunicado a outros arquitetos. Em outras palavras, um conhecimento assimilado que qualquer um pode utilizar.
4.6.4 Princpios Arquiteturais Os padres arquiteturais capturam as organizaes estruturais
fundamentais dos sistemas de software. Cada padro aponta questes tcnicas da arquitetura, fornecendo descries dos subsistemas, as suas responsabilidades e explicando como estes interagem para resolver um problema particular. A abordagem pragmtica, quando cria uma arquitetura de software, explora os vrios padres arquiteturais e seleciona um que razoavelmente trate essa situao particular. Portanto, necessrio adaptar a arquitetura que satisfaz essas necessidades. O Processo de adaptao e as escolhas de projeto so guiadas pelos seguintes princpios arquiteturais. (Hohmann, 2003)
68
Encapsulamento: A arquitetura organizada ao redor de peas separadas e relativamente independentes que ocultam detalhes internos de implementao, um do outro; Interfaces: Deve-se definir a forma em que os subsistemas interagem; Acoplamento (Fraco): Refere-se ao grau de interconexes entre as diferentes partes do sistema; Granularidade Apropriada: determinada pelas tarefas associadas ao componente, esta relacionado ao tamanho do componente; Coeso Alta: Descreve as atividades relacionadas dentro de um componente ou entre um grupo de deles; Parametrizao: O nmero de parmetros deve ser apropriado, assim como os seus tipos. Estes permitem ao usurio ajustar as operaes do sistema; Deferimento: Adiar decises arquiteturais quando exista algum tipo de incerteza.
4.6.5 Estilos Arquiteturais Embora no exista ainda uma bem aceitada taxonomia para arquiteturas de software, pode-se identificar uma srie de padres ou estilos arquiteturais que, atualmente, formam o repertrio bsico de todo arquiteto de software. Entre estes temos: (Garlan & Shaw, 1994) a) Tubos e Filtros: Cada componente (filtro) possui um conjunto de entradas e de sadas. Cada componente recebe uma srie de dados de entrada, processa estes dados, envia os dados resultantes para os tubos de sada. Os conectores so os tubos de dados (pipes). Especializaes deste estilo so os pipelines; b) Organizao Orientada a Objetos e Abstrao de Dados: Este estilo possui como caracterstica forte o fato dos dados e das operaes estarem encapsulados em um componente, o qual chama-se de objeto. A comunicao entre componentes ocorre a partir da troca de mensagens entre esses.
69
c) Invocao Implcita, baseada em eventos: Neste estilo em vez de invocar um procedimento, o componente pode anunciar (broadcast) um ou mais eventos, os quais implicitamente causam a invocao de procedimentos em outros mdulos; d) Camadas: O estilo camada organizado de maneira hierrquica. Cada camada tem o objetivo de prover servios bem definidos para a camada seguinte, a qual funciona como um cliente para a camada anterior. Cada camada pode possuir vrios outros componentes. A alterao de uma camada no pode atingir mais de duas outras camadas, visto que uma camada se comunica, no mnimo, com uma camada e, no mximo, com duas. Esta caracterstica torna este estilo forte para reuso; e) Repositrios: No estilo repositrios, existem dois elementos distintos: a base central de dados (blackboard) e os componentes que executam operaes na referida base, inclusive suas intercomunicaes. Os componentes so chamados de fontes de informao (knowledge source). Os estados assumidos pela base central de dados o principal motivador de disparo de aes nos componentes que executam tarefas. Uma categoria alternativa quando dado um fluxo de entradas de transaes, estas acionam a seleo de processos a executar-se, neste caso o repositrio pode ser um banco de dados tradicional; f) Interpretadores: Inclui o pseudoprograma que esta sendo interpretado e a mquina de interpretao. O pseudoprograma inclui por sua vez o programa e o estado da sua execuo que esta sendo simulado; g) Outras arquiteturas: Entre estas se tm: Processos distribudos (anel ring- e estrela - star), organizaes de programa principal e sub-rotinas, especficas ao domnio, de transio de estado e processos. de controle de
4.7 A Tecnologia de Agentes Durante a ultima dcada, a abordagem de agentes tem sido desenvolvida com certa nfase no campo da Inteligncia Artificial e recentemente, tambm, da Engenharia de Software. Em conseqncia, muitos exemplos podem ser
70
encontrados em uma ampla variedade de aplicaes, variando desde pequenos sistemas, como filtros para e-mails, a sistemas complexos e de misso crtica, como os de controle de trfico areo.
4.7.1 Agentes - Conceitos Definies concretas acerca de agentes de software ainda no existem na literatura, porque cada autor as define sob sua prpria tica e, portanto, de forma diferente. Uma das definies mais freqentemente citadas a de Woldridge & Jennings (1995), esta diz que: um agente um sistema de computao encapsulado situado em um dado ambiente e capaz e executar aes autnomas e flexveis para alcanar os objetivos de projeto. De uma forma mais detalhada, podemos dizer que os agentes de software (Jennings, 2001): so entidades que resolvem problemas claramente identificados com limites e interfaces bem definidos; so embutidos num ambiente particular sobre o qual eles tem um controle parcial e capacidade de observao. Eles recebem inputs relacionados ao estado do seu ambiente atravs de sensores e geram outputs no seu ambiente atravs de executores; so projetados para realizar um papel especfico; possuem controle sobre seu estado interno e comportamento; so pr-ativos e reativos; possuem a capacidade de cooperar com outros agentes para resolver problemas complexos.
O estado de um agente formalizado pelo conhecimento e expresso pelos componentes mentais de pensamentos, metas e capacidades (OMG, 2000; Shoham, 1993). Os agentes podem ser classificados, de forma geral, como agentes de informao, agentes de tarefa e agentes de interface, e cada um deles, por sua vez, pode ter outras sub-classificaes, por exemplo, os agentes de descoberta, busca e recuperao so alguns tipos de agentes de informao. Uma abordagem baseada em agentes utilizada quando se requer do software a desenvolver, que este tenha caractersticas quase-humanas como:
71
aparente
inteligncia,
habilidade
social,
capacidade
de
aprendizado,
adaptabilidade, tomada de decises orientada s metas. A principal razo de no usar objetos que estes so baseados sobre uma analogia com objetos inanimados, enquanto os agentes so baseados sobre uma analogia com objetos animados (tipicamente seres humanos). Noutras palavras, os objetos - encapsulam estado e so reativos, ou seja, sempre executam mtodos quando invocados; enquanto os agentes - encapsulam estado e comportamento, so pr-ativos, orientados s metas, tentando atingir um propsito determinado.
4.7.2 Propriedades Para que uma entidade de software seja considerada um agente, so necessrios pelo menos trs propriedades: autonomia, interatividade e
adaptatividade. Outras propriedades so opcionais. A seguir apresentamos essas propriedades: 1. Autonomia. Habilidade de alcanar seu objetivo sem intervenes externas (humanos ou outros agentes) diretas. O agente deve ter controle sobre seu comportamento e seu estado interno, podendo decidir quando agir. A autonomia tem dois aspectos, o ser dinmica, quando o agente de software pode dizer vamos fazer algo, caraterizando a proatividade e o ser imprevisvel, quando o agente de software pode dizer no. 2. Interatividade (ou Habilidade Social). Habilidade de se comunicar com o seu ambiente e outros agentes (quando necessrio) visando completar seu objetivo. 3. Adaptatividade (ou Aprendizado). Habilidade de acumular conhecimento baseado nas experincias passadas e conseqentemente modificar seu comportamento em resposta as mudanas no ambiente. A inteligncia de um agente a quantidade de comportamento aprendido e a possvel capacidade de raciocnio que o agente possa adquirir. 4. Persistncia. Habilidade de executar continuamente estado interno consistente. 5. Mobilidade. Habilidade de se transportar para um outro ambiente onde ser executado. mantendo seu
72
4.7.3 Tipos de Agentes Da mesma forma que existe inmeras definies de agentes, encontra-se na literatura uma grande diversidade de taxonmias de agentes, uma delas a que os classifica em agentes interface, tarefa e de informao (Sycara et al., 1999), vide Tabela 4.1. Agentes Interface Tarefa Descrio
Coleta e apresenta informaes relevantes podendo interagir com o usurio para obter informaes adicionais e confirmao. Suporta vrias interfaces de consulta (telas formulrios, grficos, menus e linguagens). Recebe a consulta do usurio via o agente Interface. Com a ajuda dos Brokers, determinam quais dos agentes contm informaes relevantes para uma dada consulta. Decompe o plano de consulta para que seja executada por vrios agentes. Combina os resultados parciais obtidos. Faz uso de ontologias. Fazem a interoperabilidade entre fontes de dados e aplicaes. Podem ter vrias funcionalidades: converso de formato para a fonte (wrapper), monitoramento das fontes, anlise de dados, etc.
Informao
Tabela 4.1 Tipos de Agentes
Os Agentes de Interface, interagem com o usurio recebendo as suas especificaes e entregando-lhe resultados. Estes agentes adquirem, modelam, e utilizam as preferncias dos usurios para guiar a coordenao do sistema, com o propsito de suportar as tarefas dos usurios. Por exemplo, uma aplicao que filtra e-mails de acordo as preferncias do usurio um agente interface. As principais funes de um agente interface incluem; (1) coletar informao relevante dos usurios para iniciar uma tarefa, (2) apresentar informao relevante incluindo resultados e explicaes, (3) perguntar ao usurio por informao adicional durante a soluo do problema e, (4) perguntar ao usurio pela confirmao, quando necessrio. Assim mesmo, permite s aplicaes interagir somente atravs de agentes de interface relevantes, dessa forma o agente tarefa oculta o recolhimento da informao distribuda subjacente e a complexidade da soluo do problema. Os Agentes Tarefa, suportam a tomada de decises via a formulao de planos de soluo de problemas, sendo executados atravs de consultas e trocas de informaes junto a outros agentes de software. Este tipo de agentes tm conhecimento do domnio da tarefa e de quais outros agentes tarefa ou de informao so relevantes para executar varias partes da mesma. Adicionalmente,
73
possuem estratgias para resoluo de conflitos e para fusionar a informao recuperada por meio dos agentes de informao. Um Agente de Informao, um tipo especial de agente de software que deve prover acesso a uma ou mais fontes de informao heterogneas e distribudas, sobre as quais proativamente recupera, analisa, manipula e integra informaes relevantes em prol dos seus usurios ou de outros agentes, de forma preferencialmente just-in-time (Klusch, 1999). Um agente de informao deve
satisfazer uma ou mais das seguintes caractersticas: Gerncia e Aquisio de Informao: capacidade de prover acesso transparente para as fontes de informao. Deve poder recuperar, extrair, analisar e filtrar dados, monitorar fontes e atualizar informaes relevantes em prol de seus usurios ou agentes; Gerncia e Aquisio de Conhecimento: habilidades de adquirir e manter conhecimento sobre ele mesmo e seu ambiente atravs da representao e processamento de ontologias, metadados, perfis, mudana de formato de dados e tcnicas de aprendizado de mquina; Apresentao e Sntese de Informao: habilidade de juntar dados heterogneos e prover, aos seus usurios, uma viso unificada e multidimensional sobre as informaes relevantes.
Outras caractersticas desejveis so: Produzir interaes longas: que envolvem monitoramento de suas fontes visando determinadas condies tal como a atualizao da fonte; Fornecer informaes em diferentes tempos: imediato, peridico e condicional. A Tabela 4.2 exemplifica as trs formas usando uma consulta bolsa de valores; Manter conhecimento sobre seu estado interno (atividades correntes e responsabilidades): para adaptar seu comportamento (por exemplo, criar self-clones ou recusar requisies).
Tempo Imediato Peridico Condicional Exemplo de consulta: Fornea a cotao das aes da empresa x Fornea a cotao das aes de x a cada 30 minutos Fornea a cotao das aes de x somente quando subir 10 pontos
Tabela 4.2 Formas de consulta temporal de um agente
74
Quando uma aplicao desenvolvida para ambientes de rede aberta, distribuda e altamente dinmica, como o caso da internet, utiliza-se um tipo de agente chamado de middle. Estes recebem anncios das capacidades de outros agentes e os armazenam em um banco de dados interno. Dois tipos destes agentes so o agente matchmaker e o agente broker. O primeiro encontra, dado um servio requerido, qual agente pode satisfaze-lo. O segundo, alm de localizar outros agentes, com funcionalidades apropriadas, gerncia o namespace de servios e, a comunicao entre vrios agentes, bancos de dados e aplicaes dentro do ambiente. pertinente observar que o agente matchmaker atua na realidade como um agente de informao, pois seu objetivo encontrar um agente que possa atender uma determinada requisio. No caso do agente broker, este alm de atuar como um agente de informao, tambm atua como um agente tarefa virtual, pois executa determinadas tarefas utilizando outros agentes, previamente cadastrados que realizam funciones especificas. Portanto, pode-se afirmar que a classificao de agentes em interface, tarefa e informao, uma maneira simples e clara de como estes podem ser classificados, encaixando nela qualquer agente de software.
4.7.4 Sistemas Multi-Agentes Outro conceito importante o de sistemas multi-agentes (MAS) que contm agentes que interagem para solucionar problemas complexos que esto alm de suas capacidades individuais. Assim, fazendo uma analogia com a teoria de sistemas, pode-se dizer que o sistema resultante deve ter capacidades alm da simples soma das capacidades dos agentes. Para modelar as aplicaes de sistemas multi-agentes existem diversas metodologias, sendo uma delas MESSAGE (Methodology for Engineering System of Software Agents) (Eurescom, 2001b), a qual uma extenso de metodologias existentes para o desenvolvimento de software orientado a objetos, para aplicaes orientadas a agentes, vide detalhes na seo 4.7. relevante mencionar que o termo agente de informao muitas vezes usado na literatura (Klusch, 1999; Klusch, 2001) para representar sistemas de recuperao/integrao de informao baseados em um conjunto de agentes de software que interagem para fornecer determinada informao ao usurio. Nesse
75
contexto, um agente de informao um MAS porque esta composto por um grupo de agentes que interagem entre eles, tendo um objetivo comum.
4.7.5 A Arquitetura de um MAS Existem inmeras arquiteturas de sistemas MAS que integram diversos tipos de informaes com o propsito de auxiliar aos usurios na execuo efetiva e eficiente de tarefas complexas tais como diagnsticos mdicos, projetos de engenharia, decises bancrias. Nelas comum encontrar a utilizao de agentes que auxiliam a descoberta e localizao de informaes e servios, bem como a disseminao de conhecimento. Um dos desafios de qualquer arquitetura balancear a autonomia das fontes de dados e das aplicaes mediante o uso de agentes de software para a execuo de um trabalho cooperativo. De uma forma geral, a arquitetura baseada em agentes representa um nvel mais alto de abstrao se comparada com a arquitetura de objetos, pois permite a cooperao entre agentes, em vrios nveis, produzindo sistemas de informao cooperativos. Outro aspecto da arquitetura a interoperabilidade semntica, onde ontologias so usadas para descrever os significados dos recursos e das aplicaes (servios), ou seja, utilizada como base na troca de informaes entre agentes, reduzindo ou eliminando os efeitos da discrepncia nos termos. No caso de MAS abertos para a internet, um dos problemas bsicos enfrentados pelos projetistas o problema da conexo entre os agentes, ou seja, encontrar um ou mais agentes que podem ter informaes (ou outras capacidades) necessrias a um outro agente. O fato desse sistema ser aberto (i.e. os
participantes entram e saem a qualquer momento do sistema) e distribudo sobre a internet, impede que haja solues de comunicao do tipo broadcast, pois a rede ficaria sobrecarregada. As duas solues que tem sido propostas para resolver este problema de conexo so: Matchmaking e Brokering (Sycara et al, 1999), sendo a ltima a mais utilizada. Essas abordagens podem ser definidas em termos de aes bsicas de requisio/resposta entre agentes.
76
4.7.5.1 O processo de Matchmaking O processo de Matchmaking permite um agente, que possui um certo objetivo, identificar outro agente que possa realizar este objetivo. Este processo envolve trs diferentes tipos (papeis) de agentes, vide Tabela 4.3.
tem um objetivo que ser alcanado por outro agente (Server) conhece os nomes de outros agentes e suas respectivas capacidades Agente Server tem se comprometido a atender objetivos de outros agentes (Requester) Tabela 4.3 Funes dos agentes no processo Matchmaking
Agente Requester Agente Matchmaker
As interaes entre os trs tipos de agentes mostrada na Figura 4.3.

Agente Matchmaker
Id do agente Classe do servio custo confiabilidade durao caractersticas
Notifica/desabilita seus servios
Resposta:
Id dos n Servers
Requisio para servio: Quais os Servers que podem atender meu pedido de servio?
Agente Server
Requisies para os n Servers Execute o servio Resultado do servio:
Agente Requester
Figura 4.3 Interao entre agentes no processo Matchmaker
Para cada requisio recebida de um agente Requester, o agente Matchmaker tentar associar a requisio com o conjunto de classes de servios registradas pelos Servers. Se ele encontrar, ento, retorna, ao agente Requester, um conjunto ordenado (ranking) dos nomes dos agentes Servers (e respectivas classes de servio) que podem atender o servio requerido. Um exemplo do servio do Matchmaker o de pginas amarelas. Agindo como agente de informao um agente Matchmaker deve informar ao Requester sobre a entrada/sada de agentes do ambiente do sistema.
77
4.7.5.2 O processo de Brokering O processo de Brokering determina como um agente vir a ter seu objetivo alcanado por um outro agente. Assim como no Matchmaker, o processo de Brokering envolve trs diferentes tipos (papeis) de agentes: Requester, Broker e Server. Na Tabela 4.4 mostra-se as suas funes.:
tem um objetivo que ele deseja que seja alcanado por outro agente conhece os nomes de muitos agentes e suas respectivas capacidades e anuncia suas prprias capacidades como uma funo de capacidades destes agentes. indistinguvel sob a tica do Server, talvez com menor tempo de resposta e maior custo. Agente Server tem se comprometido com o Broker a atender um classe predeterminada de objetivos. Tabela 4.4 Funes dos agentes no processo Brokering Agente Requester Agente Broker
As interaes entre os trs tipos de agentes mostrada na Figura 4.4. Agente Broker
Id do agente Info.Balanceamento de carga Outras caractersticas do servio
Notifica/desabilita seus servios
Execute o servio Resultado do servio
Resultado do servio Id1, id2,...
Requisio para servio: Execute o servio
Agente Server
Figura 4.4 Interao entre agentes no processo Brokering
Agente Requester
Para cada requisio recebida do agente Requester, o agente Broker tenta associar a requisio com o conjunto de classes de servios registrados. Se encontra algum, o Broker redireciona a requisio para os agentes Servers apropriados, que logo retornam seus resultados para o agente Broker, o mesmo que os redireciona de volta para o agente Requester. A seleo de um agente Server feito no s levando em conta a satisfao em atender a requisio, mas, tambm, visando o balanceamento de carga, ou seja, otimizar o uso de recursos dos agentes Servers. Isso implica que um agente Server no pode se registrar em mais de um Broker. Alm disso, o agente Broker precisa gerenciar o montante do trabalho realizado em cada requisio e os recursos disponveis em cada Server.
78
4.8 Metodologia MESSAGE MESSAGE (Methodology for Engineering Systems of Software Agents) (Eurescom, 2001b) uma metodologia de Engenharia de Software orientada a agentes. Esta combina as melhores caractersticas de trs abordagens baseadas em agentes: MAS-CommmonKADS (Iglesias et al., 1997], derivada da metodologia KADS (Schreiber, 1992), Metodologia Gaia (Wooldridge et al., 1999), Metodologia KAOS (Darimont & Lamsweerde van, 1996; Bertrand et al., 1998)
O mtodo est orientado s fases de anlise e projeto dentro do processo de desenvolvimento de software, assim, atravs das especificaes e das representaes resultantes do modelo de anlise, a fase de projeto necessita apenas trabalhar o refinamento desses resultados. O mtodo prope cinco diagramas: (1) O Diagrama da Organizao (DO) da aplicao, (2) O Diagrama do Domnio (DD), (3) O Diagrama de Meta/Tarefa (DMT), (4) O Diagrama de Agente/Papel (DAP) e, (5) O Diagrama de Interao (DI). A metodologia MESSAGE tambm define a estrutura dos agentes de software para a fase de implementao, a arquitetura do agente MESSAGE tratada na seo 4.8.6.
4.8.1 O Diagrama da Organizao Focaliza a estrutura da organizao e os relacionamentos entre os agentes que ela contm. Desta forma, o DO visa definir a estrutura e o comportamento de um grupo de agentes, no sistema e na organizao externa, trabalhando juntos para atingir objetivos comuns. O DO esta composto por dois modelos bsicos: o modelo estrutural e o modelo comportamental. a) O Modelo Estrutural: Permite a visualizao do sistema como um todo. dizer como se for uma caixa preta, focando-se nos seus relacionamentos com outras entidades do seu ambiente, como por
79
exemplo usurios, donos de processos, e recursos. Este modelo pode ser projetado via o diagrama de classes UML, mas utilizando ou criando cones adequados, os quais devem ser associados aos diferentes esteretipos. b) O modelo de familiaridade ou de conhecimento (acquaintance): Mostra, em um primeiro nvel, os relacionamentos de familiaridade entre o sistema multiagente e as principais entidades externas a esta, como, por exemplo, outras organizaes de agentes, papeis de usurios ou recursos (bancos de dados, catlogos). Em um segundo nvel pode mostrar um maior detalhe de granularidade explodindo o sistema multiagente. 4.8.2 O Diagrama do Domnio de Informao Mostra os conceitos e relacionamentos especficos ao domnio que so relevantes para o sistema sob desenvolvimento. Como resultado, se obtm entidades, gerentes de entidades e tarefas. Este diagrama pode ser construdo em paralelo com todos os outros diagramas MESSAGE. Na prtica, novas classes e relacionamentos so progressivamente adicionadas quando o desenvolvedor define que elas so teis ou necessrias para a construo dos outros modelos. 4.8.3 O Diagrama de Meta/Tarefa Descreve como as metas de alto nvel, so decompostos em metas de mais baixo nvel, da mesma forma que tarefas so decompostas em conjuntos de subtarefas. Uma meta descreve uma motivao, ao passo que uma tarefa descreve uma atividade. Uma meta uma situao, isto , um conjunto de estados do mundo que um agente tem o compromisso de atingir ou manter.
4.8.4 O Diagrama de Agente/Papel Descreve os agentes individuais e/ou papeis. Para cada agente/papel utilizase esquemas e diagramas. Os agentes podem ser identificados atravs dos pontos de interseo entre as metas e as tarefas/aes, existindo trs formas atravs das quais a identificao de um agente pode ser abordada:
80
a) Decomposio de metas: As metas do sistema so decompostas em submetas, e agentes so construdos ao redor destes grupos; b) Decomposio de tarefas/servios: Os servios que um MAS precisa prover so analisados e agentes so construdos ao redor destes grupos; c) Decomposio orientada responsabilidade: Os agentes so
identificados para manipular relacionamentos com agentes externos e recursos.
4.8.5 O Diagrama de Interao Captura a forma na qual os agentes ou papis trocam informaes, entre eles, assim como com o seu ambiente. O diagrama consiste de um conjunto de interaes e de uma representao detalhada em termos de protocolos de interao.
4.8.6 A Arquitetura do Agente MESSAGE A metodologia MESSAGE define uma estrutura para os agentes de software a serem utilizados no desenvolvimento de aplicaes. A arquitetura do agente Message apresentada na Figura 4.5 e a mesma ser utilizada para ilustrar os agentes do SCM. Na figura observa-se que o agente estruturado em quatro camadas: (Eurescom, 2001a, Eurescom, 2001b) a) Camada de Percepo e Comunicao (Perception & Communication Layer - PCL): Contm os processadores de percepo e comunicao para obter informao do ambiente e interagir com outros agentes. b) Camada de Deciso e Gerenciamento (Decision & Management Layer DML): Controla aes do agente atravs de decises deliberativas. Tambm trata o gerenciamento do agente (criao, destruio e monitoramento do agente). c) Camada do Domnio (Domain Layer - DL): Agrupa entidades especificas do domnio. Pode conter tambm os componentes que representam os efeitores do agente (p.ex. execuo de tarefas), desde que elas sejam dependentes do domnio.
81
d) Camada de Recursos (Resource Layer - RL): Inclui os recursos internos que o agente pode necessitar. Estes devem ser distinguidos dos recursos da organizao, desde que estes ltimos pertencem ao sistema. Exemplos de recursos internos so os recursos GUI (interfaces grficas de usurio).
Esta arquitetura permite definir um amplo espectro de agentes. Para cada uma das camadas so identificados componentes, os quais dependem dos requisitos da aplicao. Em tal sentido, pertinente salientar que possvel, por exemplo, restringir um agente s camadas de Percepo e Comunicao e de Recursos. Este o caso de um agente puramente reativo. Por outro lado, agentes cognitivos poderiam instanciar a arquitetura completa.
Executa funes de gerenciamento
Fornece informaes do gerenciamento
Decision & Management Layer (DML)

Recebe informaes de alto nvel do ambiente Guia as comunicaes / modifica a perceo
Usa recursos
Ordena executar aes sobre o ambiente
Perception & Communication
Layer (PCL)
Recebe informaes de baixo nvel do ambiente Executa atos comunicativos
Domain Layer (DL)

Executa aes sobre o ambiente atravs dos recursos
Resource Layer (RL)

Executa aes sobre os recursos / envia mensagens a outras entidades Recebe mensagens de outras entidades/recebe informaes dos recursos
Figura 4.5 Arquitetura em camadas do agente MESSAGE (Eurescom, 2001a, Eurescom 2001b )
O principal propsito para a utilizao de um MAS no SCM poder delegar aos agentes uma srie de tarefas trabalhosas e exaustivas, tais como monitorar o ambiente, manter a base de conhecimento, o Baseline Organizacional, e tomar decises sobre o melhor caminho quando necessrio. Em ambientes altamente dinmicos e com grande quantidade de componentes, estas tarefas so extremamente trabalhosas e seriam, praticamente, de grande dificuldade de serem realizadas por agentes humanos.
82
4.9 A Tcnica do CBR (Wangenheim von & Rodriguez, 2000) O CBR (raciocnio baseado em casos) uma tcnica de raciocnio que, a partir de experincias prvias, armazenadas como casos, simula processos de pensamento e raciocnio. O CBR armazena uma variedade de solues para problemas passados de acordo com certos critrios ou ndices que so as caractersticas relevantes para encontrar casos similares. Quando confrontados com um problema similar, o CBR busca na base de casos e seleciona as solues dos problemas passados que mais se assemelham a este problema. pertinente mencionar que se definidas as mtricas apropriadas de distncia, casos corretos podero ser selecionados, os quais podem fornecer conhecimento til do domnio, seja na forma de uma soluo completa ou mesmo de solues parciais que ajudem a resolver o problema atual. Por outro lado, muitos pesquisadores asseguram que os casos suportam melhor que as regras, a propagao e comunicao do conhecimento (Riesbeck & Schank, 1989). Assim mesmo, a complexidade dos problemas do mundo real torna algumas vezes difcil, seno impossvel, generalizar regras a partir de casos. Como dito no pargrafo anterior, necessrio o estabelecimento de atributos e mtricas que devem ser definidas de acordo com o domnio sob anlise. Ao mesmo tempo necessrio definir o algoritmo que permita encontrar o caso mais aproximado e que melhor satisfaa aos requerimentos do problema vigente. No trabalho sobre gerenciamento das experincias na rea da Engenharia de Software (Wangenheim von & Rodriguez, 2000), encontra-se um algoritmo para recuperao de casos baseado em medidas de similaridade, definindo-se a medida sim, a qual parametrizada para um objetivo especfico, tendo as seguintes assunes: Dependendo da meta de recuperao g, um particular conjunto de indices Ig={Ig1, Ig2, ...., Ign} definido para a recuperao do caso ou casos mais similares. A faixa de valores do atributo Igi definido pela respectiva faixa definida em Wi. A situao do problema presente (Sit) avaliado baseado no conjunto de ndices Igi da meta de recuperao, onde: Sit={(Igi,si)
Sit / o fator de relevncia (Si)
essencial}
83
tal que os atributos Igi
Ig e os seus valores si
Wi. Um caso de experincia,
casok representa uma experincia Ck={(Ck1, ck1), (Ck2, ck2), ..., (Ckn, ckn)} com os atributos Cki e seus valores cki
Wi e, com Ck Ck e Cki
Ig e, os seus
respectivos valores cki
Wi. As medidas de similaridade local v(si, cki)
[0,1]
para todos os Wi definidos. Introduzem-se condies de similaridade local i
[0,1] para cada ndice Igi, com o intuito de determinar se os valores so considerados o suficientemente similares. Para cada ndice Igi
ao conjunto de
ndices Ig, um fator de relevncia gi
[0,1] definido. Para cada meta de
recuperao os fatores de relevncia so representados pelo vector de relevncia Rg={ g1, g2, ..., gn} com gi=1 normalizado. A fim de explicitamente lidar com conhecimento incompleto, a similaridade de dois objetos expressa atravs de um contraste linear de diferencias ponderadas entre as suas caractersticas comuns e diferentes (Tversky, 1977). Na Tabela 4.5 mostr-se os diversos conjuntos de ndices definidos. E: Conjunto dos ndices de uma E={Igi / (Igi Sit Cki) e v(si, cki) i} situao dada e os casos armazenados W: Conjunto de ndices que W={Igi / Igi Sit Cki) e v(si, cki) < i} contradizem a situao dada e os casos armazenados

U: Conjunto de ndices desconhecidos na descrio da situao atual
U={Igi / (Igi

Cki Sit)}
R: Conjunto de ndices redundantes R={Igi / (Igi Sit Cki)} no contidos nos casos armazenados
Tabela 4.5 Conjunto de ndices definidos para a medida sim
Para cada conjunto de caractersticas, so definidos os pesos especficos , , , [0,1] na formula da medida de similaridade global:
si E ik v(si, cki) Sim(Sit, Ck) = --------------------------------------------------------------------------------si E ikv(si,cki) + si W ik(1- v(si,cki)) + si U ik + si R ik
Baseado no valor calculado de similaridade, um casok considerado como candidato a reuso, se todas as caractersticas marcadas como essenciais na situao dada se assemelham as respectivas caractersticas do caso, e se sim(Sit, Ck) a condio de similaridade global k.
5 Resultados da Estratgia Proposta
Como dito no Captulo 4, o primeiro passo foi estudar as diversas teorias, vises e abordagens da anlise estratgica, a anlise de funes e processos, o gerenciamento da qualidade total e, em forma ortogonal, as metforas de Morgan, com o propsito de extrair os construtos mais relevantes para a criao do esquema conceitual da memria corporativa, o modelo de negcio. A tecnologia utilizada para essa tarefa foi a de ontologias, a qual permitiu gerar uma ontologia empresarial orientada estratgia de negcios em ambientes de mudana contnua. Das diferentes metodologias de ontologias descritas na seo 4.5.5, selecionou-se a de Uschold & King (1995), pela simplicidade e clareza de cada um de seus itens. No entanto, vale a pena mencionar que considerou-se tambm o uso de Methontology, mas esta no foi escolhida porque implicava um processo mais extenso e, para efeitos do presente trabalho, a proposta de Uschold e King atingia os objetivos desejados na elicitao de uma ontologia empresarial.
5.1 A Ontologia Empresarial orientada Estratgia de Negcios O propsito da utilizao da tecnologia de ontologias detectar quais so os construtos mais relevantes na rea de estratgia de negcios que servem de base para a criao do modelo de negcio, o qual do ponto de vista computacional se reflete no Organizational Baseline. A abordagem da metodologia de Uschold e King descrita a seguir: a) Identificar o propsito: Estabelecendo os fatos que motivam a sua criao, como esta ser utilizada e os possveis mecanismos para seu uso;
85
b) Determinar o nvel de formalizao da ontologia: Em geral, o grau de formalidade requerida aumenta com o grau de automao das tarefas que a ontologia ir suportar; c) Delimitar o escopo da ontologia: Determina-se atravs do uso de cenrios de motivao, os quais ajudaro ao estabelecimento de um conjunto de questes de competncia que a ontologia dever satisfazer. Muitas vezes utiliza-se tambm a tcnica de brainstorming; d) Criar a ontologia: Envolve a captura da ontologia em si, identificando os conceitos chave e os seus relacionamentos no domnio de interesse (escopo). Tambm inclui a produo de definies precisas e no ambguas, a determinao dos termos que melhor as identifiquem e a codificao em alguma linguagem formal; e) Avaliar a ontologia: Refere-se a fazer um julgamento tcnico da ontologia, do ambiente de software associado e da documentao com respeito ao frame de referncia (domnio); f) Documentar a ontologia: Envolve a descrio das assunes ou supostos assumidos com respeito aos principais conceitos, as especificaes de requisitos, as questes de competncia, bem como as primitivas utilizadas para expressar as definies na ontologia (meta-ontologia). Nas prxima sees desenvolve-se cada um dos itens acima citados.
5.1.1 Identificando o Propsito Uma ontologia tem como propsito bsico servir como um meio de comunicao entre as pessoas, dentro de algum contexto ou domnio, facilitando o seu reuso. Um outro propsito de uma ontologia suportar a interoperabilidade entre sistemas. No presente trabalho, a ontologia a ser criada ser utilizada como um meio para estruturar a base de conhecimento (modelo de negcio) da memria corporativa orientada estratgia de negcios (Strategic Corporate Memory SCM), a qual uma aplicao baseada em conhecimento. Nota-se que sendo a estrutura do repositrio do SCM baseado em uma ontologia, esta facilita a aquisio de conhecimento, bem como a identificao de requisitos e
86
especificaes da arquitetura do sistema a desenvolver, tudo isso com o intuito de obter um software mais confivel. Na seo 4.5.3 estudou-se que uma ontologia pode ser de domnio, tarefa, aplicao e representao (meta-ontologia). A ontologia empresarial proposta de domnio, sendo per-se genrica ao domnio em estudo. Isto porque est baseada em teorias da estratgia de negcios aceitas tanto pela comunidade acadmica como de negcios e, portanto, aplicvel em um alto nvel a qualquer tipo de organizao, mas, obviamente, com os ajustes pertinentes, pois os construtos a nvel de ativos e capacidades vo depender necessariamente da atividade principal da organizao (core do negcio). Esta ontologia no s pode ser utilizada para estruturar a base de conhecimento do SCM, como tambm poderia ser utilizada por outro tipo de aplicaes mais especificas, como por exemplo na rea de recursos humanos ou de marketing.
5.1.2 O Nvel de Formalidade Considerando-se que a ontologia empresarial ser utilizada para estruturar uma base de conhecimento, bem como para suportar o seu reuso e compartilhamento, utilizou-se, inicialmente, uma linguagem de representao semi-informal em linguagem natural estruturada e restrita. A ontologia foi documentada na ferramenta Protg (2003), a qual permitiu express-la em uma linguagem de representao semi-formal, o RDF-XML. Anota-se que uma ontologia fornece um modelo semntico dos conceitos existentes em um repositrio, independente da estrutura existente em um determinado momento. Portanto, o conceito de ontologia anlogo ao modelo conceitual utilizado em bancos de dados convencionais, podendo se dizer que o modelo de banco de dados em um domnio de aplicao especifico pode refletir a representao de uma ontologia de aplicao. Isto se sustenta na afirmao de Gruber (Guarino, 1998) de que esquemas em bancos de dados relacionais tambm servem como ontologias pela especificao das relaes que podem existir em algum banco de dados compartilhado e as restries que devem ser manipuladas pelo banco. Assim, possvel descrever uma ontologia sob o modelo ER, embora se saiba as suas limitaes, tal como a impossibilidade de
87
representar regras e axiomas. Porm, considerando-se que no presente trabalho no so tratados aspectos de inferncia baseada em regras, essa limitao no foi restritiva.
5.1.3 O Escopo da Ontologia O escopo da ontologia empresarial esta delimitada estratgia de negcios em um ambiente competitivo de mudana contnua. Dado esse escopo, estudou-se as teorias de estratgia de negcio mais relevantes, sob o marco de um planejamento estratgico, o qual inclui tanto os aspectos do ambiente externo indireto, ambiente externo direto e ambiente interno. a partir dessas abordagens mais especficas que criada a ontologia empresarial no presente estudo. O Planejamento Estratgico de Negcios, que integra as diferentes escolas da analise estratgica, positioning e emphasizing efficiency, uma abordagem bastante utilizada na rea de estratgia organizacional, seja no meio acadmico, indstria e/ou de consultoria. Esta tem suas origens no planejamento do longo prazo, sendo seu objetivo central o estabelecimento de uma estratgia que envolva a definio de misso, viso, objetivos estratgicos, polticas e planos de contingncia. Dada essa abrangncia decidiu-se que a estrutura do repositrio do SCM poderia estar baseada nesta abordagem integradora, considerando que esta tinha sido estudada em profundidade e comprovada a sua validade no ambiente de negcios.
5.1.4 Criando a ontologia Delimitado o escopo da ontologia, o passo seguinte selecionar quais teorias, vises ou abordagens a satisfazem. Assim, determinou-se que para a anlise do ambiente externo indireto se utilizaria a anlise ambiental (Aybar et al., 1989; Austin, 1990) da escola positioning, a qual classifica o ambiente em quatro grandes reas: aspectos socioculturais, econmicos, polticos e
tecnolgicos. Para a anlise do ambiente externo direto utilizou-se o modelo de Porter (1980) ou das cinco foras competitivas, tambm da escola positioning. Finalmente, para a anlise do ambiente interno aplicou-se a escola que enfatiza a eficincia (emphasizing efficiency), a viso resource_based view e o
88
framework dynamic capabilities (Day et al., 1997, Teece et al., 1997). Estas escolhas foram realizadas baseadas em que as mesmas so aceitas e amplamente estudadas no meio acadmico, bem como utilizadas por importantes empresas de consultoria, PricewaterhouseCoopers, Ernst & Young, Deloitte Touche Tohmatsu, KPMG (Klynveld, Peat, Marwick, Goerdeler). relevante citar que como decorrncia do processo de planejamento estratgico estabelece-se uma estratgia global, a qual est baseada nas oportunidades e riscos (resultado da anlise do ambiente externo indireto e direto e da anlise do setor) e, nas fortalezas e pontos de melhoria da organizao (resultado da anlise do ambiente interno). A ontologia de negcio foi tambm enriquecida com a teoria de TQM (Total Quality Management), a anlise de funes e processos e as metforas de Morgan. Um aspecto importante quando se pretende criar uma ontologia considerar o reuso das ontologias existentes, pois muitas vezes melhor partir de algo que outros possam haver desenvolvido, em vez de tratar de recri-lo de novo. Nos dias de hoje muitas ontologias, nas mais diversas reas, podem ser encontradas na internet. No entanto, estas ontologias, antes de serem usadas, devem ser analisadas e refinadas, estendendo-as para um domnio ou tarefa particular. Uma proposta importante para o presente trabalho a ontologia Enterprise Ontology de Uschold et al. (1998) dado que a mesma esta orientada modelagem de negcios. Entretanto, apesar da relevncia da Enterprise Ontology, decidiu-se analisar em detalhe as teorias e abordagens provenientes da cincia administrativa, pois acredita-se que sendo esta uma rea relativamente madura, seria adequado criar a ontologia empresarial orientada estratgia de negcios a partir dessas teorias, mas que no futuro esta poderia ser enriquecida com a meta-ontologia e as ontologias parciais de estratgia, atividade e organizao da proposta de Uschold et al. Considera-se essa extenso como um tpico para futuros trabalhos do SCM. Na atualidade existem diversos possveis critrios para o desenvolvimento de uma ontologia na forma de uma hierarquia de conceitos e relacionamentos ontolgicos, sendo estes Top-Down, Bottom-Up e Middle. Um processo de desenvolvimento Top-Down comea com a definio dos conceitos mais gerais no domnio, com a subseqente especializao desses conceitos. O processo Bottom-Up comea, pelo contrario, com a definio dos conceitos mais especficos, as folhas da hierarquia, para logo agrup-las em conceitos mais gerais. O terceiro critrio, o Middle, uma combinao dos dois anteriores, este
89
primeiro define os conceitos mais relevantes e logo os mesmos so apropriadamente especializados e/ou generalizados. Salienta-se que nenhum desses mtodos melhor ou pior que o outro: o critrio selecionado depender fortemente da viso do domnio que tenha o pessoal responsvel da criao da ontologia. No presente trabalho, adotou-se de modo geral o critrio Top-Down, dado que a abordagem de planejamento estratgico empresarial utilizada fornece uma viso sistemtica que vai do aspecto geral s questes mais especificas, facilitando a aplicao do critrio antes citado. No Captulo 4, quando estudou-se o tpico da estratgia de negcios escreveu-se que o primeiro passo do planejamento estratgico era a anlise do ambiente externo indireto. O segundo passo era a anlise do ambiente externo direto, esta inclui o setor onde a organizao desenvolve as suas atividades, e o terceiro passo era a anlise do ambiente interno. Isto reafirmado na seo 5.1.3 quando se define o escopo da ontologia. Baseado nessa linha de raciocnio, as Figuras 5.1, 5.2, 5.3 e 5.4 mostram a aplicao das vises do negcio utilizadas no planejamento estratgico para a criao da ontologia em termos dos conceitos e os seus relacionamentos.
Companhia Nome, Descrio , Matriz (Organizao)
PART-OF
Ambiente Organizacional
PART-OF
PART-OF
Estratgia Global
PART-OF PART-OF
Negcio
PART-OF Processos
Foras Competitivas
Funes
PART-OF
Fatores Socioculturais
PART-OF
PART-OF PART-OF
Fatores Polticos Fatores Tecnolgicos
Fatores Econmicos
Figura 5.1 Ontologia da Organizao e do Ambiente Organizacional
Como decorrncia desse processo de raciocnio definiu-se uma primeira hierarquia de conceitos (modelo global da organizao), utilizando-se o critrio Top-Down sob um relacionamento mereolgico, vide Fig. 5.1, onde o conceito Ambiente Organizacional refere-se ao ambiente externo indireto; as Foras
1
Nesta verso do SCM no se modelou os axiomas da ontologia.
90
Competitivas, incluindo a analise do setor, ao ambiente externo direto; a anlise do Negcio, Funes e Processos ao ambiente interno e a Estratgia Global que define a misso, viso, polticas, objetivos, estratgias, o resultado do processo de planejamento estratgico como um todo. O detalhe desta primeira classificao de conceitos mostrada na mesma Figura 5.1 para o conceito Ambiente Organizacional. O detalhe dos conceitos Foras Competitivas e anlise do Negcio mostrado na Figura 5.2. Os conceitos Estratgia Global e Processos so mostrados na Figura 5.3. A ontologia do conceito Funes detalhada na Figura 5.4.
Companhia Nome da Empresa Descrio Matriz Estrutura Organizacional . Funcional . Divisionalizada . Matricial . Por Processos . Simples . Ad-Hoc Estilo de Liderana . Impeditiva . Negociadora . Competitiva . Acomodatcia . Colaboradora Forma de Governo . Autocracia . Burocracia . Tecnocracia . Co-gesto . Participativo Setor de Atuao Mercado de Atuao Diagnostico Geral V V V V V V V V V V V V V V V V V V V V V V V V V V V V Mecan. Organ. Cerebro V V V V V Cultura Poltico Priso Fluxo Domin.
LEGENDA: V: Satisfaz a metfora Tabela 5.1 O conceito Companhia e as metforas de Morgan
O detalhe do conceito Ambiente Organizacional est baseado no modelo Ambiental (escola positioning), e classificado por sua vez em quatro conceitos, os Fatores Socioculturais, Econmicos, Polticos e Tecnolgicos. A Tabela 5.1 mostra o conceito Companhia (organizao) e alguns dos seus atributos mais relevantes. Nota-se como as metforas de Morgan ajudaram na elicitao de atributos mais especficos e em alguns casos, como nos itens estrutura organizacional, estilo gerncial e forma de governo, conseguiu-se obter sub-
91
atributos. Tambm observa-se a importncia de todas as metforas, a exceo da metfora do organismo e do fluxo e transformao. Para efeitos de exemplificar a ontologia do negcio, adaptou-se o estudo de caso da empresa Multicom apresentado em Morgan (1996). Na Tabela 5.2 mostra-se uma instncia do conceito Companhia com dados da Multicom.
Tabela 5.2 Uma Instncia do Conceito Companhia
A Figura 5.2 mostra o detalhe das Foras Competitivas e da anlise de Negcio, a primeira usa o relacionamento taxonmico, a segunda o relacionamento mereolgico. As foras competitivas, baseada no modelo de Porter so: Compradores, Fornecedores, Concorrentes, Empresas de Produtos Substitutos e Novos Concorrentes. Para a anlise do Negcio, baseado no planejamento estratgico empresarial, determinou-se como construtos relevantes os conceitos Pontos Fortes, Pontos de Melhoria, Mercado de Atuao, Oportunidades, Riscos e Medidas, utilizando-se o relacionamento mereolgico. Logo, para o conceito Medidas aplicou-se o relacionamento taxonmico obtendose os conceitos Resultados e Benchmarking, estes ltimos foram inspirados no
92
TQM, o que prope o uso de indicadores de medio para avaliar o desempenho da organizao. Os indicadores do tipo resultado so conseqncia da atividade prpria do negcio, os indicadores do tipo benchmarking podem ser internos, quando so resultados passados ou externos, quando obtidos de instituies representativas ou de consultorias. Os indicadores externos por sua vez so de ndole local, estadual, regional ou internacional.
Foras Competitivas
IS-A
Compradore s
IS-A
Fornecedores
IS-A
Concorrentes
IS-A
Novos Concorrentes
IS-A
Empresas de Produtos Substitutos
Negcio
PART-OF
Pontos Fortes
PART-OF
PART-OF PART-OF
Oportunidades
PART-OF
Riscos
PART-OF
Medidas
Pontos de Melhoria
Mercado de Atuao
IS-A
Resultados
IS-A
Benchmarking
Figura 5.2 Ontologia das Foras Competitivas e da Anlise do Negcio
A Tabela 5.3 mostra o conceito Concorrentes e a influncia das metforas de Morgan para a determinao de seus atributos. A Tabela 5.4 mostra uma instncia deste conceito, utilizando-se o caso da Multicom.
Concorrentes Nome Descrio Endereo Telefone Tipo (Varejo, Atacado, Distribuidor, Produtor) Pontos Fortes Pontos Fracos Participao do Mercado
Mecan.
Organ. Cerebro V V V V V V V V
Cultura Poltico Priso Fluxo V V V V V V V V V V V V V V
Domin.
LEGENDA: V: Satisfaz a metfora Tabela 5.3 O Conceito Concorrncia e as metforas de Morgan
A Figura 5.3 especifica os conceitos Estratgia Global e Processos, o primeiro baseado no processo do planejamento estratgico, utiliza os relacionamentos mereolgico junto com o relacionamento temporal (conceito Fatores Crticos), o segundo baseado na anlise de processos, usa um
93
relacionamento mereolgico, em um primeiro nvel, e um relacionamento taxonmico e temporal (conceito Resultados) em um segundo nvel. A Tabela 5.5 mostra a definio, em detalhe, do conceito Objetivos, da qual uma instancia o objetivo estratgico.
Entidade: Concorrentes
Nome Descrio Media 2000 Companhia dedicada aos servios de Marketing e Publicidade. As suas atividades incluem: Desenho Grfico para a identificao das empresas atravs de logotipo ou marcas; Criao e produo de catlogos, manuais, brochuras, cartazes, mala direta. Rua Santa Catarina, 244 8o andar- conj. 805 CEP 09510-120 Rio de Janeiro RJ (21) 2224-5657
Endereo Telefone Tipo Varejo Atacado Distribuidor Produtor
X Scios principais com ampla experincia, portaflio de clientes pequenos, mas lucrativos. Ambiente de trabalho amplamente estimulante. Companhia inovadora e talentosa. Companhia nova no mercado, pouca experincia gerencial dos principais scios, estrutura financeira no muito slida. Pequena (2%)
Pontos Fortes Pontos de Melhoria Participao de Mercado
Tabela 5.4 Uma instancia do Conceito Concorrentes
Estratgia Global PART-OF PART-OF Objetivos PART-OF
Viso, Misso
PART-OF Estratgias PART-OF Fatores Crticos
Polticas
Anlise do Setor
After Medidas
{Nome, Descrio, Dono de Processo Escopo, Tipo, Nvel, Suporte Critico, Processos Representao, Polticas, Padres, Procedimentos}
PART-OF Aes (Atividades) AFTER
PART-OF Medidas IS-A I IS-A IS-A
PART-OF Cliente do Processo IS-A Unidade
PART-OF Fornecedor do Processo IS-A Pessoa
PART-OF Inputs IS-A
PART-OF Outputs
PART-OF Atores (Pessoas)
Resultados Indicadores
Benchmarking
Pessoa
Unidade
Figura 5.3 Ontologia da Estratgia Global e dos Processos
94
GA67D(4$ 5H6 It$ W 7v"%( )9"@w6'#$ D I u g9"%$ D A W63( )6D9$ &6)30 P F630 y !2X$ &$ 7v"%( )35H6 GA3W6)3( "@)#C3&9"@ 65H6 ( ) 9)9"@#( 67 (4 "%$ D37

!#"%$ &'#$ ()10 $ 233(4)3&5)1&61789"@#(A1&6BC#( D8)623E)30 F6 IP(4&6)3( QR7TSU)VDXW)3&3Y3$ )`23T( 30 )65a67bWc3d0 $ D)67eDf0 $ 23( )3&358)T&6)67hg#( 6)37h23 ip)3(Rq9"%$ &'1Er3S3d0 $ D9$ 2)623s x x 6S3&6D9$ &6g(4$ 7#S)30 $ @$ D)62376#S$ W6)#C3&9"@72V)30 "@)V#S)30 $ 2)6236d6&67eD#&"@)9"@#7e&6 3(D)623 !7 W6773)67U( 67W6&679g9F33$ 729F33"%3()19W3(4$ #&D$ )E( 6#S3(4$ 23)s 3( F3$ 5371W( 32#S"@3723US6)30 $ 23)62s
S3W#( "@1(4$ "%$ D %U W6)6D"@7
Tabela 5.5 Conceito Objetivos
A Figura 5.4 detalha o conceito Funes, que faz parte do conceito Companhia, utilizando os relacionamentos taxonmico e mereolgico. De acordo com a analise de funes, uma organizao pode ser organizada em quatro funes bsicas: Administrao e Recursos Humanos, Marketing, Finanas e Produo e, Logstica. No entanto, devido importncia que nas ultimas dcadas os sistemas de informao tm tido, esta rea tornou-se, na prtica, uma nova funo, responsvel pela gerncia dos recursos informticos da organizao, da acreditou-se que era conveniente mostr-la como uma rea independente. Assim mesmo, determinou-se que, para efeitos de uma melhor apresentao, era adequado separar os conceitos de Administrao e Recursos Humanos, inicialmente juntos. Cada uma das funes tem por sua vez um conjunto de ativos e capacidades distintivas, o que resultado do uso da escola emphasizing efficiency. No detalhou-se os ativos e capacidades distintivas da organizao porque estes construtos, como afirmado na seo 5.1.1, vo depender necessariamente do core do negcio.
Funes
Polticas, Padres e Procedimentos
IS-A Produo
PART-OF Ativos Capacidades
IS-A Recursos Humanos

PART-OF
IS-A Marketing
PART-OF
IS-A Finanas
PART-OF
Capacidades
IS-A
Administrao n PART-OF
IS-A Sistemas Informao

PART-OF
CapaciAtivos dades Ativos
CapaciAtivos dades
CapaciCapaciAtivos dades Ativos dades
Figura 5.4 Ontologia das Funes
95
Antes de finalizar a elicitao dos construtos em um alto nvel, vamos analisar alguns dos j elicitados. Por exemplo, o construto Pessoa pode ter vrios papeis, assim define-se o construto Papel. Por outro lado, cada rea ou sub-rea funcional vai ter no seu interior Grupos Formais, quando representados no organograma e Grupos Informais, quando no o estiverem. As Funes vo ter tambm um conjunto de posies ou Cargos, os que vo estar alocados a determinadas Pessoas. Por ltimo toda organizao tem um conjunto de Padres, e Procedimentos constituindo estes em novos construtos da ontologia.
5.1.5 Avaliao Na presente pesquisa definiu-se o frame de referncia do domnio como a rea de estratgia de negcios em ambientes de mudana continua, para a qual criada uma arquitetura de memria corporativa. Tendo delimitado nosso escopo, utilizou-se a abordagem do planejamento estratgico empresarial que integra teorias da anlise estratgica (positioning e emphasizing efficiency), junto com a anlise de funes, processos, TQM e as metforas de Morgan, para a elicitao da ontologia empresarial. Estas teorias, vises e abordagens tm sido aceitas e validadas tanto no mbito da consultoria de negcios como no meio acadmico. Portanto, acredita-se ter feito uma abordagem com slida base terica a qual garante a validade da anlise para criao da ontologia empresarial e em conseqncia a ontologia em si mesma.
5.1.6 Documentao A ontologia empresarial anteriormente mostrada, foi documentada na ferramenta Protg. O Protg um software que permite definir os conceitos, atributos, os seus relacionamentos e as suas instncias. Na presente tese no se utilizou a ltima opo, porque nossa abordagem foi criar um repositrio de conhecimento independente, o Organizational Baseline. Na Figura 5.5. mostra-se os conceitos da ontologia empresarial documentados no Protege e, na Figura 5.6 o arquivo RDF Schema gerado por este. As assunes ou supostos assumidos na
96
criao da ontologia tm sido detalhadas, como observado, no percurso da seo 5.1.
Figura 5.5 Os conceitos da Ontologia do Negcio no Protege
5.2 O Modelo de Negcio O Organizational Baseline Baseada na ontologia apresentada na seo 5.1, criou-se (Mamani-Macedo & Leite, 2001) um modelo de Entidade-Relacionamento (ER) para o Organizational Baseline, vide Figura 5.7, o qual detalha os conceitos bem como os seus relacionamentos de domnio. Este foi feito em um contexto geral, porque, como mencionado antes, utilizou-se como base terica um conjunto de abordagens amplamente aceitos e utilizados na cincia administrativa. A seguir extrai-se do modelo ER do Organizational Baseline, as entidades e relacionamentos listadas abaixo. 1. Toda organizao (Companhia) possui um conjunto de Objetivos Estratgicos, unidades de negcio (Negcio), Funes e Processos. Os processos tm escopo, representao, Inputs, Outputs, Clientes do
3 2
As entidades so marcadas em negrita. Os relacionamentos so marcados em cursiva.
97
Processo, Fornecedores do Processo e vrios nveis hierrquicos. Cada processo coordenado por uma Equipe de trabalho composto de atores (Pessoas). Os Resultados so gerenciado(s) por Pessoas. 2. Os Objetivos Estratgicos so afetado(s) pelos Fatores Crticos, os quais so controlado(s) pelos Indicadores de Benchmarking. 3. Comparando os Resultados com os ndices de Benchmarking pode-se executar uma avaliao contnua da organizao nos nveis de unidades de negcio (Negcio), Funes e Processos. Quando necessrio determinadas Aes de Melhoria so tomadas afetando as unidades de negcio (Negcio), Funes, Processos, Clientes do Processo, e Fornecedores do Processo. 4. A Companhia ao relacionar-se com o ambiente afetado pelas Foras Competitivas como so: os compradores, fornecedores, concorrncia, nova concorrncia, companhias ou empresas de produtos substitutos; pelo Ambiente Organizacional formado pelos aspectos: socioculturais, econmicos, polticos e tecnolgicos; e pela Anlise do Setor. 5. Os Padres, Procedimentos e Polticas podem ser aplicados a (so possudos pela(s)(os)) Funes e Processos. Os Objetivos
Operacionais referem-se s (so possudos pelas) Funes e Processos.
Embora o modelo apresentado esteja orientado principalmente a dados, este toma em conta aspectos de qualidade e da melhora de processos, como visto acima no ponto 3. Atualmente o modelo est em um nvel genrico, no entanto apesar que o trabalho tenha enfatizado a integrao de conceitos via uma abordagem ontolgica, acredita-se que um maior detalhe necessrio, por exemplo, na descrio dos indicadores de benchmarking, os quais devero ser baseados em um programa de medio da qualidade. A integrao de um programa de medio com o aprendizado continuo poderia, por exemplo, ser executado usando a abordagem proposta por Cantone et al. (2000). Outra importante caracterstica do modelo a descrio das relaes sociais, isto conseqncia da nossa preocupao com os atores organizacionais (Pessoas e Funes) e as suas responsabilidades (Papis e Procedimentos), ressaltando-se assim, a importncia dos aspectos sociais no processo de tomada de decises. Por outro lado, apesar da presente proposta do Organizational Baseline incluir
98
construtos relevantes aos nveis estratgico, ttico e operacional, enfatizou-se a dimenso estratgica na criao do SCM.
<?xml version='1.0' encoding='ISO-8859-1'?> <!DOCTYPE rdf:RDF [ <!ENTITY rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'> <!ENTITY a 'http://protege.stanford.edu/system#'> <!ENTITY SCM 'http://protege.stanford.edu/SCM#'> <!ENTITY rdfs 'http://www.w3.org/TR/1999/PR-rdf-schema-19990303#'> ]> <rdf:RDF xmlns:rdf="&rdf;" xmlns:a="&a;" xmlns:SCM="&SCM;" xmlns:rdfs="&rdfs;"> <rdfs:Class rdf:about="&SCM;Administrao" rdfs:label="Administrao"> <rdfs:subClassOf rdf:resource="&SCM;Funes"/> </rdfs:Class> <rdfs:Class rdf:about="&SCM;Ambiente Organizacional" rdfs:label="Ambiente Organizacional"> <rdfs:subClassOf rdf:resource="&rdfs;Resource"/> </rdfs:Class> <rdfs:Class rdf:about="&SCM;Analise do Negocio" rdfs:label="Analise do Negocio"> <rdfs:subClassOf rdf:resource="&rdfs;Resource"/> </rdfs:Class> <rdf:Property rdf:about="&SCM;Atividades" rdfs:label="Atividades"> <rdfs:range rdf:resource="&rdfs;Literal"/> </rdf:Property> <rdfs:Class rdf:about="&SCM;Ativos" rdfs:label="Ativos"> <rdfs:subClassOf rdf:resource="&SCM;Produo"/> </rdfs:Class> <rdfs:Class rdf:about="&SCM;Atores" rdfs:label="Atores"> <rdfs:subClassOf rdf:resource="&SCM;Processos"/> </rdfs:Class> <rdfs:Class rdf:about="&SCM;Aes" rdfs:label="Aes"> <rdfs:subClassOf rdf:resource="&SCM;Processos"/> </rdfs:Class> <rdfs:Class rdf:about="&SCM;Capacidades" rdfs:label="Capacidades"> <rdfs:subClassOf rdf:resource="&SCM;Produo"/> </rdfs:Class> <rdfs:Class rdf:about="&SCM;Cliente Processo" rdfs:label="Cliente Processo"> <rdfs:subClassOf rdf:resource="&SCM;Processos"/> </rdfs:Class> <rdfs:Class rdf:about="&SCM;Compradores" rdfs:label="Compradores"> <rdfs:subClassOf rdf:resource="&SCM;Foras Competitivas"/> </rdfs:Class> <rdfs:Class rdf:about="&SCM;Concorrentes" rdfs:label="Concorrentes"> <rdfs:subClassOf rdf:resource="&SCM;Foras Competitivas"/>
Figura 5.6 O Arquivo RDF Schema da Ontologia (vista parcial)
99
1,n 1,n 1,1 1,1 1,n possui 1,1 possui 1,1 1,n
1,n
Negcio
0,n 0,1
Companhia
1,n 1,1
1,1 1,1
Objetivos Estratgicos
0,1
0,n
0,n afetado-por / afeta
Fatores Crticos
0,n
possui faz-parte 1,n 1,n
afetado-por / afeta
produz / melhora 0,n 0,n 0,n
R-Matriz produz/ melhora 0,n 0,n 0,1 produz / melhora
Funes
possui
1,n
Funes*
1,n alimenta R-Atravessa 1,n
controlado -por 0,n 0,n
Foras Competitivas
Resultados
0,n gera
0,n
Benchmarking Indicadores*
possui 0,n
tem 1,1
0,n comparado 0,n
afetado-por / afeta 0,n alimentado-por
tem / faz-parte 0,1 1,n possui
afetado-por/afeta
Benchmarking Indicadores
afetado-por afeita
sofre 1,n
Processos
1,1 1,n 1,1 Nvel Hierrquico 1,1 1,n 1,1 coordenado-por possui 1,n
Polticas, Padres e Procedimentos

possui 1,n
1,n tem
0,n
tem
1,n afetado-por / afeta 1,n
0,n afeta/afetado-por 0,n
afeta/ 0,n afetado-por
1,1
tem 1,n
Objetivo Operacional Outputs

1,n alimenta tem (fornece) 1,n 0,n 0,n
Aes de Melhoria
0,n 0,n 0,n gerenciado-por 1,n
Equipe
composto de 0,n
Anlise do Setor
0,1
Papis
1,1
Equipe Informal
0,n executado-por
faz-parte 1,n 1
1,n
gerencia / gerenciado-por
0,n
Inputs
1,n
1,n
Pessoas*
afeta / afeitado-por 0,n afeta/ afetado-por 1,n tem/ faz-parte 0,n
1,n composto-de
Clientes Processo
afeita / afeitado
Fornecedores Processo
1,n
Benchmark Indicadores*
Pessoas
Modelo E-R
* Definido em outra parte
Figura 5.7 O Modelo E-R do Organizacional Baseline do SCM
100
5.3 A Arquitetura Genrica do SCM (Strategic Corporate Memory) Na criao da arquitetura do SCM utilizou-se um estilo arquitetural heterogneo, combinando, principalmente, a arquitetura de camadas e a arquitetura de repositrio, vide seo 4.6.5, pois acredita-se que estas satisfazem melhor os objetivos a serem atingidos pelo SCM. Con respeito aos dados, sabe-se que a integrao de dados heterogneos e distribudos um tema de pesquisa atual e com muitos problemas em aberto na rea de banco de dados, pois no existe uma soluo global que seja adequada ou que se ajuste aos diversos problemas de integrao (Barbosa, 2001). Ao mesmo tempo conhece-se a existncia de uma grande variedade de problemas, solues e de potenciais usurios com relao integrao de dados heterogneos. Duas alternativas de como tratar a integrao de dados so: a abordagem materializada e a no materializada. No primeiro caso temos, por exemplo, um data warehouse e no segundo caso, um sistema baseado em mediadores e wrappers. Este ltimo cria um modelo global virtual que integra todas as fontes pr-estabelecidas. A criao de uma memria corporativa implica, por definio, a integrao de dados das mais diferentes fontes (legados, web, bancos de dados relacionais e de objetos) e tipos (dados textuais e multimdia). Isto levou a procurar uma soluo baseada em uma das abordagens de integrao antes citada. Assim, no presente estudo decidiu-se pela opo materializada e escolheu-se que o SCM deveria ter um repositrio de conhecimento adaptado estratgia de negcios, tendo as seguintes caractersticas: (Rundensteiner et al., 2000) Em tempo de configurao, informao relevante extrada desde diferentes fontes de informao (web, sistemas legados, bancos de dados existentes e seres humanos) por meio da utilizao de agentes de software. Esta informao transformada, depurada e juntada com informao de outras fontes, quando necessria, para logo ser carregada dentro do repositrio (Organizational Baseline); Em tempo de processamento, consultas so submetidas ao sistema (SCM), sendo por este avaliada sem precisar interagir com as fontes originais;
101
Em tempo de execuo, modificaes no contedo das fontes so filtradas para atualizar o repositrio do SCM, logo so propagadas (disseminadas) utilizando agentes de software.
A deciso anterior baseou-se no fato de que os dados do repositrio no sofreriam uma grande quantidade de mudanas, como sim acontece com aplicaes orientadas transaes, por exemplo vendas e compras. Outra razo foi que o desenvolvimento de uma arquitetura baseada em mediadores e adaptadores (wrappers) poderia prejudicar o desempenho (tempo de resposta) do SCM, dado que a recuperao de informao utilizando esta abordagem faz-se diretamente a partir dos arquivos fonte. Em vista de tais argumentos decidiu-se pelo tipo de uma integrao de informao materializada. Na Figura 5.8 apresenta-se a proposta de camadas da arquitetura fsica do SCM, nela observa-se que esta tem trs camadas, uma camada de fontes, outra de servios ou middleware e, finalmente uma de repositrios, sendo parte desta ltima o Organizational Baseline ou repositrio de conhecimento.
Decision Making Interface
Case Base
AGENTES MIDDLEWARE
Query Engine Data Loader View Maintainer Metaknowledge Manager Metaknowledge Organizational Baseline
LOG Interface
Busca & Descobrimento Descobrimento
Temporal Metadata DataBase
Descobrimento
CAMADA MIDDLEWARE
Repositorios: Ontology, HyperlinksHistory, Users
MK DB
Logistic DB HR DB
Seres Humanos
WEB
CAMADA DE REPOSITRIOS
CAMADA DE FONTES
Figura 5.8 Arquitetura de Camadas do SCM (Strategic Corporate Memory)
102
5.3.1 A camada de Fontes Considerando que a proposta arquitetural do SCM, uma arquitetura de integrao de informao materializada, esta inclui, como dito na seo 5.3, fontes to diversas tais como: sistemas legados, bancos de dados relacionais ou orientado a objetos, Web sites HTML, documentos SGML ou XML, ou mesmo dados multimdia. Outra fonte, no menos importante, para a elicitao do conhecimento que alimente o repositrio do SCM so os seres humanos. As fontes de informao do SCM so mostradas na Figura 5.8 dentro da camada de fontes (sources layer). Para cada fonte ter que se desenvolver um wrapper. Anota-se que o desenvolvimento destes absolutamente factvel porque, em primeiro lugar,
muito da informao e conhecimento relevante que alimenta o Organizational Baseline ser extrada dos bancos de dados que possui a organizao, o que implica no conhecimento detalhado da estrutura interna dessas fontes. No caso dos sistemas legados tambm no haveria dificuldade pois, como na situao anterior, a sua estrutura conhecida pela organizao. No caso de fontes da web, poderia acontecer que em alguns casos no se possa extrair o contedo, por estarem ocultos ou por se desconhecer a sua estrutura, dificultando portanto o seu acesso. Nesse caso, seria adequado procurar outros sites alternativos de onde se possa extrair essa informao. Nos ltimos tempos, com o surgimento de aplicaes web baseadas em XML, essa dificuldade inicial pode ser superada aos poucos. Isto porque essas aplicaes, usualmente, deixam disposio do pblico usurio a estrutura de seus arquivos ou mesmo o seu modelo de dados. Por ltimo, se os dados fossem extrados dos seres humanos, seria necessrio criar adequadas interfaces de usurio, sob a forma de formulrios que permitam a estes preench-los e assim alimentar o repositrio da base de conhecimento. Estes dados devem ser filtrados pela equipe de gerncia do conhecimento. Na Figura 5.9 observa-se, tambm, que as tomadas de decises (Decision Making) efetuadas pelos executivos e/ou pessoal tcnico so armazenadas em uma base de casos, para a sua posterior recuperao quando necessria. Esta base de casos constitui o que se chama arquivo de boas prticas e acumula experincias
103
positivas ante determinadas situaes e, em no poucos casos, quando o engenheiro de conhecimento o considere oportuno, tambm deve-se armazenar experincias negativas, para no se voltar a comet-las. Maiores detalhes sero tratados quando se explicar os diferentes repositrios que formam parte do SCM e quando se descrever a arquitetura do middleware de servios de software atravs do uso dos componentes-agentes de software na seo 5.5.7. Finalmente, ressaltase que os dados podem ser classificados como qualitativos (Qualitative Data), textos ou imagens ou som, e quantitativos (Quantitative Data), dados numricos, essa classificao mostrada na Figura 5.9.
Strategic Corporate Memory SCM Case Base
BD
Decision Making
Qualitative Data
Quantitative Data
Intelligent Agents E-mail, Portal

Log Build
RH
MK WEB
Log
Temporal Metadata Database
Fig. 5.9 Viso Arquitetural do Strategic Corporate Memory
5.3.2 A Camada Middleware ou de servios O software responsvel por facilitar os diferentes servios aos usurios do SCM encontra-se na camada mdia ou middleware layer. Esta consiste em uma coleo de ferramentas encarregadas da explorao da informao fornecida pelas fontes individuais e do apropriado gerenciamento do SCM como um todo. Exemplos de tais ferramentas so: programas para filtrar e juntar informao de diferentes fontes, programas para o gerenciamento da meta-descrio do espao de informao e programas para a manuteno do SCM quando houver alguma notificao de mudana das fontes. O middleware ser desenvolvido sob uma abordagem de agentes, assim, por exemplo, os agentes wrapper so os responsveis de capturar informao relevante das fontes e alimentar a base de conhecimento, o Organizational Baseline.
104
O meta-conhecimento das fontes facilita o descobrimento e a integrao do seu contedo no Organizational Baseline. Tipicamente, o middleware contm alguma informao acerca dos esquemas e facilidades de todas as fontes de informao registradas. A camada mdia inclui tambm os agentes usurios, que capturam as principais caractersticas e funcionalidades dos executivos da organizao. Salienta-se que a sua modelagem deva ser feita com muito cuidado, para determinar o conjunto de suas necessidades de informao, bem como as suas tarefas especficas. A definio dos agentes usurios permite, portanto, o mapeamento dessas necessidades ao repositrio de conhecimento. Assim, dada a ontologia empresarial, faz-se um mapeamento de cada termo a todos os usurios para os quais esse tipo de informao relevante. Ento, cada vez que o repositrio atualizado, um agente ouvinte que est rodando em background dispara uma mensagem a esses usurios, executando dessa forma o processo de disseminao de informao e conhecimento. Na realidade, vide Figura 5.9, cada vez que o repositrio atualizado, se cria um registro no arquivo LOG do sistema (Log Build) onde se armazena os metadados da atualizao (LOG - Temporal Metadata Database). Este arquivo consultado de tempo em tempo, por exemplo a cada 30 segundos, pelo agente ouvinte. Quando se descobrir que o LOG tem novos registros, isso significa que o Organizational Baseline foi atualizado, ento o agente ouvinte envia uma mensagem aos usurios que tm mapeado esse termo. O detalhe desta camada tratado na Seo 5.5.
5.3.3 A Camada de Repositrios A terceira camada a de repositrios (repository layer), podendo ser de conhecimento como: o Organizational Baseline e o Case Base (documentos e experincias passadas) e auxiliares como: os de Business Ontology, Hyperlink History, Upgrading Organizational Baseline e Users. No entanto, um importante desafio como recuperar a informao mais adequada dos repositrios de conhecimento, para satisfazer a necessidade de um usurio particular. Justamente para lidar com essa problemtica utiliza-se esse conjunto de repositrios adicionais para auxiliarem na extrao e disseminao do conhecimento contido no Organizational Baseline e o Case Base. Na Figura 5.10, mostra-se todos esses
105
repositrios. Nela ressalta-se pela sua importncia o Organizational Baseline, pois onde mantm-se toda a informao estratgica relevante organizao. A seguir detalha-se cada um destes: a) Organizational Baseline: Desenvolvido e baseado nas vises
positioning e resource-based da estratgia de negcios. Inclui tambm aspectos da anlise interna dos processos e das suas funes sob um enfoque da qualidade total, bem como aspectos das metforas de Morgan. Toda essa base terica foi representada no Modelo Conceitual do Organizational Baseline, utilizando a tecnologia de ontologias e o modelo de entidade-relacionamento. Este modelo conceitual engloba uma complexa rede de aspectos organizacionais modelados de maneira sistmica e objetivando futuras mudanas na prpria organizao. Portanto, o seu objetivo primrio representar o contexto organizacional com o propsito de explicitar informaes teis e relevantes. Na Figura 5.10, no interior do Organizational Baseline, apresenta-se algumas das entidades de informao que precisam ser coletadas para se poder mapear e gerenciar a informao contida nele. Estes itens de informao so coletados, como dito antes, de forma manual e automtica a partir da camada de fontes. b) Case Base: Rene experincias de projetos ou problemas resolvidos no passado e que pela sua importncia so armazenados para o seu posterior reuso. Estas experincias podem ser consultadas para encontrar knowhow relevante que sirva para guiar e dar suporte organizao no seu processo de tomada de decises. As experincias relevantes so identificadas neste repositrio baseadas nas caractersticas do contexto, do tipo de problema ou dos objetivos, utilizando heursticas de similaridade. As candidatas relevantes a reuso so sugeridas ao usurio via um sistema de navegao (hyperlinks), o qual permite a explorao interativa das candidatas. c) Business Ontology: Armazena a ontologia de domnio do SCM incluindo os conceitos e relacionamentos das entidades e atributos que formam parte do Organizational Baseline, com o intuito de facilitar o suporte semntico para o acesso a determinadas informaes de interesse presentes neles, por ex. quando um usurio quer fazer uma pesquisa no SCM que retorne
106
informao relevante ao termo estrutura da organizao, o SCM primeiro faz a consulta no Business Ontology, e no caso de encontr-lo vai existir um ponteiro ou ponteiros entidade ou atributos do Organizational Baseline, logo, baseado nesse mapeamento, procede-se a extrair o conhecimento contido neles. Alm disso, em alguns casos mostra-se tambm os seus possveis relacionamentos com os outros elementos. No caso de no existir o termo, o SCM mostra, se possvel, as entidades que so mais similares e onde provvel que exista alguma informao relevante, utilizando o mesmo raciocnio anterior.
Organizational Baseline Business Produce/Improve Results (Measures) Produce/Improve Produce/Improve Compare Functions Provide Process Own Own Own Company Affected-by Affected-by Affected-by SectorAnalysis Organizational Environment Competitive Forces
Benchmark
Business Ontology
Temporal Metadata DB Organizational Baseline
SCM
Hyperlinks History
CaseBase (Repository)
Users
Figura 5.10 Viso Estrutural dos Repositrios
d) Hyperlink History: Armazena o nmero de hits para cada uma das entidades do Organizational Baseline ou do Case Base, com a finalidade de fornecer ao usurio uma classificao baseada nas estatsticas de acesso de como outros usurios fizeram a sua escolha em situaes similares no passado. e) Upgrading Organizational Baseline: Cada vez que o Organizational Baseline atualizado cria-se um registro no arquivo LOG (Temporal Metadata DataBase arquivo de metadados temporais) do SCM o qual
107
facilita que a cada certo tempo alguns usurios, cujo perfil diga que eles utilizam esse tipo de informao nas suas atividades, sejam comunicados oportunamente (recuperao automtica). Isto se faz por meio de um agente sensor que esta observando as mudanas que acontecem no repositrio. A comunicao pode ser feita por meio de uma mensagem sobre o browser do usurio ou atravs de um e-mail ou portal, vide Figura 5.9. Com respeito ao Case Base, futuros trabalhos devem avaliar a opo de cadastrar cada caso dentro de um tpico e cada tpico para determinados usurios. f) Users: Armazena o cadastro de todos os usurios do SCM, explicitando as suas principais caractersticas (atributos), necessidades de informao e relacionamentos entre eles, quando houver.
Em resumo, o SCM para fazer a busca no repositrio de conhecimento do Organizational Baseline utiliza mapeamentos pre-estabelecidos, o qual permite a recuperao de entidades mais pertinentes dada uma consulta em particular. As palavras chave fornecidas so comparadas com a estrutura ontolgica como base para encontrar a entidade / atributo mais adequada. No caso do repositrio do Case Base, a busca se realiza utilizando heursticas de similaridade, vide detalhes na Seo 5.5.7. Extenses ao presente trabalho devem tratar o uso de outras heursticas de similaridade, para ter novas alternativas nas buscas por aproximao.
5.4 Desenvolvendo a Arquitetura de Software (Middleware) A arquitetura de software do SCM est baseada nas tcnicas de componentes e a sua implementao na abordagem de agentes. Para o seu desenvolvimento se seguir a Metodologia MESSAGE (Eurescom, 2001b). Esta nos permitir detectar as suas principais funcionalidades, as que se refletem na criao dos componentes de software, no seu mais alto nvel, para logo passar etapa de desenvolvimento de cada um deles. O mtodo utilizado sugere que se utilize um conjunto de diagramas como detalhados na seo 4.8.
108
5.4.1 O Diagrama Organizacional do SCM O Diagrama Organizacional da Metodologia MESSAGE prov uma abstrao muito importante e til para o entendimento dos outros diagramas do mtodo. O diagrama organizacional foca-se na estrutura da organizao de software e nos relacionamentos entre os elementos que ela contm. Desta forma o diagrama define a estrutura e o comportamento do SCM dentro da organizao empresarial qual esta se refere. O diagrama composto por dois modelos bsicos: o modelo estrutural e o modelo de familiaridade. a) O modelo estrutural: O modelo estrutural pode ser representado atravs de uma arquitetura composta de trs entidades bsicas: funes/ processos / sistemas, pessoas e repositrios (bancos de dados), vide Figura 5.11. b) O modelo de familiaridade ou de conhecimento (acquaintance): Na Figura 5.12 mostra-se as relaes de acquaintance ou de familiaridade entre o SCM, os principais bancos de dados da arquitetura, o pessoal das reas funcionais e de processos e os usurios. Observa-se que o SCM interage com os papeis Administrador do SCM e Usurios e com os bancos de dados LOG, OB e CB. Alm disso, tambm interage com as equipes que conformam as reas funcionais e de processos, ambas alimentam os repositrios do SCM com informao relevante.
Gerncia do Conhecimento t
Admin.
SCM
Funes
Processo
SCM
LOG
OB
CB
LEGENDA LOG: Log das transaes (Metadados) OB : Organizational Baseline CB : Base de Casos (experincias passadas)
Repositrios (Banco de dados) Organizao (funes, processos, sistemas) Pessoas (Papeis)
Figura 5.11 Diagrama do SCM dentro da Organizao
109
Admin.
SCM
Funes Pessoal Alimenta
Processos Pessoal Alimenta
Alimenta
SCM Atualiza
Atende
Executivo ou Usurio Engenheiro de Requisitos
Cria Log
Bancos de Dados Fonte (RH, Mk, etc)
Armazena LOG OB CB
Figura 5.12 Diagrama de Familiaridade do SCM
5.4.2 O Diagrama de Meta / Tarefa O principal objetivo funcional do SCM fornecer assistncia aos executivos e engenheiros de requisitos, no entanto o SCM tambm dever satisfazer outro tipo de objetivos, os chamados requisitos no funcionais (RNFs), os quais so mostrados na Figura 5.13. No presente trabalho no estudou-se em forma explcita este tipo de requisitos, mas dada a sua relevncia os mesmos sero tratados em forma implcita durante todo o processo de desenvolvimento da arquitetura. Na Figura 5.14 mostra-se como o RNF denominado de alta preciso na informao decomposto em objetivos mais especficos como preciso no clculo, preciso na escrita e preciso no tempo.
SCM Memria Corporativa Estratgica Manutebilidade
Meta
Preciso na Informao Desempenho
Interoperabilidade
Usabilidade
Portabilidade
Segurana (no acesso)
Confiabilidade
Fig. 5.13 Requisitos No Funcionais do SCM
A noo de preciso apresentada descreve o desvio permissvel entre os valores atuais e os desejveis. Na Figura 5.15 detalha-se o RNF preciso na escrita derivando-se do mesmo os RNFs preciso na consistncia interna, preciso um-a-um nos conceitos, preciso nas propriedades, preciso na
110
consistncia externa e preciso na determinao das funcionalidades (Chung, 1993; Mamani-Macedo, 1999).
Preciso na Informao
Preciso no Clculo
Preciso no Tempo
Preciso na Escrita
Figura 5.14 Requisitos No Funcionais: Preciso da Informao

Preciso na Escrita
Preciso na Consistncia Interna
Preciso na Consistncia Externa
Preciso um-a-um
Preciso nas Propriedades
Preciso nas Funcionalidades
Figura 5.15 Requisitos No Funcionais: Preciso na Escrita
Na Figura 5.16 mostra-se o RNF preciso na determinao das funcionalidades, derivando-se os sub-objetivos qualidade na evocao de conhecimento (das pessoas), aquisio de informao relevante (de valor) e gerar uma base de conhecimento confivel. Na mesma figura observa-se os agentes que realizam essas tarefas, em um alto nvel, para atingir esses objetivos. Cada uma dessas funcionalidades do software constituem, em uma primeira aproximao, um conjunto de componentes do SCM. Na seo 5.5. cada um deles estudado em um nvel de detalhe maior, mostrando a sua estrutura e comportamento. Na Figura 5.17 analisa-se a tarefa elicitar conhecimento das pessoas. Esta tem trs sub-tarefas: definir as necessidades de informao, preparar o questionrio e desenvolver formulrios para o ingresso dessas informaes (conhecimentos), a partir do qual logo se atualiza o Organizational Baseline. Na Figura 5.18 analisa-se a tarefa preparar o questionrio, a qual explodida em trs sub-tarefas: entrevistar os executivos, avaliar questionrios passados e analisar o ambiente que rodeia o negcio. Observa-se que o processo de raciocnio utilizado chegou at o nvel de tarefas operacionais que so independentes do software, o qual mostra a robustez do mtodo empregado.
111
Preciso nas Funcionalidades Agente Tarefa
Qualidade na Evocao do Conhecimento Agente Executivo
Aquisio de Informao Relevante
Base de Conhecimento Confivel
Elicitar Conhecimento
Agente Interface
Capturar Informao
Agente Informao
Gerar Base de Conhecimento
Agente Informao
Atualizao Base de Conhecimento
Figura 5.16 Requisitos Funcionais e No Funcionais: Uma primeira aproximao para a determinao dos Componentes do SCM
Elicitar Conhecimento (das pessoas)
Definir Necessidades de Informao
Preparar Questionrio
Desenvolver Formulrios (Conhecimento)
Figura 5.17 Tarefa: Elicitar Conhecimento

Preparar Questionrio
Entrevistar
Executivos
Avaliar
Questionrios Passados
Analisar
Ambiente do Negcio
Figura 5.18 Tarefa Preparar o Questionrio
Em conjuno com a decomposio dos RNFs til determinar quais sero os servios prestados pelo SCM, bem como mostrar o conjunto de tarefas necessrias para atingir satisfatoriamente tais servios. Estas tarefas devem casar com as tarefas decorrentes da decomposio dos RNFs. Na Figura 5.19 mostra-se as duas tarefas bsicas do SCM, os servios consulta requerida e disseminao automtica, os quais so detalhados na mesma figura, a ordem descendente indica o workflow de cada um deles. O servio consulta requerida tem a subtarefa busca da palavra chave no Thesaurus da ontologia, isto implica que
112
previamente tem que ser mapeada a ontologia ao Organizational Baseline, sendo assim, decidiu-se que esta deveria constituir-se, pela sua importncia dentro do SCM, em um componente separado. O servio de disseminao automtica tem a sub-tarefa ler o LOG do baseline, o qual tem que ser gerado cada vez que o Organizational Baseline atualizado, seguindo o mesmo raciocnio anterior, decidiu-se que a disseminao do LOG deveria constituir-se tambm em um componente independente. Finalmente, existe um conjunto de itens que no tm sido tratados at agora: as lies aprendidas ou boas prticas as quais devem povoar a base de casos de experincias passadas (CB), esta pela suas prprias caractersticas ir se constituir tambm em um componente independente. Na Figura 5.19 observa-se o elemento Busca da Palavra Chave nas Regras da Ontologia, o qual implica que tem que se gerar uma mquina de inferncia, mas como explicado antes, o escopo do presente estudo no envolve o seu desenvolvimento, ficando assim como um tpico para trabalhos futuros do SCM.
Assistir ao Usurio
Consulta Requerida
Disseminao Automtica
Requisitos da Consulta (Palavra Chave) Busca da Palavra chave nas Regras da Ontologia Busca da Palavra chave no Thesaurus Ontologia Extrao de Conhecimento do OB Notificar ao Usurio
Atualizao Organizational Baseline Ler
o LOG
Extrao de Conhecimento do OB Notificar ao Usurio
Figura 5.19 Outra Viso: Os servios do SCM (requisitos funcionais)
Uma viso mais detalhada de todas essas funcionalidades e componentes ser fornecida nas sees 5.4.5 e 5.5, onde se mostrar primeiro, a viso de projeto do SCM e, a seguir, a sua estrutura e comportamento.
113
5.4.3 O Diagrama de Agente / Papel Este modelo faz uso do diagrama estrutural de delegao, vide Figura 5.20, o diagrama de workflow e esquemas textuais de agente / papel, vide tabela 5.6. O primeiro mostra como o requisito funcional de servios do SCM explodido em submetas obtidos como resultado da descomposio do objetivo macro assistir ao usurio. Nota-se que cada meta ir gerar uma tarefa e cada tarefa ser atribuda aos agentes/papis pertinentes que formam parte da organizao de software do SCM. Enfatiza-se que este diagrama no s est estritamente relacionado com o diagrama de decomposio dos servios prestados pelo SCM, como tambm deve ser consistente com o mesmo, vide Figuras 5.19 e 5.20.
SCM
Assistir ao
Usurio
Busca Maquina Regras
Consulta Requerida
Disseminao
Requisitos
Busca
Extrao
Notificao
Agente Validao
Agente Busca Thesaurus
Agente Extrator
Agente de Notificao
Figura 5.20 O Diagrama Estrutural de Delegao
Na Figura 5.20 mostra-se, em um primeiro nvel, o principal servio do SCM: assistir ao usurio (executivo ou engenheiro de requisitos), o qual tem dois sub-servios ou metas consulta requerida e disseminao. Na figura detalha-se o primeiro com os seus quatro sub-servios meta/tarefa, requisitos da consulta, busca no thesaurus, extrao de conhecimento e notificao ao usurio. No aparece o servio busca na mquina de regras da ontologia porque este no est sendo tratado no presente trabalho. De forma similar, um diagrama workflow dever mostrar os papeis que devem cumprir os agentes na organizao de software, bem como a execuo das tarefas necessrias para implementar o servio fornecido pela aplicao do SCM. Para cada agente / papel existe um esquema que descreve as suas caractersticas, vide Tabela 5.6, na mesma nota-se
114
que o contedo destes esquemas realizado em linguagem natural. (Eurescom, 2001b)

Esquema Agente / Papel Metas Agente Extrator Extrair informao relevante do Organizacional Baseline (OB) e/ou da Base de Casos (CB) de experincias passadas (lies aprendidas). Utilizando os ndices de mapeamento dever extrair a informao / conhecimento dos repositrios OB e/ou CB. Dever ter conhecimento de que ante consultas similares, por um usurio determinado, exista um arquivo histrico, o qual ajudaria ao agente de notificao ao escalonamento dos resultados. Dever receber do agente procura os ndices de mapeamento (chave de acesso).
Capacidades Conhecimento / Pensamentos
Requisitos do Agente
Tabela 5.6 Esquema Agente / Papel para o Agente Extrator (Eurescom, 2001b)
5.4.4 O Diagrama de Interao Este diagrama ressalta qual, porque e quando os agentes / papis necessitam se comunicar, mas no trata detalhes de como a comunicao se efetua - isso ser tratado na fase de projeto mediante a utilizao do protocolo FIPA (2003) (Foundation for Intelligent Physical Agents). Usualmente este diagrama refinado atravs de um processo de vrias iteraes, tantas quantas sejam necessrias. O diagrama de interao tem como elementos o iniciador, o respondente, o motivador de uma interao (fornece o objetivo do iniciador), mais outras informaes opcionais como a condio do trigger (disparador) e as informaes fornecidas e obtidas por cada agente. A Figura 5.21 mostra o diagrama de interao entre o agente busca e o agente extractor. O agente busca tem como objetivo um requerimento de informao do motivador que outro agente.
Iniciador Agente Busca Solicitude de Notificao Respondente (Colaborador) Agente Extractor
1 Requerimento Informao Agente Motivador 1 e-Mail 1..* Fornecimento de Informao Conceito / Atributo
Figura 5.21 O Diagrama de Interao entre os agentes Extrator e Busca
No exemplo, o agente motivador faz um pedido ao agente busca de determinada informao, o agente busca atravs de uma Solicitude de Notificao
115
encaminha ao agente extrator por esse Requerimento de Informao. O agente extrator via outra Solicitude de Notificao faz o Fornecimento de Informao dos conceitos/atributos relevantes. Logo, o agente busca encaminha essa informao ao agente motivador. De maneira similar funcionam todos os outros diagramas de interao dos demais agentes de software. importante declarar que a modelagem dos protocolos de interao situam-se no limite entre as fases de anlise e projeto. Portanto, a interao pode ser detalhada em qualquer dessas fases.
5.4.5 Estruturando os Resultados de acordo aos organizacional, meta / tarefa, agente / papel e interao
diagramas
A seguir, como resultado da anlise estrutural do diagrama organizacional da Metodologia MESSAGE e dos diagramas meta / tarefa e de interao mostrase, na Figura 5.22, um maior nvel de detalhe do projeto arquitetural de software do SCM.
SCM
Organization Structure
PurposeDescrip
Workflow Structure
Control(Sensor)
Agent
Roles
Task
Results
InformationEntity
UserAgent
Application Agent
GenerateKnowledge (From BD)
Produce/Feed Feed
Knowledge Base
(Organizat.Baseline)
ElicitKnowledge (From people)
F DisplayKnowledg (Browser)
Information
CaptureKnowledge (From Internet)
e Produce
Interface
Disseminate Knowledge Produce StoreDecision Making
DecisionMaking CaseBase
TaskAgent
UpgraOrgBaseline Produce SearchKnowledge Produce
OutputVector
Statistics
Figura 5.22 Viso de Projeto do SCM
Observa-se que as principais tarefas do SCM so gerar a base de conhecimento (GenerateKnowledge) o que reflete-se no Organizational Baseline;
116
elicitar o conhecimento das pessoas (ElicitKnowledge); capturar conhecimento da internet (CaptureKnowledge); disseminar conhecimento (Disseminate
Knowledge); armazenar tomadas de decises (StoreDecisionMaking); atualizar o Organizational Baseline (UpgraOrgBaseline) e busca de conhecimento nos repositrios (SearchKnowledge). Os principais resultados alm do Organizational Baseline so mostrar conhecimento no browser (DisplayKnowledg); o repositrio de tomada de decises (DecisionMaking CaseBase); o mapeamento da ontologia ao Organizational Baseline (OutputVector) e as estatsticas de acesso (Statistics).
5.4.6 O Diagrama de Domnio Segundo a Metodologia MESSAGE, o modelo de domnio pode ser convenientemente representado atravs dos diagramas de classe UML, onde as classes representam elementos especficos ao domnio da aplicao e os relacionamentos as suas associaes. Na Figura 5.23 mostra-se a relao que existe entre a ontologia do domnio do negcio e o modelo do negcio.
Business Ontology
Offers
1..*
Concepts
Name Attributes
Organizational Baseline Business Produce/Improve Results (Measures) Produce/Improve Produce/Improve Compare Benchmark Functions Process Own Own Own Co Affected-by Affected-by Affected-by SectorAnalysis Organizational Environment Competitive Forces
Figura 5.23 AViso de Domnio do SCM
Na Figura 5.24 mostra-se em detalhe a anlise do domnio do processo de busca, nela observa-se como o SearchQuery utiliza o relacionamento casar
117
(matches) para procurar o termo no thesaurus da ontologia do domnio (Thesaurus Ontology), extrair os conceitos (ConceptList) e logo para cada conceito extrair os usurios que poderiam estar interessados em possuir essa informao (UserList), finalmente se efetua a disseminao via uma janela (WindowDissemination).
S e a rc h Q u e ry m a tc h e s T h e s a u ru s O n to l o g y
l is t 1 ..n C o n c e p tL i s t
m a tc h e s W i n d ow D is s e m i n a t i o n m a tc h e s 1 ..n U s e rL is t
Figura 5.24 O Processo de Consulta do SCM
Na Figura 5.25 mostra-se o processo de disseminao automtica (AutomaticDissemination), o qual comea com a leitura do arquivo LOG (LogFile) de onde se extrai os conceitos que mudaram no baseline (ConceptsList) e, como no caso anterior, para cada conceito so extrados (matches) os usurios relevantes e via e-mail (e-mailDissemination) essa informao disseminada a todos eles.
Auto m a ticD is s e m in a tion m a tche s L o gFile
m atch es 1 ..n C on cep ts Lis t
m atch es 1 ..n e -m a ilD is s em ina tion d is s em in atio n U s erL is t
Figura 5.25 Os Processos de Disseminao Automtica do SCM
118
5.5 Descrio dos Componentes-Agentes da Arquitetura de Software Uma arquitetura de software predefine um conjunto de componentes funcionais, descritos em termos de seus prprios componentes e interfaces no qual o sistema dividido. Assim, uma descrio arquitetural est primariamente preocupada com a estrutura do sistema e com a especificao de suas funes e responsabilidades, mas trata tambm das regras e diretrizes que ajudam na organizao dos relacionamentos entre os componentes. Faz-se notar que o termo componente, tal como empregado aqui, inclui componentes funcionais, agentes, subsistemas e mdulos (Eurescom, 2001a). Neste sentido, a arquitetura do SCM fornece, em um alto nvel, a forma como as suas partes podem ser utilizadas e instanciadas. Acredita-se que o SCM pode ser completamente implementado usando um sistema multi agente (MAS), porque ao igual que um MAS o domnio no qual se insere a memria corporativa possui: um ambiente externo; objetivos a serem atingidos; capacidades (de negcio) necessrias para suportar esses objetivos e; um conjunto de planos (explcitos) a serem selecionados. Por exemplo, se quisermos fazer um planejamento de marketing estratgico (objetivo e planos especficos), ser necessrio determinar que informaes ou conhecimentos mantidos no SCM podem ser relevantes para essa atividade (entidades do ambiente externo e capacidades). Por outro lado, considerando que o SCM um sistema de software distribudo orientado ao negcio, lida com aspectos de: aprendizado (capacidade de acumular conhecimento baseado em
experincias passadas, por exemplo a partir do arquivo LOG do sistema pode se deduzir o tipo de informao que determinada rea da empresa mais utiliza, facilitando a disseminao automtica); interatividade (capacidade de se comunicar com o seu ambiente e com outros agentes, por exemplo recepcionar uma solicitude de busca); e
119
autonomia (capacidade de acessar as fontes de informao e de forma proativa recupera-as, analisa-as, manipula-as e integra-as).
Todas essas caractersticas so difceis de serem alcanadas com abordagens baseadas em objetos, devido a isto, tomou-se a deciso de aplicar uma abordagem baseada em agentes e de sistemas multi agentes. Dado que a arquitetura do SCM est desenvolvida, basicamente, sob uma abordagem de agentes, necessrio a utilizao de uma plataforma de comunicao que facilite o seu gerenciamento. Entretanto, anota-se que esta plataforma no exclusiva para o uso dos agentes de software, pode tambm ser utilizada para a comunicao entre componentes. Na presente tese prope-se a utilizao da plataforma FIPA (2003) para a comunicao entre os agentes do SCM.
AGENTES - COMPONENTES
Busca e Entrega Armazenamento e Disseminao Armazenamento Lies Aprendidas
Interface
Usurio
Descobrimento
Regras de Inferncia *
Controle e Comunicao
CAMADA MIDDLEWARE
Log Organizational Case Base Metadata Baseline
Seres Humanos
DataBases
CAMADA DE REPOSITRIOS
CAMADA DE FONTES
Figura 5.26 Os Componentes da Arquitetura de Software do SCM (* No tratado no presente trabalho
Na Figura 5.26 observa-se os principais componentes da arquitetura de software do SCM, mas relevante mencionar que os mesmos so resultado da anlise da seo 5.4.5, onde estruturou-se a viso de projeto do SCM, o qual permitiu visualizar as suas principais funcionalidades, as mesmas que serviram de base para a criao dos componentes do SCM. Salienta-se que a arquitetura de
120
agentes Message, vide seo 4.8.6, utilizada para descrever os agentes de software est orientada, fundamentalmente, ao desenvolvimento dos agentes de aplicao do SCM. Um dos componentes do SCM, o de Controle e Comunicao no ser estruturado sob a arquitetura do agente Message. Primeiro, porque este no de aplicao e segundo, porque este componente est baseado no Projeto P815 da Eurescom (2001a). A seguir descreve-se os diversos componentes e as suas ligaes com a viso de projeto do SCM mostrado na Figura 5.22: Controle e Comunicao: fornece a infra-estrutura bsica para o gerenciamento e a comunicao de agentes. a plataforma sobre a qual atuam os agentes; Interface: inclui formulrios GUI para acesso s informaes e conhecimentos fornecidos pelos seres humanos. Possui as opes agregar, modificar, consultar e, eliminar. Reflete a funcionalidade ElicitKnowledge da viso de projeto do SCM; Descobrimento: ao inicio responsvel pelo povoamento da Base de Conhecimento, preenchendo o Organizational Baseline a partir da captura de informao dos arquivos fontes previamente definidos, logo faz a funo de manuteno, atualizando o baseline quando houver alguma mudana na camada de fontes. Este componente trata as funcionalidades de gerar a base de conhecimento (GenerateKnowledge), capturar conhecimento dos bancos de dados internos, arquivos legados e a web (CaptureKnowledge) e, atualizar o Organizational Baseline (UpgraOrgBaseline), vide a Figura 5.22 viso de projeto do SCM; Busca e Entrega: dada uma requisio de informao/conhecimento, consulta-se no repositrio de conhecimento, extrai-se aquilo que foi pedido para logo entregar os resultados ao solicitante. Notar que a busca se realiza primeiro no thesaurus da ontologia e depois no repositrio das regras de inferncia, para o qual dever utilizar-se os axiomas da ontologia para inferir respostas ante determinadas consultas. Est ltima opo no tratada no presente trabalho. Este componente reflete a funcionalidade busca de conhecimento (SearchKnowledge), vide a Figura 5.22;
121
Armazenamento e Disseminao: cada vez que o Organizational Baseline atualizado se cria um registro da transao no LOG com os conceitos e atributos que tenham sido alterados. Logo, utiliza-se esse arquivo para iniciar o processo de disseminao aos usurios relacionados, os que deveram ter sido previamente cadastrados. Envolve as funcionalidades ElicitKnowledge, CaptureKnowledge e
DisseminateKnowledge da viso de projeto do SCM. Este componente agente interage com os componentes agentes Interface e Descobrimento. Usurio: cadastra os diferentes usurios da organizao empresarial que utilizaro o SCM, tendo em considerao as suas necessidades de informao. Para definir o componente Usurio do SCM utilizou-se uma instncia do agente interface (Application Agent) da viso de projeto do SCM; Armazenamento das Lies Aprendidas: povoa a base de casos com experincias passadas, define tambm uma opo de busca por similaridade. A funcionalidade armazenar tomadas de decises (StoreDecisionMaking) da viso de projeto o origem deste componente.
5.5.1 O Componente Agente Plataforma de Controle e Comunicao o responsvel por fornecer a infra-estrutura bsica para o controle e comunicao dos agentes de software. Essa infra-estrutura operacionalizada por meio de um conjunto de facilidades que so detalhadas a seguir (Eurescom, 2001a): Gerenciamento de agentes: inclui a criao, eliminao, registro (marcao) e de-registro (desmarcao) na plataforma de controle e comunicao; Negociao dos servios do agente: representado pelo servio de pginas amarelas; Fornecimento de uma linguagem de comunicao de agentes e de uma linguagem de contedo; Comunicao de agentes e de linguagem de contedo, representado pelos protocolos de comunicao;
122
Segurana da plataforma de controle e comunicao de agentes e de cada agente em si.
O componente de plataforma de controle tm por sua vez os seguintes componentes: o Facilitador de Diretrio (Directory Facilitator DF), o Sistema de Gerenciamento de Agentes (Agents Management Sytsem - AMS) e o Canal de Comunicao de Agentes (Agents Communication Chanel ACC). Todos eles so tipos especficos de agentes que suportam o gerenciamento e comunicao entre sistemas de agentes. O AMS e o ACC suportam a comunicao entre agentes, o ACC suporta a interoperabilidade dentro e atravs de diferentes plataformas. O primeiro caso acontece quando se tem um s SCM. O segundo, no tratado no presente trabalho, acontece quando dois ou mais SCMs de diferentes organizaes querem se comunicar. Isto possvel hoje em dia, pois o mundo dos negcios mudou, sendo comum o estabelecimento de redes de organizaes na forma de joint ventures, alianas estratgicas e fuses com clausulas que deixam aberta a possibilidade de no futuro volver a separar-se. Todos os agentes antes mencionados se comunicam atravs de um servio de roteamento (encaminhamento) de mensagens, o qual denominado de Transporte de Mensagens para Plataformas Internas (IPMT Internal Platform Messages Transport). Este servio deve ser confivel e ordenado. Assim, o DF, AMS, ACC e IPMT formam o que se denomina a plataforma de agentes (Agents Platform), sendo o IPMT o meio pelo qual se efetua a comunicao com os outros componentes-agentes do SCM. O padro FIPA, que utilizado neste componente, uma plataforma de agentes que facilita o gerenciamento destes, fornecendo tambm uma linguagem de comunicao de agentes (Agents Communication Language ACL), o FIPAACL. No entanto, anota-se que tambm poderia ser utilizado qualquer outro tipo de plataforma, por exemplo CORBA, como um meio bsico para a comunicao de agentes intra ou inter domnios e, para a comunicao com sistemas legados ou para a comunicao entre componentes.
123
5.5.1.1 O Facilitador de Diretrio (DF) um tipo de agente que fornece o servio de pginas amarelas aos outros agentes. O DF o responsvel pela manuteno e segurana do diretrio de agentes, para o qual mantm uma lista exata, completa e oportuna dos agentes. Ao mesmo tempo, o DF fornece informaes atualizadas dos agentes, sobre uma base no discriminatria, a todos os agentes autorizados. No entanto, o DF pode tambm restringir o acesso a seu diretrio, verificando todas as permisses de acesso dos agentes que tentem se informar das mudanas de estado dos outros agentes. O DF no controla o ciclo de vida interno de qualquer agente. Os agentes registram seus servios com o DF e tambm o consultam para averiguar que servios so oferecidos e por quais agentes. Tanto o AMS como o ACC podem se registrar com o DF. Os membros de um diretrio DF definem o domnio do agente, onde um domnio um espao lgico fornecendo um contexto dentro do qual os agentes podem se organizar e localizar entre eles. As operaes suportadas pelo DF so: deRegister (de-registro), modify (modificao), register (registro) e search (busca).
5.5.1.2 O Sistema de Gerenciamento de Agentes (AMS) O AMS exerce o controle e a superviso sobre o acesso e uso do ACC, previamente deve se registrar com o DF. Tambm responsvel pelo gerenciamento das atividades do componente de controle, incluindo as responsabilidades de criao e eliminao de agentes, bem como decidir se um agente pode se registrar dinamicamente no DF e inspecionar a migrao de agentes para e desde outras plataformas. O AMS mantm um ndice de todos os agentes que so atualmente residentes na plataforma. As operaes suportadas pelo AMS so as seguintes: autentify (autentificar), registerAgent (registro de agentes), deRegisterAgent (de-registro de agentes), modifyAgent (modificar agentes), todas em tempo de configurao.
124
5.5.1.3 O Canal de Comunicao de Agentes (ACC) Fornece uma rota para o contato e intercmbio bsico entre um agente e os outros agentes, podendo incluir tambm o DF e o AMS. A funcionalidade principal do ACC encaminhar mensagens entre agentes do SCM e para agentes residentes em outras plataformas. Esta ltima opo no tratada neste trabalho. Ressalta-se que somente mensagens endereados a um agente podem ser enviados por meio do ACC, para o qual utiliza-se a operao: forward (encaminhar).
5.5.1.4 A Comunicao de Agentes A comunicao de agentes, seja intra agentes ou inter agentes, exige a utilizao de uma linguagem de comunicao de agentes (Agent Communication Language - ACL) e os seus correspondentes protocolos. A seguir descreve-se os elementos estruturais de uma mensagem ACL que satisfaz a especificao FIPA97, parte 2 (Eurescom, 2001a):
<message> <communication-act> inform </communication-act> <sender> agentSCM-sender </sender> <receiver> agentSCM-receiver </receiver> <content> expression-of-content </content> <in-reply-to> </in-reply-to> <reply-with> </reply-with> <reply-by> <envelope> <time-sent> </time-sent> </reply-by>
<time-received> </time-received> <route> </envelope> <language> </language> <ontology> </ontology> <protocol> </protocol> <conversation-id> </conversation-id> </message> </route>
125
O primeiro elemento identifica o ato comunicativo que est sendo comunicado, vide Tabela 5.7, definindo o significado principal da mensagem, seguido por uma seqncia de parmetros. Os parmetros <sender> e <receiver> definem os agentes de envio e recepo respectivamente. O parmetro <content> contem o contedo da mensagem, codificado em alguma linguagem previamente definida a qual deve ter, por sua vez, um conjunto de parmetros. Os parmetros <language> e <ontology> ajudam ao <receiver> a interpretar o significado da mensagem. Os parmetros <reply-with> e <reply-by> ajudam ao <receiver> a responder em forma cooperativa, especificamente o <reply-by> indica o ltimo momento que o remetente aceitaria uma replica e o <reply-with> indica que se deve de introduzir uma expresso a qual ser utilizada pelo <receiver> para identificar a mensagem original, quem responde utilizando o parmetro <in-replyto>. Estes dois parmetros podem ser utilizados para seguir o thread de uma conversao, em situaes onde vrios dilogos ocorrem simultaneamente.
Communicative act
accept-proposal agree

Information passing
Requesting information
Negotiation
Action performing
Error handling
cancel cfp

confirm disconfirm
failure inform

inform-if (macro act) inform-ref (macro act) not-understood propose
query-if query-ref
refuse reject-proposal
request request-when

request-whenever subscribe
Tabela 5.7 Atos Comunicativos na Especificao FIPA (Eurescom, 2001a)
126
O parmetro <envelope> fornece informao til da mensagem como por exemplo hora de envio <time-sent>, hora de recepo <time-received>, rota <route> e outros aspectos relevantes do servio de mensagens. O parmetro <protocol> denota o protocolo que o remetente est utilizando, serve para dar um contexto adicional para a interpretao da mensagem. O parmetro <conversationid> utilizado para identificar uma seqncia de atos comunicativos que juntos formam uma conversao, fornece tambm um contexto adicional para a interpretao do significado da mensagem. Os parmetros podem colocar-se em qualquer ordem. O nico parmetro que mandatrio em todas as mensagens o <receiver>. Na Tabela 5.7 mostra-se os principais atos comunicativos e as categorias nas quais podem se agrupar as mesma (Eurescom, 2001a). 5.5.1.5 Negociao de Agentes O objetivo de todo agente maximizar seus interesses, enquanto tenta alcanar acordos com outros agentes. Isto requer necessariamente a existncia de um processo de negociao, o qual exige uma seqncia de ofertas e contraofertas que minimize o custo ou maximize o beneficio, dependendo do papel que o agente esta desempenhando. O processo de negociao faz uso do ACL que fornece os atos comunicativos que a operacionalizam, sendo estes os seguintes: cfp (calling for proposals) ao de chamada de propostas para executar uma ao dada, propose ao de submeter uma proposta para executar uma certa ao, dadas certas pre-condies, accept-proposal ao de aceitar uma proposta previamente submetida para executar uma ao, reject-proposal ao de rejeitar uma proposta para executar alguma ao durante uma negociao.
5.5.1.6 Protocolos de Negociao A troca contnua de mensagens de negociao freqentemente cai em padres tpicos. Nesses casos, so esperadas certas seqncias de mensagens e em algum
127
ponto da conversao outras mensagens so esperadas que sigam. Estes padres, chamados de protocolos de negociao, facilitam a simplificao da conversao para o alcance de acordos e a efetiva interoperao de agentes. O padro FIPA prov dois protocolos que podem ser utilizados na negociao, o FIPA-contract-net e o FIPA-iterated-contract-net, sendo o ltimo uma extenso do primeiro, vide Figura 5.27 (Eurescom, 2001a) .
cfp action preconditions1
not-understood FIPA-ContractNet
refuse reason
bid preconditions2
Deadline
reject-offer reason
accept-offer preconditions3
counter-offer preconditions4
preconditions3
perform action
failure reason
inform Done(action)
Figura 5.27 O Protocolo FIPA-iterated-contract-net
5.5.2 O Componente Agente Interface Este componente-agente responsvel pela entrada de informao que no pode ser capturada de forma automtica a partir da camada de fontes de dados. Para esta tarefa utiliza-se um conjunto de formulrios (forms), os quais refletem as caractersticas dos conceitos e atributos que foram elicitados durante a anlise do domnio, etapa de criao da ontologia do negcio. A definio de cada formulrio do agente interface, deve evidenciar a sua estrutura declarando os seus
128
correspondentes atributos. Isto necessrio porque cada especializao deste uma entidade do Organizational Baseline e portanto diferente de qualquer outra. Segundo o modelo de negcio estabelecido anteriormente na seo 5.2, as suas diferentes entidades esto relacionadas entre si, o que significa que tem que se considerar as possveis implicncias quando alguma delas muda no baseline. Em outras palavras, a especializao do agente interface tem que levar em conta o impacto que uma mudana, em alguma entidade, pode ter nas outras entidades vinculadas a esta. Nesse sentido, a complexidade e dificuldade de uma especializao do agente interface ir depender fundamentalmente de seus relacionamentos existentes com as outras entidades (instancias do agente interface).
User Agent
Agent beliefList goalList planList setBelief() addBelief() setGoal() addGoal() setPlan() addPlan() Domain Layer Resource Layer Storing& Dissemination Agent Company
Business
InterfaceAgent
Client
Perception& Communication Layer
Decision& Management Layer
Domain Manager dataChecking() getEntity() getEntityList() setEntity() addEntity() elimineEntity()
Resource Manager addLog() sendMessage() showMessage() receiveMessage() retrieveFormGUI() deleteEntity() readEntity() writeEntity() updateEntity() openDB() closeDB()
UserProfile Manager retrieveUser() storeUser()
Perception & Communication Manager analysingEvent() analysingMessage() inform() reject() propose() finish() accept() forward()
DML Manager
makingDecision() creation() destruction() monitoring() captureEvent()
Figura 5.28 O Componente Agente Interface
Na Figura 5.28 observa-se que o Agente Interface (InterfaceAgent) uma subclasse da classe Agente (Agent), esta ltima define as caractersticas gerais do agente como so o cadastramento dos pensamentos (Beliefs), metas (Goal) e planos (Plans). Mostra-se tambm na figura algumas das possveis
especializaes do agente interface como so Companhia (Company) , Negcio (Business) e Cliente (Client), porm de fato existem outras especializaes como as definidas no modelo do negcio. De acordo seo 4.8.6 um agente Message tem os seguintes componentes: Recursos (RL - Resource Layer), Domnio (DL DomainLayer), Percepo e Comunicao (PCL - Percepo & Comunication
129
Layer) e, Deciso e Gerenciamento (DML Decision & Management Layer), nos pargrafos seguintes detalha-se cada um deles no mbito do agente interface. O componente DL (Domain Layer) tem a operao dataChecking, a qual responsvel pela checagem dos dados ingressados no formulrio. A checagem pode ser de dois tipos: de unidade (sub-operao dataCheckingUnitary), quando se checa cada atributo em forma independente, e de integridade (sub-operao dataCheckingIntegrity), quando se checa o relacionamento que pode ter com outros atributos da mesma entidade. Por exemplo, seria incoerente que exista a seguinte possibilidade: Estilo de Liderana
Colaborativa, e Autocrtico
Forma de Governo
para que no acontea esse tipo de situao que existe a operao dataChecking. Outras operaes fornecidas pelo DL so: agregar entidade (addEntity), eliminar entidade (elimineEntity), obter entidade (getEntity), atualizar entidade (setEntity) e obter lista de entidades (getEntityList). O componente RL (Resource Layer) no s responsvel pela execuo de aes sobre o mundo externo, como tambm pela recepo de mensagens. Inclui entre as suas funes a recuperao de recursos internos como o caso dos formulrios GUI. As operaes definidas para este componente so: recuperao de formulrios GUI (retrieveFormGUI), apagar entidade (deleteEntity), ler entidade (readEntity), gravar entidade no banco de dados (writeEntity), atualizar entidade no banco de dados (updateEntity), abrir o banco de dados (openDB), fechar o banco de dados (closeDB), informar a existncia do proxy do agente (informProxy) - cada agente que esta enviando uma mensagem a outro agente deve ter um proxy desse agente, onde o proxy representa internamente a esse agente -, informar a existncia de uma implementao do proxy no servidor (informServer) - os servers oferecem uma implementao para uma interface que acedida pelos proxies. Outras operaes so: mostrar formulrio GUI (showFormGUI), mandar mensagem a outro agente ou usurio (sendMessage) e receber mensagem de outro agente ou usurio (receiveMessage). O componente DML (Decision & Management Layer) responsvel pelo controle das aes do agente atravs de decises deliberativas; para isso faz o
130
monitoramento do ambiente externo, capturando os eventos que refletem as mudanas no baseline. Outra de suas funes o gerenciamento do mesmo agente, realizando tarefas de criao, destruio e monitoramento. As operaes definidas para o DML so: executar uma determinada tomada de deciso baseada nas condies de estado dos atributos e das variveis do ambiente externo (makingDecision), criar uma instncia do agente (creation), eliminar uma instncia do agente (destruction), fazer o monitoramento do agente (monitoring) exceto as mudanas no baseline - e capturar os eventos do ambiente externo (captureEvent). O componente PCL (Perception & Communication Layer) recebe tanto informaes de baixo nvel do mundo externo via o RL, como informaes de alto nvel via o DML. No primeiro caso, recebe o contedo das mensagens e no segundo, o tipo de evento. Este componente tm como operaes: analisar o evento recebido (analysingEvent), solicitar analisar o o contedo da mensagem
recebida(analysingMessage),
estabelecimento
de comunicao
(request), informar o estado da comunicao (inform), rejeitar a mensagem (reject), propor alguma alternativa (propose), finalizar a comunicao (finish), aceitar a mensagem (accept), encaminhar a mensagem (forward). A seguir descreve-se o funcionamento do agente interface. Primeiro, o DML cria o agente interface, o qual especializado dependendo do tipo de conceito a ser tratado, logo chamado o formulrio GUI especifico por meio da operao retrieveFormGUI do RL, o mesmo que preenchido pelo usurio, em seguida o DML atravs da operao captureEvent captura a ao a ser realizada analisando o tipo de evento atravs da operao analysingEvent, logo o transmite ao DL, via a operao forward do PCL, que executa a operao dataChecking, a mesma que analisa o contedo do formulrio e determina que conceitos e atributos devem ser checados. Finalmente, o RL recebe do DL o contedo checado e atualiza o Organizational Baseline, utilizando as operaes addEntity ou setEntity. Como aconteceu uma mudana no baseline do SCM, cria-se um registro log com o nome da entidade e os atributos que mudaram. Para fazer isto o agente interface se comunica com o agente de armazenamento e disseminao que grava o registro no arquivo LOG.
131
O agente interface deveria interagir diretamente com o agente usurio, pois aps a atualizao de alguma entidade sabe-se que essa mudana na entidade ou nos seus atributos, eventualmente, poderia afetar ou ser de suma importncia para determinados usurios. Ento, o ideal seria que o agente interface tenha dentro do PCL um log-Manager, encarregado de fazer a comunicao com o agente usurio. Mas bom lembrar que o Organizational Baseline no s atualizado pelo agente interface, como tambm por outros agentes como o agente descobrimento, o qual atua diretamente nas fontes de dados do SCM. Assim, determinou-se que seria conveniente criar um agente especifico, responsvel exclusivo pelo
armazenamento e disseminao do contedo do arquivo LOG, o qual deve comunicar-se com o agente usurio para atingir o objetivo do SCM, de disseminar os novos conhecimentos que foram colocados no baseline. Esses agentes sero analisados nas prximas sees.
5.5.3 O Componente Agente Usurio O componente agente usurio responsvel pelo gerenciamento dos dados do perfil do usurio. Desde o ponto de vista estrutural os atributos bsicos deste agente so nome, cargo, unidade organizacional, entidades com as quais est relacionado e atributos aos quais tm acesso. Instncias de agentes usurios so por exemplo, vide Figura 5.29: o Gerente Financeiro (Financial Manager), o Gerente de Marketing (Marketing Manager), o Gerente de Recursos Humanos (Resources Human Manager), o Engenheiro de Requisitos (Requirement Engineer), entre outros. Salienta-se uma situao que pode acontecer em no poucos casos: que um determinado usurio tenha acesso a determinada entidade, mas no a todos os atributos da mesma. Alguns atributos podem ter restries de acesso por conter informao confidencial. O ponto referente a segurana no tratado na presente tese, fica para futuros trabalhos do SCM. A seguir declara-se as principais operaes dos componentes do agente usurio: o DL tem as operaes: validar a informao ingressada no formulrio usurio (dataCheckingUser), agregar usurio (addUser), modificar usurio (modifyUser), eliminar usurio (elimineUser), obter usurio (getUser) e obter lista de usurios (getUserList). O RL tm as operaes recuperar formulrio do usurio
132
(retrieveFormUser), sendMessage, receiveMessage, showMessage, mostrar dados do usurio (showUser), apagar dados do usurio (deleteUser), ler no banco de dados (readUser), gravar no banco de dados (writeUser), atualizar no banco de dados (updateUser), openDB e closeDB. O PCL tm como operaes analysingEvent, analysingMessage, inform, reject, propose, finish, accept e forward. As operaes do DML so: makingDecision, creation, destruction, monitoring, e captureEvent. Tanto as operaes do PCL e do DML so similares s definidas no componente agente interface. Na Figura 5.29 mostra-se as operaes antes citadas.
InterfaceAgent
Agent beliefList goalList planList setBelief() addBelief() setGoal() addGoal() setPlan() addPlan() Domain Layer Resource Layer Storing& Dissemination Agent Financial Manager Marketing Manager
UserAgent
Requirement Engineer
Domain Manager dataCheckingUser() getUser() getUserList() modifyUser() addUser() elimineUser()
Resource Manager retrieveFormGUI() sendMessage() showMessage() receiveMessage() showUser() deleteUser() readUser() writeUser() updateUser() openDB() closeDB() Perception & Communication Manager analysingEvent() analysingMessage() inform() reject() propose() finish() accept() forward() DML Manager
Figura 5.29 O Componente Agente Usurio
O agente usurio interage diretamente com o agente de armazenamento e disseminao, o qual tem entre as suas funes a de espalhar informao / conhecimento por toda a organizao. O agente de armazenamento e disseminao por sua vez interage com os agentes de descobrimento e de interface, que so os encarregados de capturar conhecimento relevante, o primeiro de forma automtica a partir dos repositrios que se possuem na organizao ou de fontes disponibilizadas na web, o segundo, como resultado do preenchimento de informaes via os formulrios GUI. O processo de espalhamento de conhecimento a partir do agente armazenamento e disseminao realizada como segue: primeiro, o agente usurio recebe a mensagem atravs da operao receiveMessage, a qual passada
133
operao analysingMessage, que analisa o seu contedo para tomar alguma ao, automtica ou para simples conhecimento do usurio humano.
5.5.4 O Componente Agente Descobrimento Este componente o responsvel pela extrao de informaes da camada dos arquivos fontes, tanto no inicio para comear a povoar o Organizational Baseline, como aps sua criao, na sua manuteno, para manter atualizado o conhecimento mantido nele. A caracterstica ou funcionalidade principal deste componente agente , simplesmente, ouvir mudanas nos arquivos fontes e atualizar o baseline. Para cada tipo de fonte necessrio criar uma instncia deste agente, um wrapper que capture a informao requerida contida nela com o propsito de atualizar os conceitos e atributos do baseline. Um wrapper um tipo de software denominado tambm de glueware [(Eskelin, 1999; Scheneider, 1999) em (Barbosa, 2001)], que atua junto com outros componentes de software. Embora no exista uma clara demarcao entre o que seria um wrapper simples e complexo, pode se afirmar que um wrapper complexo encapsula uma nica fonte de dados para que ela possa ser utilizada da maneira mais conveniente, enquanto um wrapper simples captura uma determinada informao do arquivo fonte e atualiza o repositrio de destino. Em particular, para o desenvolvimento de um wrapper devem ser analisadas que fontes de dados sero tratadas pelo wrapper e se estas esto bem documentadas, como tambm quais so as suas funes, como foram construdas e qual a sua estrutura interna. Uma das fontes do SCM so os sistemas legados, bancos de dados e outros arquivos prprios da organizao, como tal conhecida a estrutura interna de cada fonte e o tipo de dado de seus campos. Outro tipo de fonte que alimenta o baseline so as pginas web da internet, as quais utilizam linguagens de marcao HTML ou alguma de suas variantes. Usualmente possvel conhecer a estrutura destes arquivos, quando seu contedo no est oculto, e obter sem maior dificuldade a informao contida nela, pois basta ler os seus tags. O problema surge quando o dono da pgina web muda a sua estrutura: nesse caso necessrio que esta se anlise novamente para detectar os tags de interesse. Pode tambm ocorrer que o
134
dono da pgina web de moto prprio oculte o seu contedo: nessa situao ser materialmente impossvel l-los, pois no existiria uma soluo fatvel vivel. Outro tipo de fontes de dados so os arquivos XML (eXtended Markup Language). A linguagem XML uma linguagem para a interoperabilidade de dados, mas que tambm utilizado como uma forma de armazenamento de dados (sob a forma de documentos) e para a construo de web services. O web service qualquer servio que est disponvel sobre a internet, usa um sistema padro de mensagens XML e, no est limitado a algum sistema operacional ou linguagem de programao. Outras propriedades do web service que este deve ser autodescritivo (fornecer uma interface pblica para o servio em XML com sua documentao textual) e fcil de encontrar (deve existir um mecanismo simples para ser encontrado). Os web services podem ser centrados nos dados ou nos processos. No presente trabalho, seria suficiente a primeira opo, pois o
interesse est em capturar informao especfica para preencher o repositrio de conhecimento. Conhecendo a definio do documento XML se estaria em um caso similar aos arquivos fonte proprietrios da empresa, pois se conheceria a sua estrutura e se poderia desenvolver programas wrapper que capturem a informao requerida. No caso dos web services a descrio dos servios realizada por meio do uso da Linguagem de Descrio de Servios (Web Service Description Language WSDL) (Cerami, 2002). O WSDL faz uso da gramtica XML para a especificao da interface pblica dos servios web. Esta interface inclui informaes sobre todas as funes disponveis, tipos de dados utilizados nas mensagens XML, informaes do protocolo de transporte a ser utilizado e endereo do servio especificado. Mas tudo isso implica obviamente uma cultura que envolva e motive o compartilhamento de informaes alm da prpria organizao. Em resumo, seja qual for o tipo dos arquivos fontes acima explicados, necessrio conhecer a sua estrutura para que possa se extrair a informao procurada. O componente de Descobrimento tem duas funcionalidades especificas: o servio de descobrimento em si e o servio ouvinte de descobrimento. O descobrimento em si tem um conjunto de operaes que so detalhadas a continuao: executar a consulta na fonte de dados (executeQuery), receber os
135
dados como resultado da consulta (resultQuery), recuperar o estado atual do arquivo fonte (retrieveStateSource), recuperar o estado da consulta
(retrieveStateQuery) - se foi um sucesso ou se houve alguma dificuldade -, recuperar os metadados do arquivo fonte (retrieveMetadadosSource), abrir o arquivo fonte (openSource), fechar o arquivo fonte (closeSource), ler os dados do registro do arquivo fonte (readDataSFile) e, gravar os dados extrados do arquivo fonte no Organizational Baseline (writeDataOB). O servio ouvinte realizado por meio da operao listenerDiscover, roda de forma permanente no servidor, checando de tempo em tempo qualquer mudana que houver nos arquivos fonte, devendo disparar o processo que ative as operaes do servio de recuperao de informao, quando houver algum cmbio.
Storing& Dissemination Agent Agent beliefList goalList planList setBelief() addBelief() setGoal() addGoal() setPlan() addPlan() Domain Layer Resource Layer Wrapper Source A Wrapper Source B Wrapper Source C
Discovering Agent
Domain Manager dataChecking() executeQuery() resultQuery()
Resource Manager retrieveStateQuery() retrieveStateSource() retrieveMetadadosSource() sendMessage() showMessage() receiveMessage() readSource() openSource() closeSource() writeDataOB() Perception & Communication Manager analysingEvent() analysingMessage() inform() reject() propose() finish() accept() forward() DML Manager
makingDecision() creation() destruction() monitoring() listenerDiscover()
Figura 5.30 O Componente Agente de Descobrimento
O wrapper deve ser instanciado dependendo do tipo do arquivo fonte e a sua forma de comunicao. Nesse sentido, para cada tipo de fonte de dados a ser integrada no Organizational Baseline do SCM, deve haver um wrapper especfico, o qual utilize os metadados da fonte. Na Figura 5.30 mostra-se o componente Descobrimento de acesso aos dados fonte, baseado no trabalho de Barbosa (2001).
136
5.5.5 O Componente Agente Busca Os repositrios principais do SCM so o Organizational Baseline e o de Lies Aprendidas (Base de Casos de Experincias). Com o intuito de delimitar o processo de busca em ambos repositrios, decidiu-se que a busca no repositrio de casos seja tratado em forma separada, isto pela sua prpria caracterstica: buscar uma soluo para um determinado problema, vide detalhes na seo 5.5.7. Delimitado o escopo deste componente, o mesmo estar centrado exclusivamente na recuperao de informaes do Organizational Baseline, definiu-se duas alternativas de busca: uma primeira de navegao, utilizando para isso a rvore da ontologia do negcio e uma segunda, de busca por termos no baseline, utilizandose como um meio de busca os conceitos da ontologia. A opo de navegao envolve a realizao de um mapeamento de todos os conceitos da ontologia para o Organizational Baseline. Ressalta-se que cada elemento da ontologia tem um conjunto de termos relacionados os quais sero utilizados tanto no processo de extrao via a opo de navegao como de busca por termos. A ontologia tambm contm a nvel interno uma lista de sinnimos apontando aos conceitos base, porm estes sinnimos no aparecem na rvore de navegao. Nesse sentido, quando um usurio clicar sobre o link de um conceito, o SCM deve mostrar uma tela com os itens mais relevantes, em ordem de importncia, sendo o primeiro deles o conceito solicitado e os subseqentes os termos relacionados, eventualmente o usurio pode desejar estender seu conhecimento clicando sobre estes ltimos. A opo de busca por termos implica o uso de heursticas de similaridade, assim, por exemplo, se o usurio coloca a palavra empresarial e esta no existe como uma entidade no Organizational Baseline, o sistema deve ser capaz de mostrar ao usurio que o conceito mais perto deste empresa. Maior complexidade pode se apresentar quando o usurio coloca duas ou mais palavras ou conceitos a procurar, a dever de estabelecer-se heursticas apropriadas, como, por exemplo, o tratamento de conetivos lgicos, sinnimos, termos relacionados, similaridade, entre outros. de maneira tal que a operao de busca possa ter um maior leque de possibilidades de sucesso.
137
As operaes que este componente deve ter so basicamente as seguintes: createTreeOntology, cria o formulrio onde se mostra as opes de navegao na ontologia e, retrieveFormSearch que faz a busca no Organizational Baseline. O createTreeOntology, mostra a rvore da ontologia, lembrando que esta foi desenvolvida baseada em teorias da estratgia de negcios, sob uma abordagem top-down. Quando o usurio clicar sobre o link de algum termo da ontologia o SCM deve mostrar o contedo desse termo (operao showConcept), assim como os links dos termos relacionados (operao showLinks), quando clicar encima de algum termo relacionado se utiliza novamente a operao showConcept. Para o caso de busca utiliza-se a operao searchConcept, a qual fornece um conjunto de links com os termos que melhor satisfazem a consulta. Logo o usurio pode selecionar aqueles que ele achar melhor atingem a sua busca. O searchConcept utiliza para o processo de busca uma ou mais heursticas, como podem ser a estratgia de sinnimos, termos relacionados ou de sintaxe junto estratgia de similaridade dos termos. Existem inmeras formas para encontrar a similaridade, sendo um tpico de amplo estudo nos ltimos tempos pelo surgimento da internet. Na Figura 5.31 mostra-se as principais operaes deste componente.
UserAgent Agent beliefList goalList planList setBelief() addBelief() setGoal() addGoal() setPlan() addPlan() Domain Layer Resource Layer
Navigation Search Services Concept Search
Search Agent
Domain Manager searchConcept() getConcept() createTreeOntology()
Resource Manager retrieveFormSearch() retrieveTreeOntology() retrieveMetadadosSource() sendMessage() receiveMessage() showConcept() showLinks() readConcept() openOB(), openOntology() closeOB(), closeOntology() writeDataOB() Perception & Communication Manager analysingEvent() analysingMessage() inform() reject() propose() finish() accept() forward() DML Manager
Figura 5.31 O Componente Agente de Busca
138
5.5.6 O Componente Agente Armazenamento e Disseminao do LOG Este componente agente o encarregado e responsvel por armazenar, gerenciar e viabilizar o acesso s metainformaes dos dados que foram agregados e/ou atualizados no Organizational Baseline, bem como pela disseminao desse novo conhecimento aos usurios envolvidos. Cada uma das fontes de dados no momento de atualizar o baseline cria um registro log por meio deste agente, o caso do agente interface como visto na seo 5.5.2 um exemplo. Quando o baseline atualizado a partir de um formulrio, o log registra as entidades (conceitos) e atributos que tenham mudado. Notar que os atributos de um conceito no baseline podem ser resultado da integrao de vrias fontes de dados, portanto, quando alguma dessas fontes sofre alguma mudana, os agentes de descobrimento (ouvintes) devero atualizar os atributos correspondentes do conceito no baseline. Outra situao que pode se apresentar quando um atributo o resultado de duas ou mais outras fontes, aqui tambm se est em frente de um problema de integrao, geralmente de sumarizao de dados numricos. O tratamento deste tipo de problemas exige o mapeamento de todas essas fontes e que o agente de descobrimento tenha a capacidade de integrar o resultado final para logo atualizar o baseline. A Figura 5.9, apresentada na seo 5.3.1, mostrou em um alto nvel que quando um determinado conceito atualizado, gera-se um registro log desse conceito e de seus atributos que mudaram, o detalhe do mesmo foi mostrado na seo 5.5.2. A estrutura do registro log, vide Tabela 5.8, como segue:
Atributos Cdigo do Log MetadadosConceito Indicador de Leitura Tabela 5.8 Estrutura do Registro log Tipo de dados Numrico (seqencial) String (Mime) Numrico (0..1)
Sabe-se que cada fonte de dados possui seus prprios metadados, assim, o atributo MetadadosConceito estruturado como do tipo String, sendo o seu contedo formado pelo nome do conceito (entidade ou nome da tabela) seguido dos atributos que mudaram. Em geral, o atributo MetadadosConceito tem a seguinte estrutura:
139
(*nome_conceito* + (?nome_atributo?)1..n) 1..n
Para cada conceito existe um ou mais atributos que podem ter mudado, o nome do conceito tem como delimitador o smbolo *, antes e depois do conceito, o nome do atributo que mudou tem como delimitador o smbolo ?, tambm antes e depois do mesmo. Em vista que o Organizational Baseline pode ter diferentes tipos de fontes de dados, no exemplo a seguir se tratar o caso quando este atualizado a partir do formulrio do conceito Companhia (agente interface) o qual tm como atributos Nome da companhia, Empresa Matriz, Misso, Viso, entre outros. Suponha-se que os atributos Misso e Viso tenham mudado, ento o registro log desta mudana havida no Organizational Baseline como segue:
25*Companhia*?Misso??Viso?0
onde o nmero 25 representa o cdigo seqencial do registro log e o zero no final significa que este ainda no foi processado. O cdigo seqencial incrementado automaticamente em uma unidade cada vez que um novo registro adicionado no arquivo LOG. O indicador de leitura zero (0) quando criado (ainda no processado) e um (1) depois de ter sido processado pelo componente, o agente de armazenamento e disseminao.
Agent beliefList goalList planList setBelief() addBelief() setGoal() addGoal() setPlan() addPlan() Domain Layer Discovering Agent InterfaceAgent
Storing
Dissemination Storing& Dissemination Agent Services
Resource Layer
Resource Manager Domain Manager processingMetadataLog() getLog() addLog() deleteLog() readLog() updateConditionLog() updateSequenceNumber() sendMessage() receiveMessage() getUser() Perception & Communication Manager analysingChange() listeningRegLog() analysingEvent(0 analysingMessage() DML Manager makingDecision() creation() destruction() monitoring() listeningChange() captureEvent()
Figura 5.32 O Componente Agente Armazenamento e Disseminao
Na Figura 5.32 observa-se as principais operaes ou servios do agente armazenamento e disseminao. A seguir explica-se o funcionamento deste agente para o caso do armazenamento no arquivo LOG, logo se faz o mesmo para o caso
140
de disseminao. Na primeira situao, suponha-se que se recebe a comunicao (mensagem) do agente interface, podendo tambm ser do agente descobrimento, por meio da operao receiveMessage do RL, o qual encaminha o contedo da mesma ao PCL que o analisa por meio da operao analysingMessage, retornando-o logo ao RL que atualiza o LOG utilizando a operao addLog (agregar registro log). Na segunda situao, o agente de armazenamento e disseminao atravs da operao thread listeniungChange do DML ouve que novos registros log tm sido adicionados ao arquivo LOG do SCM, dizer que o baseline da memria corporativa tem sido atualizado com novas informaes, comunicando esse evento ao PCL, o qual o analisa, via a operao analysingChange, para verificar se verdadeiramente novos registros tm sido adicionados. Aps isso, comunica-se com o DL e l os registros do LOG utilizando a operao getLog, o qual por sua vez utiliza a operao readLog do RL. A atualizao do indicador de leitura do registro lido realizado pela operao updateConditionLog. O processamento do contedo dos metadados do Log faz-se via a operao processingMetadataLog do DL, extraindo-se o conceito e os atributos que mudaram. A seguir, procura-se atravs do getUser do RL, aqueles usurios para os quais essas mudanas tm um efeito relevante, finalmente, envia-se uma mensagem aos usurios via a operao
sendMessage do RL.
5.5.7 O Componente Agente Armazenamento de Lies Aprendidas
Como resultado da turbulncia na qual tm que atuar as organizaes, como dito na introduo do presente trabalho, tem-se salientado a importncia do know
how como um ativo organizacional, o mesmo que necessita ser gerenciado com o
intuito de que a organizao obtenha uma vantagem competitiva sustentvel. Uma forma de representar o know-how, tambm chamado de ativos do conhecimento, por meio das lies aprendidas (experincias passadas relevantes, aplicao de determinados procedimentos ou tcnicas), modelos especficos (de qualidade, distribuio de carga de trabalho, custos, segmentao de mercado) ou
documentos corporativos (planos de marketing, produo, qualidade). Estes so
141
armazenados na base de casos do know-how, a qual na arquitetura do SCM um repositrio independente do Organizational Baseline. As lies aprendidas so, basicamente, experincias relevantes que aconteceram no passado e que por sua relevncia so armazenadas para o seu posterior reuso. Assim, no so armazenadas todas as experincias, seno s aquelas que aps uma anlise profunda, feitas pelo pessoal das reas envolvidas, considera-se que constituem uma experincia digna de se manter, da tambm a denominao de boas prticas. Exige-se que estas, sempre que possvel, sejam validadas. As lies aprendidas podem incluir tambm experincias mal sucedidas que mostrem erros que aconteceram no passado sob determinadas situaes e que se espera no devam se repetir no futuro. Definido aquilo que deve se armazenar com relao ao know how corporativo, o passo seguinte operacionalizar a recuperao e disseminao dessas experincias, para o qual utiliza-se a abordagem do raciocnio baseado em casos (Case-Based Reasoning CBR), a qual em anos recentes tem sido considerada como uma tcnica adequada para suportar o desenvolvimento de sistemas de aprendizado baseados em conhecimento (Althoff et al., 1998). No entanto, prvio ao problema de recuperao e disseminao existe a questo da identificao e modelagem das experincias a serem armazenadas no repositrio de casos do SCM. O que resta desta seo est baseado no trabalho de Wangeheim & Rodriguez (2000) para o domnio de Engenharia de Software, o mesmo que foi adaptado aqui para o domnio da estratgia de negcios. O algoritmo de recuperao utilizado apresentado em detalhe na seo 4.9.
5.5.7.1 Estruturando a Base de Experincias
Um dos pontos crticos quando se utiliza o raciocnio baseado em casos a estruturao das experincias, existindo dois problemas: primeiro a
contextualizao do caso com o intuito de facilitar a sua recuperao e, segundo o caso em si mesmo. A contextualizao ir depender do domnio especifico que est se tratando, devendo se definir um conjunto de atributos ou caractersticas que coadjuvem identificao mais exata da experincia. O caso poderia se estruturar da seguinte forma:
142
Contexto: Conjunto de atributos que melhor caracterizem o problema Problema: Definio do problema-caso Causa: Explicao das possveis causas do problema Soluo: Explicao das possveis solues ao problema definido Resultados: Descrio dos resultados da soluo proposta
Usualmente toda empresa de porte tem um manual de procedimentos para as situaes tpicas que acontecem no dia-a-dia, onde se descreve os passos necessrios para trat-as. No entanto, a empresa e o seu entorno no so estticos mas bem dinmicos, o que implica que podem aparecer novas situaes, chamadas de atpicas, para as quais no existe um procedimento predeterminado. Nessas situaes, o pessoal envolvido necessita de algumas sugestes que o ajudem a resolv-las ou a trat-las da melhor forma. Porm, muitas vezes esse tipo de problema pode ter sido resolvido em outras reas da empresa, no mesmo local ou, provavelmente, em qualquer outro local da organizao. A onde surge a importncia de contar com um repositrio de casos, que armazene experincias relevantes, para no dedicar esforos em resolver novamente um problema que pode ter sido antes tratado ou resolvido com sucesso.
Crditos e Cobranas Avaliao Pessoa Fsica 4000 reais Inadimplencia O cliente C001 no tem pago as suas contas desde h 3 meses, ele no tem avalista pois estava catalogado como um cliente especial Tabela 5.9 Exemplo de um problema e seu contexto Departamento Seo Tipo de Cliente Quantia do crdito Tipo de problema Problema
A seguir mostra-se um exemplo, seja o Departamento de Crditos e Cobranas da empresa ABC: o problema detectado que o cliente C001 recebeu um crdito da empresa, mas aps um certo perodo de tempo este deixou de pagar as parcelas pendentes, tendo ficado como inadimplente por mais de 3 meses. O cliente argumenta que foi demitido do servio e que est impossibilitado de honrar seus pagamentos. Sabe-se tambm que este um antigo cliente e que nunca tinha tido problemas de pagamento antes. Na Tabela 5.9 mostra-se o problema e seu contexto, na Tabela 5.10 a base de casos e o problema a resolver (situao presente) e na Tabela 5.11 o caso soluo para esse problema.
143
Atributos Contexto Departamento Seo Tipo cliente Quantia credito Local do
Relevncia Situao Presente

Alta Muito importante Importante Pouco importante Irrelevante Muito importante
CASO CC03
Base de Casos CASO CASO CC05 C007
Credito e Crdito e Crdito e Crdito e Cobranas Cobranas Cobranas Cobranas Avaliao Avaliao Aprovao Avaliao Pessoa fsica 4000 Pessoa fsica 5000 Pessoa fsica 1000 Belo Horizonte 60 Pessoa jurdica 3000 Porto Alegre 120
Morosidade Problema Causa Soluo Resultado
Rio de So Paulo Janeiro 90 dias 90
Tabela 5.10 A Base de Casos, seus atributos e relevncia dado o problema
Departamento Seo Tipo de Cliente Caso Recuperado Monto do crdito Tipo de problema Problema Causa Soluo Resultado
Crditos e Cobranas Avaliao Pessoa Fsica CC03 5000 reais Morosidade O cliente no tem pago as suas contas desde h 4 meses, ele no tem avalista pois estava catalogado como um cliente especial O cliente foi demitido sem causa justa, o que lhe impossibilitou cumprir com as suas obrigaes. Ampliou-se o prazo de pagamento ao cliente at 12 meses, com parcelas menores. Ao termino dos 12 meses o cliente cumpriu com o pagamento que tinha com a empresa.
Tabela 5.11 Recuperao de um caso dado um problema
5.5.7.2 Operaes do Componente Agente de Lies Aprendidas
As operaes bsicas que so necessrias para o adequado funcionamento deste componente so: recuperao do formulrio do caso (retrieveFormCase), agregar um novo caso (addCase), modificar um caso existente (modifyCase),
144
eliminar um caso (elimineCase), mostrar um caso (showCase), e busca de casos

(searchCase).
Na Figura 5.33 mostra-se todas as operaes deste componente. Percebe-se que a operao mais importante o searchCase porque este o que permite a recuperao dos casos mais relevantes que possam ajudar resoluo ou tratamento do problema em agenda. Est operao utiliza o algoritmo apresentado na seo 4.9.
Agent beliefList goalList planList setBelief() addBelief() setGoal() addGoal() setPlan() addPlan() Domain Layer Resource Layer
CaseBase Agent
Domain Manager dataCheckingCase() addCase() modifyCase() elimineCase() getCase() searchCase()
Resource Manager retrieveFormCase() showCase() sendMessage() receiveMessage() readCase() writeCase() updateCase() openCase() closeCase() Perception & Communication Manager analysingEvent() analysingMessage() inform() reject() propose() finish() accept() forward()
DML Manager
Figura 5.33 O Componente Agente da Base de Casos
6 Apresentao do Prottipo
Com o objetivo de mostrar, na prtica, as caractersticas da proposta arquitetural do SCM desenvolveu-se o prottipo apresentado neste captulo. A implementao, embora parcial pelo fato de ser um prottipo, abrange as funcionalidades bsicas do SCM, os seus servios de busca e disseminao
automtica. Nas sees 5.4.2 e 5.4.3 esto apresentados esses servios bsicos do
SCM. O desenvolvimento do prottipo envolveu a programao dos componentes Busca, Interface e Armazenamento e Disseminao, cujos detalhes arquiteturais foram apresentados nas sees 5.5.2, 5.5.3, e 5.5.6. Optou-se pelo
desenvolvimento destes componentes somente para tornar visvel os principais servios do SCM. O prottipo do SCM, como qualquer aplicao, necessita de dados que ajudem a mostrar a aplicabilidade da proposta. Sendo assim, adaptou-se um estudo de caso relatado no livro Imagens of Organizations de Morgan (1996), o caso da empresa Multicom, de onde foram extrados os dados para a validao da proposta da memria corporativa. Ressalta-se que esses dados ajudaram de sobremaneira na apresentao dos servios e das caractersticas bsicas do SCM. Destaca-se, tambm, que o propsito do presente captulo no apresentar o diagnostico organizacional nem mesmo desenvolver alguma estratgia para a Multicom, como o objetivo do estudo de caso na sua forma original. O propsito explicitar, atravs do uso do prottipo do SCM, como este poderia ser utilizada no processo de Gesto do Conhecimento, tanto pelos consultores como pelos funcionrios e executivos da Multicom. Na seo 6.1 descreve-se o estudo de caso de forma sucinta, com o propsito de que o leitor possa compreender melhor o mbito da empresa, bem como os termos e descries a serem utilizadas na demonstrao do prottipo.
146
6.1 O Caso da Empresa Multicom
A Multicom uma pequena empresa que desenvolve as suas atividades na rea de Relaes Pblicas, empregando 150 pessoas. Iniciou as suas operaes h 7 anos com Jim Walsh, especialista em Marketing, e Wendy Bridges, com ampla experincia na rea de relaes pblicas, cada um deles com 40% das aes (participaes), ambos tinham na poca 34 e 33 anos respectivamente. Juntos haviam trabalhado por vrios anos em uma empresa de comunicaes de mdio porte. Antes de se demitirem convenceram dois outros colegas, Marie Beaumont, produtora de filmes e vdeos, e Frank Rossi, redator e autor de excelente reputao, para se unirem a eles como acionistas minoritrios (ambos com 10% das aes). Estes ltimos tinham no inicio das operaes da empresa 23 e 24 anos respectivamente. A Multicom tinha um modelo de organizao orientado ao cliente (cada cliente era um projeto). Entretanto, h quatro anos as coisas comearam a mudar, Walsh e Bridges decidiram estruturar melhor a companhia. Inicialmente, Beaumont and Rossi no aprovaram as mudanas, porm, decidiram continuar na companhia, enquanto os funcionrios comentavam que a Multicom estava perdendo as suas caractersticas especiais de ter um ambiente motivador de trabalho. H dois anos, Beaumont and Rossi decidiram criar uma nova companhia, a Media 2000, levando com eles alguns clientes e funcionrios. Gradualmente a Multicom comeou a perder a sua imagem de uma companhia lder no mercado, enquanto a Media 2000 rapidamente se consolidava como uma agncia capaz e inovadora. Desde que Beaumont and Rossi saram, os resultados financeiros da Multicom diminuram fortemente, sendo o clima organizacional afetado seriamente. Perante esses fatos, Walsh and Bridges decidiram contratar uma firma de consultoria para fazer um diagnstico organizacional e propor uma nova estratgia para a Multicom.
6.2 Os servios do SCM
Usualmente quando se realiza um trabalho de consultoria de negcios como o requerido pela Multicom, o primeiro passo fazer um levantamento de
147
informaes que facilite o conhecimento da organizao como um todo, pois, embora as firmas de consultoria tenham experincia nesse tipo de atividades e muitas vezes no setor onde a empresa cliente atua, sabem que sempre existem particularidades inerentes empresa sob anlise. Essas particularidades exigem que os consultores faam esse levantamento antes de comearem as entrevistas com os executivos e funcionrios da organizao, cuja disponibilidade de tempo exgua e valiosa no atendimento de suas atividades. nesse ambiente de trabalho que os consultores utilizaro o SCM, levando a um uso racional de seu prprio tempo e de seus clientes. A seguir lista-se algumas perguntas usuais que todo consultor realiza, bem como as localizaes das possveis respostas para estas no repositrio do conhecimento: a) Que tipo de estrutura a Multicom possui? Esta informao encontrada nos itens Estrutura Organizacional e Forma de Governo da entidade Companhia. b) Qual o tipo de ambiente organizacional? A resposta encontrada nos atributos Estilo de Liderana e Cultura Corporativa, das entidades Companhia e Negcio. c) A Multicom possui um nicho de mercado? A resposta a esta questo pode ser encontrada na entidade Companhia (atributos Mercado e Setor
de Atuao). Tambm so relevantes as entidades Objetivos Estratgicos
e Fatores Crticos. d) Qual a atual estratgia da Multicom? Esta questo pode ser atendida pela entidade Companhia (atributos Misso, Viso). Tambm pelas entidade Objetivos Estratgicos.
Com isso mostra-se, intuitivamente, que a modelagem do modelo do negcio e a sua representao no Organizational Baseline, respondem s questes propostas no estudo de caso. Todas essas questes, antes citadas, so satisfeitas pelo prottipo. O propsito em desenvolver o prottipo do SCM, como definido ao inicio desde captulo, foi mostrar os servios de busca e disseminao automtica, funcionalidades chave em todo processo de gesto do conhecimento. O passo
148
seguinte foi escolher o ambiente de desenvolvimento e as tecnologias a serem utilizadas. Visando sua execuo em um ambiente de rede na internet, primeiro, instalou-se um servidor de aplicaes, o Tomcat, o qual um software livre e amplamente utilizado no meio acadmico. Logo, das diversas alternativas que existem para o desenvolvimento de aplicaes na internet, tais como o JSP, ASP, APPLET e SERVLET, selecionou-se a alternativa do SERVLET porque esta uma tecnologia relativamente madura, alm de bastante difundida tanto no meio acadmico como na indstria. Para suportar os arquivos que armazenem as informaes e conhecimentos organizacionais utilizou-se o gerenciador de banco de dados MS-Access. Estabelecida a plataforma onde se desenvolver o prottipo, a atividade seguinte foi definir os repositrios necessrios a serem utilizados, vide seo 5.3.3 da camada de repositrios. Nesta tarefa utilizou-se o conhecimento adquirido na fase de anlise do domnio, quando se estruturou a ontologia do negcio. Assim, criou-se os repositrios do Organizational Baseline, Usurios (Users) e Ontologia (Ontology), preenchendo-se o primeiro com dados da Multicom, o segundo com dados dos consultores e dos funcionrios da Multicom, e o terceiro com dados da ontologia empresarial. Todos esses repositrios, implementados em tabelas do MS-Access, so explicadas nas sees seguintes. Adicionalmente criou-se, em tempo de execuo, o repositrio do arquivo LOG (Upgrading Organizational Baseline), onde armazena-se as transaes que motivaram atualizaes no Organizational Baseline.
6.2.1 Descrio do Prottipo: O Servio de Busca
Na Figura 6.1, apresenta-se a estratgia do processo de busca para uma das questes anteriormente citadas: Que tipo de estrutura a Multicom possui? Percebe-se que o consultor (usurio) necessita dar como entrada a palavra chave estrutura que est sublinhada. Logo, o SCM, por meio do componente Busca, procura no repositrio de dados da memria corporativa, o Organizational Baseline, as informaes mais relevantes, as quais so extradas e em seguida entregues ao usurio.
149
O processo todo se d da seguinte forma: primeiro, o agente de busca acessa o repositrio da ontologia do negcio (no mostrado na Figura 6.1), o qual fornece o ponteiro ou ponteiros (output vector), em seguida esse(s) ponteiro(s) (so) utilizado(s) para ler o baseline organizacional, de onde se extrai a informao solicitada pelo consultor. No exemplo, o conceito Estrutura Organizacional da entidade Companhia do Organizational Baseline satisfaz a questo colocada. Ressalta-se que na etapa da modelagem do domnio existiu a preocupao de se mapear os termos da ontologia ao Organizational Baseline.
Figura 6.1 Uso do SCM
A Figura 6.2 mostra a estrutura da Ontologia dos conceitos do negcio. Este possui os seguintes atributos:
ConceitoNome: Nome do conceito. ConceitoDescrio: Descrio do conceito. ConceitoNivel: Os nveis do conceito podem ser 1 Entidade , 2
Atributo, 3 Faceta e 4 Intermedirio. O nvel intermedirio significa que o conceito pertence hierarquia mas no uma entidade, atributo ou faceta. O nvel intermedirio um conceito que contm outro conceito intermedirio ou uma entidade.
ConceitoSinonimo: Rene os ponteiros a todos aqueles conceitos que so
sinnimos do conceito principal.

ConceitoTipo: Pode ser 1 Principal, quando o conceito faz parte da
hierarquia de conceitos; 2 Sinnimo,
quando um termo com o
mesmo significado que algum conceito da hierarquia, em particular pode ser um nome de tabela ou de atributo.
150
ConceitoUsuarios: Contm os ponteiros a todos aqueles usurios para os
quais o conceito relevante para apoio na sua tomada de decises.
Figura 6.2 Estrutura do repositrio Ontologia do negcio
Figura 6.3 Instncias da Ontologia do negcio
A Figura 6.3 mostra seis instncias da ontologia, os conceitos Companhia, o qual do nvel Entidade; Empresa, que um sinnimo de Companhia e do nvel Intermedirio; Misso e Viso, que so do nvel Atributo e; os termos EmpMissao e EmpVisao, que so tratados tambm como sinnimos. Observa-se que o conceito Companhia tem todos os campos preenchidos, pois trata-se do tipo Principal; o conceito Empresa, que um sinnimo, tem somente os campos
ConceitoCodigo, ConceitoNome, ConceitoNivel, ConceitoTipo
ConceitoPrincipal preenchidos. Os conceitos Misso e Viso so casos similares
ao conceito Companhia, exceto que so do nvel Atributo. Nota-se que os conceitos que so sinnimos por definio no tm todos os seus campos preenchidos, somente aqueles que lhe permitam ser identificados, mas devem necessariamente estar vinculados a um conceito principal, o qual sim possui todos
151
os seus campos de dados preenchidos. do conceito principal de onde, quando requerido, so extradas as informaes (conceitos relacionados, usurios, tipo, email) a serem utilizadas nos processos de busca e de disseminao.
Figura 6.4 O servio de Busca
A Figura 6.4 mostra a tela principal do componente agente Busca do prottipo, vide detalhes na seo 5.5.5. Na parte superior o usurio entra com o(s) termo(s) a ser(em) procurado(s) no Organizational Baseline. Nota-se que o usurio tm duas opes de busca: Pesquisar no Baseline Organizacional e
Pesquisar na Base de Casos, o prottipo implementa a primeira opo. Na parte
inferior apresenta-se os resultados decorrentes dessa extrao. No exemplo apresentado, o usurio entra com o termo estru e obtm-se como resultado o Conceito Principal Estrutura Organizacional e o Conceito Relacionado Forma de
152
Governo. Abaixo de cada conceito mostra-se o contedo destes. Dessa forma foi
mostrado o servio de busca. Este servio tambm denominado de disseminao requerida, porque o mesmo realizado por solicitao do usurio, no exemplo, um consultor de negcios. Internamente, o processo de procura no componente de busca como segue primeiro, vide Figura 5.31, o servlet do agente recupera o formulrio de busca do servidor, utilizando a operao retriveFormSearch(). O prottipo no implementa na presente verso as operaes retrieveTreeOntology(), showLinks(), sendo assim, mostra de forma direta os conceitos encontrados no repositrio principal da base de conhecimento. O servio de busca em si realizada pela operao
searchConcept(), a qual primeiro acessa o repositrio da ontologia do negcio,
operaes getConcept() e readConcept(), de onde extrai o conceito principal que melhor satisfaz a busca requerida tanto como os conceitos relacionados e os metadados para acessar o Organizational Baseline, operao
retrieveMetadadosSource(). Esses metadados so, logo, utilizados na recuperao
do conhecimento do baseline organizacional. Como dito na seo 5.5.5, existem inmeras heursticas para casamento de termos, como por exemplo o uso de critrios de similaridade e de sinnimos. No prottipo implementou-se uma verso da estratgia de similaridade, a qual tem como entrada uma cadeia de caracteres. Aps a sua entrada o sistema procura que conceitos tem essa cadeia como parte do nome do conceito na ontologia. Tambm utilizou-se a estratgia de sinnimos, onde cada conceito da ontologia possui um conjunto de conceitos sinnimos os quais apontam a um conceito principal, e este por sua vez, aponta a um conjunto de termos relacionados. Destaca-se que, dada a difuso da internet, a rea de recuperao de conhecimento na atualidade uma linha de ampla pesquisa. Futuras verses do prottipo devem implementar outras heursticas.
6.2.2 Descrio do Prottipo: O Servio de Disseminao
Outra das funcionalidades do SCM o servio de Disseminao automtica. Ressalta-se que o processo de disseminao exige que previamente se realize o processo de armazenamento e de atualizao do Organizational Baseline. As
153
fontes de dados do Organizational Baseline, como dito na seo 5.3.1, podem ser das mais diferentes classes e tipos, includas as informaes provenientes de sites da web e o conhecimento de posse pelos membros da organizao. No entanto, salienta-se que o propsito do prottipo no mostrar as diversas formas de como o baseline preenchido ou atualizado, e sim o processo de disseminao em si. Acredita-se que para atingir esse objetivo adequado o uso de formulrios que capturem informaes e conhecimentos. Os formulrios so uma forma simples de entrada de dados, assim, estes foram utilizados para atualizar o repositrio do baseline organizacional. No prottipo os formulrios foram instanciados a partir do componente Interface, vide na seo 5.5.2 a Figura 5.28. Deste componente foram implementados as operaes retrieveForGUI(), readEntity(), writeEntity(),
updateEntity() entre outras.
Figura 6.5 Formulrio da Entidade Companhia (Interface)
154
A Figura 6.5 apresenta o formulrio do conceito Companhia (Empresa). O conceito Companhia representado no Organizational Baseline como uma tabela. Na figura mostra-se alguns dos seus principais atributos, tais como: nome, descrio, matriz, estrutura organizacional, estilo de liderana, entre outros. Percebe-se que os conceitos (atributos) Estrutura Organizacional e Estilo de
Liderana, mostram, tambm, as suas facetas. Assim, o primeiro tem os valores: Funcional, Divisional, Matricial, Por Processos, Simples e, Ad Hoc; o segundo
tem os valores: Impeditiva, Negociadora, Competitiva, Acomodativa e

Colaborativa. Adicionalmente esses dois conceitos possuem o campo Descrio,
onde se descreve a evoluo do seu contedo no tempo. Outros conceitos que fazem parte da conceito Companhia no so mostrados na figura por limitaes de espao. Aps preencher os dados do formulrio, o usurio encaminha os mesmos ao servidor de aplicaes, atravs do servlet do componente agente Interface, atualizando, assim, o repositrio do Organizational Baseline. O servidor logo retorna ao usurio uma tela com a mensagem Dados Includos com Sucesso, vide Figura 6.6.
Figura 6.6 Tela de Confirmao dos Dados Ingressados
Como decorrncia da atualizao do baseline do SCM criou-se, em forma paralela, um registro no repositrio LOG do sistema, o qual armazena as mudanas que ocorreram no Organizational Baseline. A criao destes registros realizada pelo componente agente de Armazenamento e Disseminao atendendo a solicitao do componente Interface. Vide detalhes nas sees 5.5.2 e 5.5.6. A Figura 6.7 apresenta os diferentes atributos do arquivo LOG, os quais so:
LogCodigo (Cdigo do Log), LogMudanca (cadeia de caracteres que contm as
155
mudanas que aconteceram no Organizational Baseline) e LogLido (indicador que mostra se o registro log j foi processado). Neste estudo de caso, mudou-se os conceitos Misso e Viso do conceito Companhia. Essa modificao reflete-se como uma transao no arquivo LOG e exibida na Figura 6.8, na terceira linha, onde o LogCodigo a igual a 3. O campo LogMudanca mostra o nome da entidade (conceito) e dos atributos que mudaram, bem como os delimitadores utilizados, * para a entidade e ? para os atributos.
Figura 6.7 Registros log do SCM
Figura 6.8 Estrutura do Arquivo LOG
O processo de disseminao exige a existncia do repositrio Usurio, onde se armazena os diferentes usurios do SCM. O gerenciamento deste repositrio realizado pelo componente agente Usurio, vide na seo 5.5.3 detalhes do mesmo. O arquivo Usurio inclui campos com dados referentes ao tipo de informaes e conhecimentos relevantes ao usurio e o seu endereo eletrnico. A Figura 6.9 apresenta a tabela deste repositrio e todos os seus atributos:
UsuarioCodigo (cdigo do usurio), UsuarioNome (nome do usurio), UsuarioConceitos (cadeia de caracteres que contm as entidades e atributos
relevantes a cada usurio), UsuarioCargo (cargo do usurio) e UsuarioEmail (correio electrnico do usurio). O atributo UsuarioConceitos possui uma
156
estrutura similar ao atributo LogMudanca do arquivo LOG, pois usa os mesmos delimitadores, * para entidades e ? para atributos. No estudo de caso utilizou-se duas instncias de usurio, vide Figura 6.10, o primeiro, Sergio Cortes com o cargo de Consultor e correio eletrnico scortes@inf.puc-rio.br; o segundo, Fausto Maranhao com o cargo de Gerente de TI (Gerente de Tecnologias da Informao) e correio eletrnico fausto@inf.puc-rio.br.
Figura 6.9 Estrutura da Tabela Usurio
Figura 6.10 Instncias de Usurio
Definidos os registros dos repositrios LOG e Usurio, restaria apenas a definio do arquivo Ontologia para realizar o processo de disseminao, mas este j foi definido na seo 6.2.2 quando descrito o servio de Busca no prottipo. O passo seguinte explicar o processo de disseminao em si. O componente agente de Armazenamento e Disseminao, vide Figura 5.32, por meio da operao listeningChange(), a qual est executando em background, ir ler do arquivo LOG o(s) registro(s) log que reflete(m) as mudanas que aconteceram no Organizational Baseline, operao processingMetadataLog(), extraindo os conceitos que mudaram. Em seguida, busca-se se o conceito (termo) existe na ontologia. Caso exista, extra-se os usurios, operao getUser(), para os quais a informao modificada relevante. Aps obter toda essa informao o
157
agente de Armazenamento e Disseminao prepara um e-mail e o envia a todos os usurios antes selecionados, operao sendMessage(), comunicando-lhes a(s) mudana(s) havida(s). Na Figura 6.11 mostra-se o e-mail recebido pelo usurio consultor Sergio Cortes e na figura 6.12 o e-mail recebido pelo Gerente de TI Fausto Maranho. Dessa forma, tem-se mostrado todo o processo de disseminao de informao e conhecimento, passo a passo. Destaca-se, mais uma vez, que a apresentao do prottipo teve como propsito mostrar que a proposta arquitetural do SCM factvel de ser implementada. Ao mesmo tempo enfatiza-se que embora os dados utilizados tenham sido extrados de um estudo de caso acadmico, os mesmos ajudaram a mostrar a bondade da proposta do SCM.
Figura 6.11 e-Mail recebido pelo Consultor Srgio Cortes
Figura 6.12 e-Mail recebido pelo Gerente de TI Fausto Maranho
7 Concluses, Contribuies e Trabalhos Futuros
Este capitulo apresenta as consideraes finais sobre o trabalho, suas principais contribuies e trabalhos que podem dar continuidade a esta pesquisa.
7.1 Concluses
O fato de vivermos em uma sociedade denominada da informao e do conhecimento, como resultado da revoluo tecnolgica e das comunicaes, exige uma cultura que motive o compartilhamento e a disseminao do conhecimento. Ao mesmo tempo, o rpido fluxo das informaes faz com que o ambiente atual esteja caracterizado pela mudana contnua. Essa mudana contnua fator motivador para que as organizaes evoluam rapidamente para acompanhar essa evoluo. Essa problemtica levou, nos anos 90, a empresas de grande porte, tais como Xerox, Ford, Buckman Labs, Texas Instruments, Hoffman-La Roche e Honeywell, a usar o conhecimento de seus funcionrios para aprimorar a sua tomada de decises. Esse conhecimento armazenado em repositrios de boas prticas ou de lies aprendidas. No entanto, tais esforos tm estado orientados, basicamente, ao conhecimento operacional e de processos. No campo acadmico, diversos autores, entre eles: Tsang (1997), Walsh & Ungson (1999), Xu et al. (2003), ressaltam a importncia de uma memria organizacional como fonte de conhecimento e aprendizado (Simon, 1991). Portanto, crtico estabelecer repositrios de conhecimento que ajudem s organizaes a suportar sua tomada de decises. Estes repositrios devem conter tanto informaes de natureza estratgica como conhecimentos organizacionais. Reconhecido o fato do ambiente de turbulncia na qual atuam as organizaes, tem-se alavancado a importncia de capturar o know how como um ativo organizacional para a obteno de vantagem competitiva. O know-how, tambm chamado de ativos do conhecimento, pode ser representado pelas lies
159
aprendidas (experincias passadas relevantes, aplicao de determinado procedimento ou tcnica), modelos (de qualidade, distribuio de carga de trabalho, custos, segmentao de mercado) ou documentos corporativos (planos de marketing, produo e qualidade). Na rea de Engenharia de Software tem-se salientado a relevncia das questes organizacionais no projeto de sistemas de informao (Dobson & Strens, 1994). Nos ltimos anos tem crescido a importncia das abordagens sciotcnicas para a elicitao de requisitos de sistemas. Nesse sentido, as diversas definies da Engenharia de Requisitos enfatizam a relevncia do contexto organizacional para a elicitao de requisitos (Sommerville, 1989; Davis, 1990, Goguen, 1992; Leite, 1994), sendo em conseqncia de natureza crtica a criao de um baseline organizacional. Nota-se que tanto pela perspectiva de negcios como da Engenharia de Requisitos, ressalta-se a importncia da organizao dispor de informaes estratgicas e de conhecimentos (know how) com o propsito de suportar uma adequada tomada de decises, disseminao de conhecimento e elicitao de requisitos organizacionais. Assim, ter informao oportuna e de qualidade constitui um problema atual nas organizaes, que pode ser resolvido com modelos e ferramentas que facilitem tanto sua aquisio e armazenamento bem como na sua extrao e disseminao. A informao estratgica e o conhecimento denominado na literatura como ativos intangveis e a sua gesto chamada de Gesto do Conhecimento. Uma conceituao bastante aceita que a gesto do conhecimento o processo por meio do qual as organizaes geram valor a partir de seus ativos intelectuais e de conhecimento. Assim, o conceito de gesto do conhecimento tem um sentido mais amplo, pois envolve tanto aspectos gerenciais, os quais no foram tratados nesta tese, e aspectos tecnologicos, como as ferramentas que ajudam a gesto do conhecimento, como por exemplo, uma ferramenta de memria corporativa. O trabalho de uma proposta de arquitetura de Memria Corporativa Estratgica (SCM) baseada em um modelo de negcio , portanto, um tema que se encaixa dentro da rea de Gesto do Conhecimento, sendo o seu objetivo no s o armazenamento de informao, como tambm o auxilio disseminao de conhecimento na organizao e uma fonte para a elicitao de requisitos organizacionais. A proposta est ancorada em trabalhos passados (Fiorini, 1995;
160
Fiorini et al., 1996; Mamani-Macedo, 1999) e postula tanto um modelo conceitual do negcio, bem como uma proposta de arquitetura do SCM, independente do setor industrial. O primeiro objetivo, antes de criar a arquitetura do SCM, foi ter representaes e modelos que encapsulem conceitos do domnio da estratgia de negcios. Ressalta-se que uma memria organizacional corporativa inclui no somente construtos estratgicos, como tambm outros que vm do nvel ttico e operacional, porm, relevantes pela sua importncia no domnio. De acordo com a literatura estudada na rea de memrias corporativas, percebe-se, em geral, que tem-se prestado pouca ateno utilizao de modelos de negcio, pois a nfase est dada, principalmente, aos repositrios de documentos e aos dados orientados aos processos. Na atualidade existem propostas no meio acadmico (Chiu, 2003; Fiorini et al., 1996), as quais embora tenham utilizado conceitos de TQM e Reengenharia de Negcios tm ignorado a existncia de abordagens mais especficas sobre como as organizaes se comportam e interagem. Outras propostas e ferramentas como KnowMore
(Abecker et al., 1998), Fbrica de Experincias (Basili & McGarry, 1997), AskMe Enterprise (AskMe, 2001), Xpert Rule Knowledge Builder (Attar, 2003) e Quest Map (Gdss, 2003) so bastante teis, mas todas elas esto orientadas leitura de documentos ou recuperao de dados operacionais, no possuindo um modelo de negcio explcito como o proposto e projetado no presente trabalho do SCM, o qual facilita as funes de aquisio, armazenamento, busca e disseminao automtica. Certamente a operacionalizao de uma memria corporativa no uma tarefa trivial, pois conhecimento relevante tem que ser identificado, modelado e armazenado. Na presente pesquisa definiu-se como frame de referncia do domnio a rea de estratgia de negcios em ambiente com mudana contnua. Para a representao do domnio, criao do modelo do negcio, utilizou-se a abordagem ontolgica, para o qual foi necessrio selecionar um dos diversos mtodos que existem para a criao de ontologias (TOVE, Enterprise Methodology, Sensus, Bernaras et al., Methontology). O mtodo selecionado foi Methodology for Building Ontologies de Uschold & King (1995), pela sua simplicidade e clareza. No entanto, salienta-se que ainda no existe um mtodo que possa se dizer que melhor que os outros, sendo um tema de pesquisa atual. Para representar a
161
ontologia de negcio se utilizaram tanto o RDF Schema como o modelo de Entidade Relacionamento, porm, notou-se que ambos tm limitaes para a formulao de regras e a descrio de axiomas. Entretanto, como o presente trabalho no trata com inferncias, essas limitaes no o afetaram seriamente. Como entrada para a criao do modelo de negcio utilizou-se diversas abordagens tericas da cincia administrativa, as quais tm sido validadas atravs do tempo em uma ampla variedade de casos, em diferentes setores industriais por empresas de consultoria. Essas abordagens foram a escola positioning, o modelo de Porter (1980) e o modelo ambiental de Austin (1990), e a escola emphasizing efficiency, abordagens resource-based view (Day et al. 1997, Wernerfelt, 1984) e dynamic capabilities de Teece et al. (1997) , junto anlise de funes e processos, sob uma abordagem de qualidade total. De forma ortogonal, com vista ao enriquecimento do modelo, aplicou-se as metforas de Morgan. Desta forma, o modelo de negcio reflete uma srie de conceitos, atributos e relacionamentos elicitados das mais diversas fontes. Embora o modelo de negcio apresentado esteja orientado principalmente aos dados, este leva em conta aspectos de qualidade e da melhoria de processos. Atualmente o modelo de negcio est em um nvel genrico. Apesar que este enfatiza a integrao de conceitos via uma abordagem ontolgica, acredita-se que um maior detalhamento necessrio, como por exemplo, na descrio dos indicadores de benchmarking, os quais devero ser baseados em um programa de medio da qualidade. A integrao de um programa de medio com o aprendizado continuo poderia, por exemplo, ser executado usando a abordagem proposta por Cantone et al. (2000). Outra importante caracterstica do modelo a descrio das relaes sociais. Isto conseqncia da preocupao com os atores organizacionais e as suas responsabilidades, destacando assim a importncia dos aspectos sociais no processo de tomada de decises. Ressalta-se que o modelo conceitual do negcio engloba uma complexa rede de aspectos organizacionais modelados de maneira sistmica e objetivando futuras mudanas na prpria organizao. Portanto, o seu objetivo primrio representar o contexto organizacional com o propsito de explicitar informaes teis e relevantes. A criao de uma memria corporativa implicou, por definio, na integrao de dados das mais diferentes fontes (legados, web, bancos de dados relacionais e de objetos, entre outros) e tipos de dados (textuais e multimdia). Isto
162
levou a busca de uma soluo baseada em uma abordagem de integrao materializada, a qual reflete-se na criao do repositrio de conhecimento, o Organizational Baseline. O Organizational Baseline foi baseado no modelo de negcio, e portanto inclui construtos relevantes ao nvel estratgico. No entanto, o mesmo tambm incorpora construtos tticos e operacionais que por sua relevncia foram includos, enfatizando-se, assim, a dimenso estratgica do SCM. Um outro repositrio importante do SCM a base de casos do know how, onde se armazena experincias passadas de sucesso, bem como tambm aquelas experincias de insucesso, porm relevantes. Estes tipos de experincias pelas suas prprias caractersticas no foram armazenados no Organizational Baseline, da o motivo da criao de um repositrio independente deste dentro da arquitetura do SCM. A proposta arquitetural apresentada define em detalhe os diferentes componentes - agentes que so necessrios para implementar o SCM, os quais so: Controle e Comunicao, Interface, Usurio, Busca, Armazenamento e Disseminao e, Armazenamento de Lies Aprendidas (Base de Casos). O SCM facilita o acesso, compartilhamento, reuso e disseminao do conhecimento em toda a organizao, permitindo acrescentar tanto a sua competitividade como o seu aprendizado. No entanto, como descrito anteriormente, todo o processo de gesto do conhecimento necessita no s de facilitadores tecnolgicos como tambm facilitadores gernciais, sendo estes ltimos to importantes quanto os primeiros. O SCM um facilitador tecnolgico que visa operacionalizar esse processo. Nesse sentido, importante perceber que a execuo de um processo de gesto de conhecimento exige a implementao simultnea de ambos facilitadores, a utilizao de ferramentas e mtodos de cunho tecnolgico, como o caso do SCM. A execuo de um programa de desenvolvimento organizacional para motivar o enraizamento de uma filosofia orientada ao compartilhamento do conhecimento entre os membros da organizao, tambm se faz necessrio. As duas funcionalidades bsicas do SCM so: o servio de consulta
requerida (busca) e o servio de disseminao automtica. O SCM para fazer a
busca no repositrio de conhecimento do Organizational Baseline utiliza mapeamentos pr-estabelecidos, os quais permitem a recuperao de entidades mais pertinentes dada uma consulta em particular. As palavras chave fornecidas
163
so comparadas com a estrutura ontolgica como base para encontrar a entidade / atributo mais adequado. No caso do repositrio do Case Base, a busca se realiza utilizando heursticas de similaridade. O processo de consulta no SCM se d atravs de palavras chave que so submetidas ao SCM pelos usurios (gerentes, consultores, engenheiros de requisitos). O agente de Busca, utilizando a semntica contida na ontologia, faz a busca no repositrio (Organizational Baseline) e extrai as informaes relevantes contida nas entidades e nos seus atributos, para finalmente entregar esses resultados aos usurios do SCM. Os dados utilizados para validar o prottipo do SCM, foram extrados e adaptados de um estudo de caso relatado no livro Imagens of Organizations de G. Morgan (1996), o caso da Multicom. A empresa Multicom est dedicada aos servios de consultoria de marketing e relaes pblicas. Esta empresa estava sofrendo uma crise organizacional e em vista disso os principais scios decidiram convocar a participao de uma empresa de consultoria de negcios, com o objetivo de receber um diagnostico organizacional sobre seu estado atual e as possveis alternativas de soluo. Este estudo de caso serviu para a exemplificao das idias apresentadas no presente trabalho e mostrou as vantagens e o funcionamento do repositrio principal do SCM, o Organizational Baseline, nos casos dos servios de busca e disseminao. Dessa forma validou-se tanto o modelo do negcio e o Organizational Baseline quanto a arquitetura proposta do SCM.
7.2 Contribuies
As principais contribuies deste trabalho so:

Propor a criao de uma ontologia voltada para o negcio, baseada em
teorias, abordagens e vises da administrao de negcios. A ontologia permitiu, logo, a criao do modelo conceitual do negcio no qual explicitou-se os conceitos e os seus relacionamentos. O modelo do negcio por sua vez foi utilizado na estruturao do repositrio principal da memria corporativa, o Organizational Baseline;
164
Propor o uso de ontologias para a extrao de conhecimentos do
Organizational Baseline. Isto factvel porque a ontologia foi elicitada a partir do marco terico fornecido pela cincia administrativa. Esse marco terico constitudo pelas diversas teorias, abordagens e vises j foi validado na rea de estratgia de negcios por inmeras empresas de consultoria;
Propor uma arquitetura genrica para a implementao da memria
corporativa estratgica. Esta arquitetura, baseada nos estilos arquiteturais de camadas e repositrios, define trs camadas: fontes, servios e repositrios;
Propor uma arquitetura de software para implementar a camada de
servios. A camada de servios foi desenvolvida sob uma abordagem de agentes, dado que esta satisfaz melhor as caractersticas do SCM, as quais so autonomia, interatividade e adaptatividade;
Ter definido como funcionalidades bsicas de uma memria corporativa
os servios de busca e disseminao. Para a determinao destes servios utilizou-se tanto a Metodologia MESSAGE como a anlise dos
requisitos no funcionais;
Apoiar a operacionalizao de um sistema de gesto de conhecimento
fornecendo uma arquitetura de ferramenta de memria corporativa que implemente as funcionalidades requeridas por esta, tais como aquisio, armazenamento, compartilhamento e disseminao;
Ter desenvolvido um prottipo do SCM com o intuito de monstrar o uso
dos conceitos da ontologia do negcio. Os dados para preencher os repositrios do Organizational Baseline foram extrados de um estudo de caso relatado em Morgan (1996).
7.3 Trabalhos Futuros
A partir da arquitetura proposta e do prottipo implementado neste trabalho podem ser especificados e desenvolvidos novas instncias do SCM. importante ressaltar que o prottipo apresentado, embora desenvolvido parcialmente, serviu para demonstrar conceitos da memria corporativa, no entanto, necessrio o desenvolvimento dos outros componentes. Espera-se no futuro poder realizar
165
novos estudos de casos, com dados reais provenientes de organizaes em atividade. Pretende-se, assim, apesar dos diferentes problemas de coleta de dados, ter exemplos que ajudem a ajustar tanto o Organizational Baseline como a arquitetura do SCM em si. A seguir prope-se alguns trabalhos especficos que podem ser pesquisados e desenvolvidos:
Desenvolvimento dos componentes Controle e Comunicao, Armazenamento no baseline, Armazenamento de Lies Aprendidas na base de casos. O desenvolvimento e detalhe desses componentes deve permitir realizar ajustes arquitetura, a luz desses novos resultados;
Especificao e Desenvolvimento do componente Regras de Inferncia, o qual no foi tratado no presente trabalho e um tema em aberto para a realizao de pesquisas;
Desenvolvimento
(re)
uso
do
componente
agente
de
Descobrimento, o qual um wrapper (mediador) que permite a extrao de informao de uma determinada fonte de dados. Pode se desenvolver um conjunto de wrappers para diferentes tipos de fontes, bem como pesquisar a existncia de outros j existentes e disponveis na internet para seu re-uso;
A proposta do SCM prope, tambm, a utilizao de uma base de casos, a semelhana de outras propostas de memrias corporativas, utilizando-se para a recuperao de experincias a abordagem do raciocnio baseado em casos, como por exemplo buscas por similaridade. Trabalhos futuros nesta direo da recuperao de experincias estudar e propor novas heursticas de similaridade bem como o uso dos conceitos da ontologia do negcio. Vale ressaltar que a gesto do conhecimento at agora estava orientada a uma nfase na gesto de documentos. Acredita-se que o uso de ontologias para a recuperao de experincias uma forma adequada para a extrao de conhecimento.
8 Referncias Bibliogrficas
ABECKER, A.; BERNARDI, A.; HINKELMANN, K.; KHN, O.; SINTEK M. Toward a Technology for Organizational Memories. IEEE Intelligent Systems 13(3): 40-48 May/June 1998. ALPANDER, G. G.; LEE, C. R. Culture, Strategy and Teamwork: The keys to organizational change. Journal of Management Development, August 1995, v.14, n.8, p4(15). ALTHOFF, K.-D.; BIRK, A.; WANGENHEIM, C. G. VON; TAUTZ C. CBR for Experimental Software Engineering. In Case-Based Reasoning Technology, Lecture Notes in Artificial Intelligence, LNAI 1400, Eds. M. Lenz et al. Springer-Verlag 1998: 235-254. ARGYRIS, C.; SCHON, D. Organizational Learning: A Theory of action perspective. Reading, MA: Addison-Wesley, 1978. ASKME CORPORATION. Disponvel em URL: <http://www.askmecorp.com>. Acesso em: 03 maio 2003. ATTAR Disponvel em URL:<http://www.attar.com/pages/info_xr.htm>. Acesso em: 03 maio 2003. AUSTIN, J.E. Managing in Developing Countries: Strategic Analysis and Operating Techniques. The Free Press. 1990. AYVAR, H.; FALCON, F.; MAMANI-MACEDO, N.A.; RODRIGUEZ J. Planeamiento Estratgico e Implementacin de una empresa del ramo Electro-tcnico. Dissertao de Mestrado em Administrao. Escuela de Administracin de Negcios para Graduados, ESAN. Lima, Per. Abril 1989. (Em Castelhano). BARBOSA, A. C. P. Middleware para Integrao de Dados Heterogneos Baseado em Composio de Frameworks. PhD. Tese. Departamento de Informtica, PUC-Rio, 2001. BASILI, V.; MCGARRY, F. The Experience Factory: How to Build and Run One, Proceedings 19th Intl Conference on Software Engineering, (ICSE'97), Boston, Massachusetts, May 17-23, 1997. BERNARAS, A.; LARESGOITI, I.; CORRERA, J. Building and Reusing Ontologies for Electrical Network Applications. Proceedings ECAI96. 12th European Conference eon Artificial Intelligence. ED. John Wiley & Sons, Ltd. 298-302. BERTALANFFY, L. VON. The Theory of Open Systems in Physics and Biology. Science, 111, 23-29, 1950. BERTRAND, P.; DARIMONT, R.; DELOS, E.; MASSONET, P.; LAMSWEERDE A. VAN. GRAIL/KAOS: An Environment for Goal Driven Requirements Engineering. Proceedings ICSE98 20th Intl Conference on Software Engineering. IEEE-ACM. Kyoto, April 1998.
167
CANTONE, G.; CANTONE, L.; DONZELLI, P. Organizing Software Technology Models, Measures and experiences for Conceptual Learning. Proceedings of the 2nd Workshop on Learning Organizations. Edited for Klaus-Dieter Althoff. Frauhofer, IESE, KL Germany. 2000. CARROLL, D. Requirements Engineering Needs Total Systems Engineering. Requirements Engineering Volume 2, Number 4, 1997. Springer-Verlag. CERAMI, E. Web Services Essentials. OReilly & Associates, Inc. 2002. CHABERT, J.M. DE; A Model for the Development and Implementation of Core Competences in Restaurant Companies for Superior Financial Performance. Dissertation of Phd. Virginia Polytechnic Institute and State University. June 1998. CHIU, C. Towards integrating hypermedia and information systems on the web. Information & Management. Volume 40, Issue 3, January 2003, Pages 165175. Elsevier Science B.V. CHUNG, L. Representing and Using Non-Functional Requirements: A Process-Oriented Approach, Phd. Thesis, Univ. of Toronto, 1993. CONKLIN, J.; BEGEMAN, M. L. (1987). gIBIS: A Hypertext Tool for Team Design Deliberation. In Proceedings of the 1st ACM International Hypertext Conference (Hypertext-87), November, Chapel Hill, NC, 247-252. DAFT, R.L.; WEICK, K. E. Toward a model of organizations as interpretation systems. Academy of Management Review, 1984, 9(2), 284-295. DARIMONT, R., LAMSWEERDE, A. VAN, Formal Refinement Patterns for GoalDriven Requirements Elaboration. Proceedings of 4th ACM Symposium on the Foundations of Software Engineering, San Francisco, 1996. DAVENPORT, T.H.; PRUSAK, L. Conhecimento Empresarial: como as organizaes gerenciam seu capital intelectual. Rio de Janeiro: Campus, 1998. DAVIS, A. Software Requirements: analysis and specification. Prentice Hall, 1990. DAY, G. S.; REIBSTEIN, D. J.; GUNTHER, R. Ed. Wharton on Dynamic Competitive Strategy, USA. John Wiley & Sons. 1997. DOBSON, J.E.; STRENS, M.R. Organisational Requirements Definition for Information Technology Systems, Proceedings IEEE, ICRE'94, Colorado Springs, April 1994. ESKELIN, P. Component Interaction Patterns. Proceedings Pattern Languages of Programs Conference PloP99, USA, August 1999. EURESCOM. A Specification of a Framework for Agent Oriented Workflow Management Systems. February 2001. Disponvel em URL: <http://www.eurescom.de/public/projectresults/P800-series/815d1.htm> Acesso em: 10 maro 2003. 2001a. EURESCOM. MESSAGE: Methodology for Engineering Systems of Software Agents Deliverable 1. September 2001. Project P907-GI. Disponvel em URL: http://www.eurescom.de/~pub-deliverables/P900-series/P907/TI2/p907ti2.pdf Acceso em: 10 maro 2003. 2001b. FERNANDEZ-BREIS, J.T., CASTELLANOS, D., VALENCIA-GARCIA, R., VIVANCOS-VICENTE, P.J., MARTINEZ-BEJAR, R., DE LAS HERASGONZALEZ, M. Towards Scott domains-based topological ontology models. An
168
application to a cancer domain. Proceedings of the International Conference on Formal Ontology in Information Systems - Volume 2001. ACM Press New York, NY, USA. FERNANDEZ-BREIS, J. T.; MARTINEZ-BJAR, R.; CAMPOY-GOMEZ, L. M.; MARTIN-RUBIO, F.; GARCIA-MARTINEZ, J. J. A Cooperative Approach to Corporate Memory Modeling. Proceedings ECAI'02 Workshop on Knowledge Management and Organizational Memories Lyon (France) - July 22, 2002. Disponvel em URL: <http://www-sop.inria.fr/acacia/WORKSHOPS/ECAI2002OM/Actes/Fernandez.pdf>. Acesso em: 10 de julho 2003. FERNNDEZ-LPEZ, M. Overview of methodologies for building ontologies. Proceedings IJCAI 99. Proceedings Workshop on Ontologies and ProblemSolving Methods: Lessons Learned and Future Trends. CEUR Publications, 1999 Disponvel em <http://www.ontology.org/main/presentations/madrid/analysis.pdf> Acesso em: 10 maro 2003. FIKES, R.; FARQUHAR, A.; RICE, J. Tools for Assembling Modular Ontologies in Ontolingua. Knowledge Systems Laboratory, 1997. Proceedings of the Fourteenth National Conference on Artificial Intelligence (AAAI '97). (July 27-31, Providence, RI) 1997: 436-441. Disponvel em URL: Acesso <http://www.ksl.stanford.edu/software/ontolingua/project-papers.html>. em: 12 maro 2003. FIORINI, S.T. Processos de Negcio e Hipertextos: Uma Proposta para Elicitao de Requisitos. Departamento de Informtica, PUC-Rio, 1995. Dissertao de Mestrado. FIORINI, S.; LEITE, J.C.S. DO P.; MACEDO-SOARES, T.D. V. A. DE. Integrating Business Processes with Requirements Elicitation. Proceedings of Fifth Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises. IEEE Comp. Society Press, 1996, pp. 226-231. FIPA - FOUNDATION FOR http://www.fipa.org/ 08, julho, 2003. INTELLIGENT PHYSICAL AGENTS.
GARLAN, D.; SHAW, M. An Introduction to Software Architecture. School of Computer Science. Carnigie Mellon University. Pittsburgh, PA 15213-3890. CMU-CS-94-1166, also appears as CMU Software Engineering Institute Technical Report CMU/SEI-94-TR-21 and ESC-TR-94-21. GARTNER GROUP. Tecnologia da Informao, Administrao do Conhecimento e Tecnologia: chave do sucesso. Encarte especial da Revista Exame, no 669, Agosto 1998. GDSS. Disponvel em URL: <http://ww.gdss.com/wp/DOM.htm>. Acesso em: 10 de julho 2003. GOGUEN, J. A. The Dry and the Wet, in Information Systems Concepts: Improving the Understanding. Proceedings IFIP WG 8.1 Conference (Egypt) Elsevier Holland, 1992, pp. 1-17. GMEZ-PREZ, A. Knowledge Sharing and Reuse. In the Handbook of AppliedExpert Systems. CRC Press. 1998. GMEZ-PREZ, A. Tutorial on Ontological Engineering. Proceedings IJCAI99. Sixteenth International Joint Conference on Artificial Intelligence 1999. Disponvel em URL: <http://www.dsv.su.se/ijcai-99/>. Acesso em: 15 maro 2003. GRUBER, T. A translation Approach to portable ontology specifications. Knowledge Acquisition. Vol 5. 1993. 199-220.
169
GRNINGER, M.; FOX, M.S. The Logic of Enterprise Modelling. Modelling and Methodologies for Enterprise Integration. P. Bernus & L. Nemes (Eds.), Cornwall, Great Britain: Chapman and Hall. Also appeared in: Proceedings of the Industrial Engineering Research Conference, IIE, Nashville TN, also appeared in: Re-engineering the Enterprise, J. Browne & D. OUSullivan (Eds), London England: Chapman & Hall, pp. 83-98. 1996. GUARINO, N.; GIARETTA, P. Ontologies and Knowledge Bases: Towards a Terminological Clarification. Towards Very Large Knowledge Bases: Knowledge Building & Knowledge Sharing. IOS Press. 1995. 25-32. GUARINO, N. Formal Ontology and Information Systems. In: Proceedings 1st International Conference Formal Ontology in Information Systems, June 1998. Trento, Italy. HENDRIKS, P. H. J.; VRIENS, D.J. Knowledge-based systems and knowledge management: Friends or foes? Information & Management 35 (1999) 113-125. Elsevier Science B.V. HOHMANN, L. Beyond Software Architecture. Addison Wesley Professional; 1st edition (January 30, 2003) ISBN: 0201775948. IGLESIAS, C.; GARRIJO, M.; GONZALEZ, J.; VELASCO, J.R. Analysis and Design of Multiagent Systems using MASCommonKADS. In Intelligent Agents IV: Agents Theories, Architectures and Languages. 1997. Lecture Notes in Computer Science LNCS 1365. Springer-Verlag. pp. 313-326. JARKE, M.; TUNG BUI, X.; CARROLL, J. Requirements Engineering, Volume 3, Numbers 3&4, 1998. Special Issue on Interdisciplinary Uses of Scenarios. Springer-Verlag. JENNINGS, N. Agent-Based Approach for Building Complex Software Systems. Communications of ACM, v. 44, n. 4. April, 2001. JIROTKA, M.; GOGUEN, J. Eds. Requirements Engineering: Social and Technical Issues. Academic Press Limted. 1994. KLUSCH, M. Intelligent Information Agents: Agent Based Information Discovery and Management on the Internet. Ed. Matthias Klusch, SpringerVerlag, 1999. KLUSCH, M. Information agent technology for the internet: A survey. Data & Knowledge Engineering 36, 2001. KOTLER, P. Marketing Management: Analysis, Planning, Implementation and Control. Sixth Edition. Ed. Prentice Hall, Englewod Cliffs, 1988. LEITE, J.C.S. DO P. Engenharia de Requisitos. Notas de Aula. PUC-Rio. 1994. LEITE, J.C.S. DO P.; ROSSI, G.; MAIORANA V.; BALAGUER, F.; KAPLAN, G.; HADAD, G.; OLIVEROS, A. Enhancing a Requirements Baseline with Scenarios. Requirements Engineering Volume 2, Number 4, 1997. Springer-Verlag London Limited. LEONARD-BARTON, D. Core Capabilities and Core Rigidities: A paradox in managing new product development. Strategic Management Journal. Summer Special Issue, 13, pp. 111-125. 1992. LEWIS, D. The Organizational Culture saga from OD to TQM: A Critical Review of the literature. Leadership & Organization Development Journal. January 1996. V17,n1 p12(8), March 1996. V17, n2 p9 (8).
170
LIEBOWITZ, J. Building Organizational Intelligence: A Knowledge Management Primer. New York: CRC Press. 1999. MAGALHES, F.C. Qualidade & Mudana: O Caso da IBM Brasil. Departamento de Engenharia Industrial, PUC-Rio, 1993. Dissertao de Mestrado. MALHOTRA, Y. What is Knowledge Management? Online. Disponvel em: URL: <http://www.brint.com/> Acesso em: 23 de setembro de 2002. MATURANA, H.; VARELA, F. Autopoiesis and Cognition: The Realization of the Living. Boston Studies in the Philosophy of Science [Cohen, Robert S., and Marx W. Wartofsky (eds.)], Vol. 42, Dordecht (Holland): D. Reidel Publishing Co., 1980. MACEDO-SOARES, T. D. L. VON A. DE; CHAMONE, S.G.R. Total Quality Strategies in Industry: The Experience of Two Multinationals in Brazil. In Quality Management Journal, Number 1, pp. 57-79, Milwaukee: ASQC, April. Quality Press. MAMANI-MACEDO, N.A. Integrando Requisitos No Funcionais aos Requisitos Baseados nas Aes Concretas. Dissertao de Mestrado. Departamento de Informtica, PUC-Rio. 1999. MAMANI-MACEDO, N.A.; LEITE, J.C.S. DO P. Criao de uma Memria Organizacional sob uma Abordagem de Ontologias. Ideas2001, Anais Workshop Iberoamericano de Ambientes e Desenvolvimento de Software. San Jose, Costa Rica. 2001. MAMANI-MACEDO, N.A.; PRO, L.; SALAZAR, A. Metodologia para la Evaluacin y Seleccion de un Sistema de Computo (Caso de una empresa de Productos Lacteos). Dissertao para optar o Ttulo Profissional de Licenciado em Computao. Em castelhano.1992. MARTINEZ-BEJAR, R. Knowledge modeling technologies: ontologies and rippledown rules. Palestra dada em ICMC-USP So Carlos 14, 17 Novembro 2000. Professor da Universidad de Murcia, Espanha. MERRIAN WEBSTER Dictionary. Online. Documento capturado em 12/10/2003. Disponvel na Internet.URL: http://www.m-w.com MIZOGUCHI, R.; VANWELKENHUYSEN, J.; IKEDA, M. Task Ontology for Reuse of Problem Solving Knowledge. Towards Very Large Knowledge Bases: Knowledge Building & Knowledge Sharing. IOS Press. 1995. 46-59. MORGAN, G. Imagens da Organizao. Ed. Atlas, 1996. MURRAY, Philip C. New language for new leverage: the terminology of knowledge management (KM). Documento capturado em 12/09/2003. Disponvel em URL: <http://www.ktic.com/topic6/13_TERM0.HTM> Acesso em: 10 maio de 2003. NECHES, R.; FIKES, R.; FININ, T.; GRUBER, T.; PATIL, R.; SENATOR, T.; SWARTOUT, W.R. Enabling Technology for Knowledge Sharing. Artificial Intelligence Magazine. Winter 1991. 36-56. NONAKA, I. TAKEUCHI, H. The Knowledge-Creating Company. Oxford University. Press. 1995. OMG - OBJECT MANAGEMENT GROUP Agent Platform Special Interest Group. Agent Technology Green Paper. Version 1.0, September 2000.
171
PORTER, M. E. Competitive Strategy. 1980. Free Press, A Division of Macmillan Publishing Co., NY, USA. PORTER, M. E. Competitive Advantage.1985. Free Press, A Division of Macmillan Publishing Co., NY USA. PROTG. http://protege.stanford.edu/ Copyright 2003 Stanford Medical Informatics. RIESBECK, C.; SCHANK, R. C. Inside Case-Based Reasoning, Lawrence Erlbaum Associates, Hillsdale, NJ, 1989. RUMELT, R.P.; SCHENDEL, D.; TEECE, D. Strategic Management and Economics, Strategic Management Journal, 12 (winter), 5-30, 1991. RUNDENSTEINER, E.A.; KOELLER, A.; ZHANG, X. Maintaining Data Warehouses over Changing Information Sources. Communications of the ACM. June 2000/Vol.43 No. 6, pp.57-62. SCHENEIDER, J. G. Components, Scripts, and Glue: A Conceptual Framework for Software Composition. PhD Thesis. Institute of Computer Science and Applied Mathematics, University of Bern, Swiss, 1999. Disponvel em URL:<http://www.iam.unibe.ch/~scg/Archive/PhD/schneider-phd.pdf Acesso em: 10 de maio de 2003. SCHREIBER, A.T. The KADS approach to knowledge engineering. Editorial special issue. Knowledge Acquisition, 4(1):14, 1992. SHOHAM, Y. Agent-Oriented Programming. Artificial Intelligence, 60: pp. 2429, 1993. SHRIVASTAVA, P.; SCHNEIDER, S. Organizational frames of reference. Human Relations, 1984, 37(10), 795-809. SIMON, H.A. Bounded Rationality and Organizational Learning. Organization Science 1991, 2(1), 125-134. SOMMERVILLE, I. Software Engineering, 3rd edition. Addison-Weslwy, Norwood, NJ, 1989. SOUZA, E.J. A relao entre Tecnologia da Informao & Gesto do Conhecimento e seu uso na gesto de empresas. Dissertao de Mestrado. Universidade Metodista de Piracicaba. Programa de ps-graduao em Engenharia de Produo. Acesso em: 10 de outubro de 2003. Disponvel em URL: <http://www.sbgc.org.br/cgi/cgilua.exe/sys/start.htm?infoid=343&sid=30> STONER, J.A.F. Administracin. Mexico, Ed. Prentice-Hall, 1986. STUDER, R.; BENJAMINS, V.R.; FENSEL, D. Knowledge Engineering: Principles and Methods. Data and Knowledge Engineering. 25 (1998) 161197. SVEIBY, K.E. A nova riqueza das organizaes. Rio de Janeiro: Campus. 1998. SWARTOUT, B.; PATIL, R.; KNIGHT, K; RUSS, T. Toward Distributed Use of Large-Scale Ontologies. Ontological Engineering. Proceedings AAAI-97 Spring Symposium Series. 1997. 138-148. SYCARA, K.; LU, J.; KLUSCH, M.; WIDOLF, S. Matchmaking among Heterogeneous Agents on the Internet. In Proceedings AAAI Spring Symposium on Intelligent Agents in Cyberspace, 1999.
172
TEECE, D.J., PISANO, G., SHUEN, A. Dynamic Capabilities and Strategic Management, Strategic Management Journal 18: 509-534. 1997. TSANG, E. Organizational Learning and the Learning Organization: A Dichotomy between Descriptive and Prescriptive Research. Human Relations, January 1997, v 50, n 1, p 73 (17). TVERSKY, A. Features of similarity. Psychological Review 84, 1977: 327-352. UNIVERSITY OF TEXAS AT AUSTIN, UT-Austin, Graduate School of Business. Knowledge Management Server. Knowledge Management Home Page. Disponvel em URL: <http://www.mccombs.utexas.edu/kman/answers.htm> USCHOLD, M.; GRNINGER, M. ONTOLOGIES: Principles, Methods and Applications. Knowledge Engineering Review. Vol 11. No 2. June 1996. USCHOLD, M.; KING, M. Towards a Methodology for Building Ontologies. Proceedings Workshop on Basic Ontological Issues in Knowledge Sharing, held in conjunction with IJCAI-95. Also available from Artificial Intelligence Applications Institute. University of Edinburgh, AIAI-TR-183. USCHOLD, M.; KING, M.; MORALEE, S.; ZORGIOS, Y. (1998). The Enterprise Ontology. The Knowledge Engineering Review, Vol. 13, Special Issue on Putting Ontologies to Use (Eds. Mike Uschold and Austin Tate). Also available from AIAI as AIAI-TR-195. VAN DE VEN, A.H.; POOLE, M.S. Explaining Development and Change in Organizations. Academy of Management Review, July 1995 v 20, n 3, p 510 (31). VAN HEIJST, G.; VAN DER SPEK, R.; KRUIZINGA, E. Organizing Corporate Memories. In B, Gaines, M. Musen Eds. Proceedings of Knowledge Acquisition Workshop96, Banff, Canada, November, pp. 42-1 42-17. 1996. VAN HEIJST, G.; SCHREIBER, T.; WIELINGA, B. Using Explicit Ontologies in KBS. International Journal of Human-Computer Studies.Vol. 46 (2/3). 183292. 1997. WALSH, J.P.; UNGSON, G.R. Organizational Memory. Academy Management Review, 1999. 16 (1), 57-91. WERNERFELT, B.; A Resource-Based View of the Firm. Strategic Management Journal, Volume 5, April-June 1984, pp. 171-180. VOLLMANN, T.E. The Transformation Imperative: Achieving Market Dominance through Radical Change. Boston, M.A. Harvard Business School Press, 1996. WOOLDRIDGE, M.; JENNINGS, N. Intelligent Agents:Theory and Practice. The Knowledge Engineering Review, 10, 2 pp. 115-152, 1995. WOOLDRIDGE, M.; JENNINGS, N.; KINNY, D. The Gaia Methodology for AgentOriented Analysis and Design. Journal of Autonomous Agents and Multi-
Agent Systems 3 (3). 2000, 285-312.

WANGENHEIM, C. G. VON; RODRIGUEZ, M.R. Case-Based Management of Software Engineering Experienceware. IBERAMIA SBIA 2000, Lecture Notes in Artificial Intelligence 1952, pp. 12-22, 2000. Springer-Verlag Berln Heidelberg 2000. XU, X.M.; KAYE, G.R.; DUAN, Y. UK executives vision on business environment for information scanning. A cross industry study. Information & Management. May2003, Volume 40, Issue5, pp. 381-389. Elsevier Science B.V.

Criando Uma Arquitetura de Memória Corporativa Baseada em Um Modelo de Negócio

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Criando Uma Arquitetura de Memória Corporativa Baseada em Um Modelo de Negócio

Uploaded by

Copyright:

Available Formats

Nstor Adolfo Mamani Macedo

CRIANDO UMA ARQUITETURA DE MEMRIA CORPORATIVA BASEADA EM UM MODELO DE NEGCIO

Rio de Janeiro Julho de 2003

Prof. Karin Koogan Breitman Departamento de Informtica PUC-Rio

Prof. Luiz Marcio Cysneiros York University Toronto Ontario - Canada

Rio de Janeiro, 03 de julho de 2003

Ficha Catalogrfica Mamani Macedo, Nstor Adolfo

172 p.: il. ; 30,0 cm

1. Tese (doutorado) Pontifcia Universidade Catlica do Rio de Janeiro, Departamento de Informtica.

Inclui referncias bibliogrficas.

Em memria de meu pai.

motivao para seguir estudos de ps-graduao no Brasil.

Attar Software Limited

80 80 82 84 84 85 86 87 87 95 95 96 100 102 103 104 107 108 109 113 114

115 116 118

5.5.4. O Componente Agente Descobrimento 5.5.5. O Componente Busca

38 72 73 76 77 83 90 91 92 93 94 114 125 138 142

Criando uma Arquitetura de Memria Corporativa baseada em um Modelo de Negcio

Criando uma Arquitetura de Memria Corporativa baseada em um Modelo de Negcio

Criando uma Arquitetura de Memria Corporativa baseada em um Modelo de Negcio

Criando uma Arquitetura de Memria Corporativa baseada em um Modelo de Negcio

Criando uma Arquitetura de Memria Corporativa baseada em um Modelo de Negcio

Criando uma Arquitetura de Memria Corporativa baseada em um Modelo de Negcio

Explicao Acesso s lies aprendidas dos tcnicos

Ford Buckman Labs

Acesso s melhores prticas Permite encontrar aos empregados com

experincia e fazer perguntas Texas Instruments HoffmanLaRoche Acesso s melhores prticas

previamente aprovado Honeywell Cria, captura, compartilha e utiliza conhecimento organizacional

Tabela 1.1 Vantagens decorrentes do uso do conhecimento (AskMe, 2001)

Criando uma Arquitetura de Memria Corporativa baseada em um Modelo de Negcio

organizacional, so uma importante fonte de conhecimento para que os membros

Criando uma Arquitetura de Memria Corporativa baseada em um Modelo de Negcio

Criando uma Arquitetura de Memria Corporativa baseada em um Modelo de Negcio

Organizao Tomada de Decises

Competitiva Estratgia Dinmica

Elicitao de Requisitos Organizational Baseline Case Base

Figura 1.1 Memria Organizacional

Criando uma Arquitetura de Memria Corporativa baseada em um Modelo de Negcio

Criando uma Arquitetura de Memria Corporativa baseada em um Modelo de Negcio

Criando uma Arquitetura de Memria Corporativa baseada em um Modelo de Negcio

Ontologia do Negcio Organizational Baseline

PROJETAR Memria Corporativa

Figura 2.1 Metodologia para o desenvolvimento da Arquitetura

Criando uma Arquitetura de Memria Corporativa baseada em um Modelo de Negcio

Organizational Baseline (Strategic Corporate Memory)

Criando uma Arquitetura de Memria Corporativa baseada em um Modelo de Negcio

Criando uma Arquitetura de Memria Corporativa baseada em um Modelo de Negcio

Criando uma Arquitetura de Memria Corporativa baseada em um Modelo de Negcio

intelectual existente visando ganhar uma vantagem competitiva sustentvel.

Criando uma Arquitetura de Memria Corporativa baseada em um Modelo de Negcio

inferncias e tomar decises, baseado no conhecimento compatilhado na organizao;

Administrao do Sistema: Fornece as ferramentas para o

monitoramento e a manuteno do sistema.

Criando uma Arquitetura de Memria Corporativa baseada em um Modelo de Negcio

3.4 XpertRule Knowledge Builder

Attar Software Limited (Attar, 2003)

Criando uma Arquitetura de Memria Corporativa baseada em um Modelo de Negcio

Criando uma Arquitetura de Memria Corporativa baseada em um Modelo de Negcio

Criando uma Arquitetura de Memria Corporativa baseada em um Modelo de Negcio

Memria Organizacional Caractersticas Orientao

Academia KnowMore Fab.Exp. AskMe

Indstria XpertRule QuestMap SCM

Faz uso de Ontologias com nfase em: