Néstor Adolfo Mamani Macedo CRIANDO UMA ARQUITETURA DE …julio/teseNestor.pdf · CRIANDO UMA ARQUITETURA DE MEMÓRIA CORPORATIVA BASEADA EM UM MODELO DE NEGÓCIO Tese de Doutorado

Néstor Adolfo Mamani Macedo

CRIANDO UMA ARQUITETURA DE MEMÓRIA

CORPORATIVA BASEADA EM UM MODELO DE NEGÓCIO

Tese de Doutorado

Tese apresentada ao Programa de Pós-graduação em Informática da PUC-Rio como requisito parcial para obtenção do título de Doutor em Informática.

Orientador: Julio Cesar Sampaio do Prado Leite

Co-orientador: Teresia Diana Lewe van Aduard de Macedo-Soares

Rio de Janeiro

Julho de 2003


Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio

Tese apresentada como requisito parcial para obtenção do grau de Doutor pelo Programa de Pós-graduação em Informática do Departamento de Informática do Centro Técnico Científico da PUC-Rio. Aprovada pela Comissão Examinadora abaixo assinada.

Prof. Julio Cesar Sampaio do Prado Leite Orientador

Departamento de Informática – PUC-Rio

Prof. Carlos José Pereira de Lucena Departamento de Informática – PUC-Rio

Prof. Karin Koogan Breitman Departamento de Informática – PUC-Rio

Prof. Luiz Marcio Cysneiros York University – Toronto – Ontario - Canada

Prof. Alvaro Cesar Pereira Barbosa Universidade Federal do Espírito Santo – UFES

Prof. Ney Augusto Dumont �� !�� #"%$�&'�)(+*)� �

Rio de Janeiro, 03 de julho de 2003

Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho sem autorização da universidade, do autor e do orientador.


Graduou-se em Ciências Contábeis na Universidad Inca Garci-laso de la Vega (UIGV-Peru) e em Ciência da Computação na Universidad Nacional Mayor de San Marcos (UNMSM-Peru). Nesta última também obteve a Licenciatura em Ciência da Computação. Mestre em Administração pela Escuela de Administración de Negócios para Graduados (ESAN-Peru) e Mestre em Informática pela PUC-Rio. Realizou trabalhos de consultoria em administração, finanças e sistemas de informação em diversas empresas e instituições no Peru.

Ficha Catalográfica

Mamani Macedo, Néstor Adolfo

Criando uma arquitetura de memória corporativa baseada em um modelo de negócio/ Néstor Adolfo Mamani Macedo; orientador: Julio Cesar Sampaio do Prado Leite; co-orientador: Teresia Diana Lewe van Aduard de Macedo-Soares. – Rio de Janeiro: PUC, Departamento de Informática, 2003.

172 p.: il. ; 30,0 cm

1. Tese (doutorado) – Pontifícia Universidade Católica do Rio de Janeiro, Departamento de Informática.

Inclui referências bibliográficas.

1.Informática – Teses. 2. Gestão do Conhecimento. 3. Memórias corporativas. 4. Modelos de negócio. 5. Sistemas de informação. 6. Ontologias e agentes. I. Leite, Julio Cesar Sampaio do Prado, Macedo-Soares, Teresia Diana Lewe van Aduard de. II. Pontifícia Universidade Católica do Rio de Janeiro. Departamento de Informática. IV. Título.

CCD: 004

Em memória de meu pai.

Agradecimentos

Ao meu orientador Professor Julio Cesar Sampaio do Prado Leite pelo estímulo e

confiança na realização deste trabalho na área de Gestão do Conhecimento.

À minha co-orientadora Professora Teresia Diana Lewe van Aduard de Macedo-

Soares pelo apoio e ensinamentos na área de estratégia de negócios.

Ao CNPq e à PUC-Rio, pelos auxílios concedidos, sem os quais este trabalho não

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 Comissão Examinadora.

Ao amigo Sérgio Côrtes pelo apoio dado, primeiro durante o Mestrado e depois

no percurso do Doutorado.

Aos amigos Fausto Maranhão 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 funcionários do Departamento pelos ensinamentos e

ajuda recebida.

Aos Professores Roberto Avila� e Agripino Garcia da UNMSM (Lima, Peru) pela

motivação para seguir estudos de pós-graduação no Brasil.

Resumo

Mamani-Macedo, Néstor Adolfo: Leite, Julio Cesar Sampaio do Prado, Macedo-Soares, Teresia Diana Lewe van Aduard de. Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio. Rio de Janeiro, 2003. 145p. Tese de Doutorado – Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro.

O presente trabalho é uma proposta para a criação de uma arquitetura geral

de memória corporativa. A mesma tem três camadas: fontes, middleware e

repositórios. Primeiro, criou-se um modelo conceitual de negócio baseado em

teorias de administração de negócios 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 repositório onde se

armazena informação relevante da organização, a qual é extraída a partir dos

sistemas legados, bancos de dados, sites na internet ou mesmo elicitadas dos seres

humanos por meio de entrevistas e formulários. O modelo conceitual está baseado

nas abordagens de análise estratégica positioning e emphasizing efficiency, junto

com a análise de funções e o estudo do gerenciamento da qualidade total.

Palavras-chave

Informática – Teses, Gestão do Conhecimento, Memórias Corporativas,

Modelos de Negócio, Sistemas de Informação, Ontologias e Agentes.

Abstract

Mamani-Macedo, Néstor 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 Informática, Pontifícia Universidade Católica 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.

Sumário

1. Introdução 15

1.1. Motivação 15

1.2. Problemas 19

1.3. Objetivo da Tese 23

1.4. Organização da Tese 26

2. Estratégia Proposta 28

3. Revisão da Literatura 31

3.1. Know More – Abecker et al. 31

3.2. Experience Factory – Basili et al. 32

3.3. AskMe Enterprise™ – AskMe Corporation 33

3.4. XpertRule Knowledge Builder � – Attar Software Limited 35

3.5. QuestMap™ – The Soft Bicycle Company 35

3.6. Avaliação das propostas e produtos 36

4. Referencial Teórico 40

4.1. Gestão do Conhecimento 40

4.1.1. Uma aproximação à definição de Conhecimento 41

4.1.2. O que é Gestão do Conhecimento 42

4.2. Estratégia de Negócios 44

4.2.1. A abordagem “positioning” ou de Estrutura-Conduta-Desempenho 45

4.2.1.1. O Modelo de Porter 45

4.2.1.2. O Modelo Ambiental 47

4.2.2. A abordagem “emphasizing efficiency” ou a que enfatiza a

eficiência 49

4.2.2.1. A visão “resource-based view” 49

4.2.2.2. O framework “dynamic capabilities” 51

4.3. A análise de processos e o TQM 52

4.4. As Metáforas de Morgan 53

4.4.1. A Organização vista como Máquina 54

4.4.2. A Organização vista como Organismo 54

4.4.3. A Organização vista como Cérebro 55

4.4.4. A Organização vista como Cultura 55

4.4.5. A Organização vista como Sistema Político 55

4.4.6. A Organização vista como Prisão Psíquica 56

4.4.7. A Organização vista como Fluxo e Transformação 56

4.4.8. A Organização vista como Instrumento de Dominação 57

4.5. Ontologias 57

4.5.1. Definições 58

4.5.2. Componentes de uma Ontologia 59

4.5.3. Tipos de Ontologia 61

4.5.4. Ontologia da Organização Empresarial 61

4.5.5. Métodos para a Descrição de Ontologias 63

4.5.5.1. TOVE (Toronto Virtual Enterprise) 63

4.5.5.2. Methodology for Building Ontologies 63

4.5.5.3. SENSUS 64

4.5.5.4. A Metodologia de Bernaras et al. 64

4.5.5.5. Methontology 65

4.6. Arquiteturas de Software 65

4.6.1. Definição 66

4.6.2. Características 66

4.6.3. O Processo de Criação de uma Arquitetura 67

4.6.4. Princípios Arquiteturais 67

4.6.5. Estilos Arquiteturais 68

4.7. A Tecnologia de Agentes 69

4.7.1. Agentes – Conceitos 70

4.7.2. Propriedades 71

4.7.3. Tipos de Agentes 72

4.7.4. Sistemas Multi-Agentes 74

4.7.5. A Arquitetura de um MAS 75

4.7.5.1. O Processo de Matchmaking 76

4.7.5.2. O Processo de Brokering 77

4.8. Metodologia MESSAGE 78

4.8.1. O Diagrama da Organização 78

4.8.2. O Diagrama do Domínio de Informação 79

4.8.3. O Diagrama de Meta/Tarefa 79

4.8.4. O Diagrama de Agente/Papel 79

4.8.5. O Diagrama de Interação 80

4.8.6. A Arquitetura do Agente MESSAGE 80

4.9. A Técnica do CBR 82

5. Resultados da Estratégia Proposta 84

5.1. A Ontologia Empresarial orientada à Estratégia de Negócios 84

5.1.1. Identificando o Propósito 85

5.1.2. O Nível de Formalidade 86

5.1.3. O Escopo da Ontologia 87

5.1.4. Criando a Ontologia 87

5.1.5. Avaliação 95

5.1.6. Documentação 95

5.2. O Modelo de Negócio – O Organizational Baseline 96

5.3. A Arquitetura Genérica do SCM (Strategic Corporate Memory) 100

5.3.1. A Camada de Fontes 102

5.3.2. A Camada Middleware ou de serviços 103

5.3.3. A Camada de Repositórios 104

5.4. Desenvolvendo a Arquitetura de Software (Middleware) 107

5.4.1. O Diagrama Organizacional do SCM 108

5.4.2. O Diagrama de Meta / Tarefa 109

5.4.3. O Diagrama Agente / Papel 113

5.4.4. O Diagrama de Interação 114

5.4.5. Estruturando os Resultados de acordo aos diagramas

organizacional, meta / tarefa, agente / papel e interação 115

5.4.6. O Diagrama de Domínio 116

5.5. Descrição dos Componentes da Arquitetura de Software 118

5.5.1. O Componente Agente Plataforma de Controle e Comunicação 121

5.5.1.1. O Facilitador de Diretorio (DF) 123

5.5.1.2. O Sistema de Gerenciamento de Agentes (AMS) 123

5.5.1.3. O Canal de Comunicação de Agentes (ACC) 124

5.5.1.4. A Comunicação de Agentes 124

5.5.1.5. Negociação de Agentes 126

5.5.1.6. Protocolos de Negociação 126

5.5.2. O Componente Agente Interface 127

5.5.3. O Componente Agente Usuário 131

5.5.4. O Componente Agente Descobrimento 133

5.5.5. O Componente Busca 136

5.5.6. O Componente Agente Armazenamento e Disseminação do LOG 138

5.5.7. O Componente Agente Armazenamento de Lições Aprendidas 140

5.5.7.1. Estruturando a Base de Experiências 141

5.5.7.2. Operações do Componente Agente de Lições Aprendidas 143

6. Apresentação do Protótipo 145

6.1. O Caso da Multicom 146

6.2. Os Serviços do SCM 146

6.2.1. Descrição do Protótipo: O Serviço de Busca 148

6.2.2. Descrição do Protótipo: O Serviço de Disseminação 152

7. Conclusões, Contribuições e Trabalhos Futuros 158

7.1. Conclusões 158

7.2. Contribuições 163

7.3 Trabalhos Futuros 164

8. Referências Bibliográficas 166

Lista de figuras

Figura 1.1 - Memória Organizacional 24

Figura 2.1 - Metodologia para o desenvolvimento da Arquitetura 28

Figura 2.2 - O Contexto do Organizacional Baseline 29

Figura 4.1 - A Organização e seus ambientes (adaptado de [Stoner85]) 44

Figura 4.2 - Cadeia do Valor 50

Figura 4.3 - Interação entre agentes no processo Marchmaking 76

Figura 4.4 - Interação entre agentes no processo Brokering 77

Figura 4.5 - Arquitetura em camadas do agente MESSAGE 81

Figura 5.1 - Ontologia da Organização e do Ambiente Organizacional 89

Figura 5.2 - Ontologia das Forças Competitivas e da Análise do Negócio 92

Figura 5.3 - Ontologia da Estratégia Global e dos Processos 93

Figura 5.4 - Ontologia das Funções 94

Figura 5.5 - Os conceitos da Ontologia do Negócio no Protégé 96

Figura 5.6 - O Arquivo RDF Schema da Ontologia (vista parcial) 98

Figura 5.7 - O Modelo E-R do Organizacional Baseline do SCM 99

Figura 5.8 - Arquitetura de Camadas do SCM 101

Figura 5.9 - Visão Arquitetural do Strategic Corporate Memory 103

Figura 5.10 - Visão Estrutural dos Repositórios 106

Figura 5.11 - Diagrama do SCM dentro da Organização 108

Figura 5.12 - Diagrama de Familiaridade do SCM 109

Figura 5.13 - Requisitos Não Funcionais do SCM 109

Figura 5.14 - Requisitos Não Funcionais: Precisão da Informação 110

Figura 5.15 - Requisitos Não Funcionais: Precisão da Escrita 110

Figura 5.16 - Requisitos Funcionais e Não Funcionais: Uma primeira

aproximação para a determinação dos Componentes do

SCM 111

Figura 5.17 - Tarefa: Elicitar Conhecimento 111

Figura 5.18 - Tarefa: Preparar o Questionário 111

Figura 5.19 - Outra Visão: Os serviços do SCM (requisitos funcionais) 112

Figura 5.20 - Diagrama Estrutural de Delegação 113

Figura 5.21 - Diagrama de Interação entre os agentes Extrator e Busca 114

Figura 5.22 - A Visão de Projeto do SCM 115

Figura 5.23 - A Visão de Domínio do SCM 116

Figura 5.24 - O Processo de Consulta do SCM 117

Figura 5.25 - O Processo de Disseminação Automática do SCM 117

Figura 5.26 - Os Componentes da Arquitetura de Software do SCM 119

Figura 5.27 - O Protocolo FIPA-iterated-contract-net 127

Figura 5.28 - O Componente Agente Interface 128

Figura 5.29 - O Componente Agente Usuário 132

Figura 5.30 - O Componente Agente de Descobrimento 135

Figura 5.31 - O Componente Agente de Busca 137

Figura 5.32 - O Componente Agente Armazenamento e Disseminação 139

Figura 5.33 - O Componente Agente Armazenamento de Lições

Aprendidas 144

Figura 6.1 - Uso do SCM 149

Figura 6.2 - Estrutura do repositório Ontologia do negócio 150

Figura 6.3 - Instâncias da Ontologia do negócio 150

Figura 6.4 - O Serviço de Busca 151

Figura 6.5 - Formulário da Entidade Companhia (Interface) 153

Figura 6.6 -Tela de Confirmação dos Dados Ingressados 154

Figura 6.7 - Registros log do SCM 155

Figura 6.8 - Estrutura do Arquivo LOG 155

Figura 6.9 - Estrutura da Tabela Usuário 156

Figura 6.10 - Instâncias de usuário 156

Figura 6.11 - e-Mail recebido pelo Consultor Sérgio Cortes 157

Figura 6.12 - e-Mail recebido pelo Gerente de TI Fausto Maranhão 157

Lista de Tabelas

Tabela 1.1 - Vantagens decorrentes do uso do conhecimento 21

Tabela 3.1 – Quadro Comparativo: Ferramentas de Gestão do

Conhecimento 38

Tabela 4.1 - Tipos de Agentes 72

Tabela 4.2 - Formas de consulta temporal de um agente 73

Tabela 4.3 - Funções dos agentes no processo Matchmaking 76

Tabela 4.4 - Funções dos agentes no processo Brokering 77

Tabela 4.5 - Conjunto de índices definidos para a medida sim 83

Tabela 5.1 - O conceito Companhia e as metáforas de Morgan 90

Tabela 5.2 - Uma Instância do Conceito Companhia 91

Tabela 5.3 - O Conceito Concorrência e as metáforas de Morgan 92

Tabela 5.4 Uma instancia do Conceito Concorrentes 93

Tabela 5.5 Conceito Objetivos 94

Tabela 5.6 Esquema Agente / Papel para o Agente Extrator 114

Tabela 5.7 Atos Comunicativos na Especificação FIPA 125

Tabela 5.8 Estrutura do Registro log 138

Tabela 5.9 Exemplo de um problema e seu contexto 142

Tabela 5.10 A Base de Casos, seus atributos e relevância dado o

problema 143

Tabela 5.11 Recuperação de um caso dado um problema 143

1 Introdução

1.1 Motivação

Como resultado da globalização da economia percebe-se que o ambiente

que rodeia as organizações está caracterizado pela mudança contínua de

regulamentações, tecnologia e mercado. Para acompanhar essas mudanças, as

organizações precisam evoluir rapidamente e com segurança. Entretanto, essa

evolução requer que estas saibam aprimorar a sua tomada de decisões nesse

contexto de turbulência, o que obriga a existência de informações confiáveis,

atuais e de fácil acesso aos tomadores de decisão. Para lidar com este ambiente,

Xu et al. (2003) propõem um sistema de radar corporativo para adquirir

informações estratégicas, porém não apontando questões da sua implementação.

Na literatura de estratégia de negócios (Alpander & Lee, 1995; Lewis, 1996;

Van de Ven & Poole, 1995; Vollman, 1996) existe o consenso de que a mudança

contínua necessita ser gerenciada com estratégias dinâmicas, o qual é enfatizado

por Day et al.(1997) quando ressalta a importância do “reconhecimento explicito

deste dinamismo na formulação da estratégia competitiva” . Uma visão estratégica

dinâmica passa por um adequado entendimento da concorrência atual e futura, e

pelo reconhecimento da influência ou do impacto, das ameaças e oportunidades

do ambiente externo sobre as organizações. As deficiências refletem-se nas

oportunidades que deixaram de ser atendidas e nos erros estratégicos cometidos.

É claro que a qualidade da tomada de decisões estratégicas está baseada na

qualidade da informação disponível. No entanto, existem dificuldades para que

uma organização possa disponibilizar a sua informação estratégica, de uma forma

estruturada e de fácil acesso, à diretoria e aos executivos, com o intuito de garantir

uma efetiva tomada de decisões. Isto se dá, principalmente, em função do fato de

que a informação é não-estruturada, de natureza crítica e em muitos casos, de

grande volume. Como resultado, faz-se necessário que as organizações possuam

modelos e ferramentas que facilitem tanto a aquisição e o armazenamento da

Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 16

informação, quanto seu compartilhamento e disseminação, 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 criação de

conhecimento. A premissa ou hipótese subjacente ao seu trabalho é que o

conhecimento humano é criado e expandido em termos de quantidade e qualidade

por meio da interação social entre o conhecimento tácito e o conhecimento

explícito. Obviamente, o conhecimento explicito é mais fácil de elicitar porque

está, em alguma medida, mais ou menos estruturado e pode ser encontrado em

bancos de dados de Recursos Humanos, Finanças, Contabilidade; o conhecimento

tácito é mais difícil de elicitar embora alguns tipos possam ser encontrados em

sistemas especialistas, sistemas de informação baseados em questões, arquivos de

melhores práticas ou de lições aprendidas (Abecker et al., 1998).

Tem-se notado também que muita informação e conhecimento relevantes

encontram-se dispersos na organização, seja em documentos impressos, meios

magnéticos ou simplesmente na “cabeça” dos seus membros, pela existência de

grupos formais e informais, dificultando seu acesso e disseminação oportuna.

Assim sendo, é crítico formular um modelo organizacional que inclua

“construtos” que possam ajudar a empresa a aprimorar sua tomada de decisões,

seu desenvolvimento organizacional e consequêntemente seu aprendizado. O

aprendizado organizacional refere-se às melhoras surgidas da experiência 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 revolução tecnológica, os requisitos

para que uma organização sobreviva e atinja o sucesso mudaram. Revalorizou-se

o papel do trabalhador na organização, 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

(competências e capacidades) para fazer as coisas através do conhecimento

adquirido por meio de treinamentos e da sua experiência no dia-a-dia. Ao mesmo

tempo, um número cada vez maior de empresas perceberam o quanto importante é

“saber o que elas sabem” e como aprender, para serem capazes de tirar o máximo

proveito de seus “ativos” de conhecimento. Assim, a capacidade de gerenciar,


disseminar e criar novos conhecimentos com eficiência, eficácia e economia é

fundamental para que uma organização se coloque em posição de vantagem

competitiva em relação aos seus concorrentes. Fica evidente que em um mercado

cada vez mais competitivo o sucesso nos negócios depende, basicamente, da

qualidade do conhecimento que a empresa possui. Nesse sentido, o conhecimento

institucionalmente organizado deve colaborar para uma melhora na tomada de

decisões, refletida na forma de ações político-econômicas e administrativas.

Por outro lado, cabe ressaltar que existem outras áreas do conhecimento

humano que também precisam desse tipo de informação e conhecimento, embora

com objetivos diferentes. A Engenharia de Software, em alguns casos, tem

apresentado sérios problemas de desenvolvimento, uma vez que alguns projetistas

“têm ignorado a importância das questões organizacionais no projeto de sistemas

de informação ... (assim)... muitas das dificuldades encontradas ocorreram, não

em função de limitações na tecnologia, mas em função do descaso com os

requisitos organizacionais” , (Dobson & Strens, 1994, p. 158). A crescente

importância das abordagens socio-técnicos para a elicitação dos requisitos de

informação é evidenciada pela literatura publicada nos últimos anos,

especialmente pelos artigos apresentados nas conferências 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 informação não pode ser reduzida a um processo racional

ou à produção de especificação técnica ... especialmente na atual turbulência

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 definição de requisitos

por meio da utilização de uma combinação de métodos, técnicas e ferramentas. A

definição 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 são obtidos os requisitos para definição dos sistemas de

informação e de software. Vale ressaltar, que antes de iniciar a elicitação de

requisitos de qualquer sistema é importante que o engenheiro de requisitos tenha


uma visão global da organização, enfatizando-se aspectos como o ambiente

organizacional, legislação, concorrência, etc., com o objetivo de visualizar suas

ligações com outros sistemas e com as estratégias e táticas da organização.

A seguir, é apresentado como as diferentes definições de Engenharia de

Requisitos salientam a relevância do contexto do sistema, reconhecendo o

envolvimento dos aspectos técnicos e sociais, explicita ou implicitamente (Jirotka

& Goguen, 1994):

Sommerville (1989) diz que a aquisição e análise de requisitos é o “processo de

estabelecer os serviços que o sistema deve fornecer e as restrições sob as quais

deve operar” .

Davis (1990) sugere que a Engenharia de Requisitos é a “análise, documentação e

evolução contínua das necessidades do usuário e do comportamento externo do

sistema a ser criado”.

Goguen (1992) declara que os requisitos são “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 definição de requisitos ocorre em um

contexto, denominado o Universo de Informações (UdI), que é “o contexto no qual

o software será desenvolvido e operado”.

A informação do contexto está embutida nas estruturas, rotinas e

procedimentos da organização; 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 questão

em Imagens da Organização. Acredita-se que os esforços envolvidos para a

elicitação dessa informação são valiosos, pois o que se procura é aprimorar a

elicitação de requisitos organizacionais, bem como os requisitos funcionais e não

funcionais, melhorando assim o processo de desenvolvimento dos sistemas de

informação.

Carroll (1997) observa que é necessário reconhecer que o problema básico

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 (estratégico, organizacional, financeiro, operacional,

tecnológico, comercial e ambiental). Nessa linha de pensamento, Jarke et al.

(1998) apresentam uma proposta interessante, vinculando os aspectos


organizacionais (políticas e metas) aos requisitos nos níveis estratégico, tático e

operacional, usando cenários. É de supor que a existência de um modelo

organizacional de negócio possa ser de grande ajuda na elicitação de requisitos,

em particular dos requisitos organizacionais. Esse modelo de negócio seria a base

para a criação de um baseline organizacional onde se armazenasse esse tipo de

informação. O baseline é na realidade um repositório de conhecimento, fazendo a

função de uma memória organizacional.

1.2 Problemas

Diversos autores, com perspectivas diferentes, salientam a importância da

organização dispor de informações estratégicas, tanto do ambiente externo e

interno como de suas competências e experiências, com o propósito de auxiliá-las

no desenvolvimento de adequadas estratégias de negócios em ambientes de

mudança contínua, disseminação do conhecimento e elicitação de requisitos

organizacionais. Essa preocupação pela gestão desses ativos intangíveis é

compartilhada tanto pela área de negócios como da engenharia de software, pois

ambas estão interessadas em possuir informações e conhecimentos relevantes

sobre a organização. No nosso ponto de vista, o conhecimento quando elicitado e

armazenado transforma-se em informação; essa premissa norteia o presente

trabalho.

A gestão dos ativos intangíveis é chamada na literatura de Gestão do

Conhecimento. Embora não exista uma definição exata, um entendimento ou

conceituação bastante difundido é que a gestão do conhecimento é o processo

através do qual as organizações geram valor a partir de seus ativos intelectuais e

de conhecimento, onde conhecimento, em uma visão restrita, pode ser definido

como o “know-how” que possui a organização, o qual reflete-se nas suas

habilidades e capacidades, as mesmas que vão lhe ajudar a atingir uma vantagem

competitiva sustentável. No entanto, é importante ressaltar que o conceito de

gestão do conhecimento tem um sentido mais amplo, pois envolve tanto aspectos

gerenciais, os quais não serão tratados aqui, como aspectos tecnológicos, é o caso

das ferramentas que podem ser utilizadas para ajudar na obtenção do sucesso


dessa gestão. Na literatura (Souza, 2002) encontram-se algumas definições de

gestão do conhecimento, as quais são destacadas a seguir:

Sveiby (1997) diz que “gestão do conhecimento é o nome dado ao conjunto de

práticas que visam à manutenção do conhecimento nas organizações”.

Murray (1996) declara que a gestão do conhecimento é “uma estratégia que

transforma bens intelectuais da organização – informações registradas e o talento dos seus

membros – em maior produtividade, novos valores e aumento de competitividade”.

Malhotra (2002) define a gestão do conhecimento como: “Uma visão, baseada no

conhecimento dos processos de negócio da organização, para alavancar a capacidade de

processamento de informações avançadas e tecnologias de comunicação, via

transformação da informação em ação por meio da criatividade e inovação dos seres

humanos, para afetar a competência da organização e sua sobrevivência em um crescente

de imprevisibilidade”.

Por outro lado, estudiosos do nível de Davenport & Prusak (1998) também

não definem o termo gestão do conhecimento, mas declaram que as atividades

principais desta são a criação, o acúmulo e a transferência do mesmo. Liebowitz

(1999) define a transferência como o ato de transformar experiências e know-how

de pessoas e grupos em conhecimento organizacional.

Uma forma de operacionalizar o processo de Gestão do Conhecimento é

mediante a criação de um Sistema de Gestão do Conhecimento, o qual é definido

pela Gartner Group (1998) como: “um processo e uma infra-estrutura que visam

apoiar a geração, coleta, assimilação e utilização ótima do conhecimento” . A

primeira parte dessa definição esta orientada à gestão administrativa e a segunda

aos recursos utilizados, sendo um deles as pessoas envolvidas e o outro as

tecnologias de informação utilizadas. Entre as tecnologias temos a criação de

ferramentas que ajudem ao suporte de todo esse processo.

Embora seja conhecida e aceita a importância de saber como manter,

gerenciar e compartilhar o conhecimento, poucas organizações contam com um

adequado sistema de gestão do conhecimento estratégico, o qual inclua um

instrumento que faça a função de memória organizacional, pois os sistemas

existentes são na maioria dos casos aplicações de suporte aos processos de

negócio ou aos seus processos de apoio. No entanto, nos últimos anos, algumas

grandes empresas de porte como Xerox, Ford, Buckman Labs, Texas Instruments,


Hoffman-LaRoche e Honeywell têm começado a usar seu ativo mais valioso e até

então sub-utilizado: o conhecimento coletivo dos seus empregados, através 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 esforços estão orientados basicamente ao conhecimento

operacional e, em alguma medida, ao nível tático, mas dando pouca importância

ao aspecto estratégico (AskMe, 2001).

Companhia Explicação Resultados nos Processos

Xerox Acesso às lições aprendidas

dos técnicos

5-10% poupança nos custos de mão de obra e

suprimentos (componentes)

Ford Acesso às melhores práticas US$ 1.25 bilhão em poupança

Buckman Labs

Permite aos empregados

encontrar colegas com

experiência e fazer perguntas

A venda de novos produtos aumentou em 50%.

Respostas às consultas dos clientes diminuiu a

horas, antes era contabilizado em dias

Texas Instruments

Acesso às melhores práticas Ganhos de US$ 500 milhões em um ano ao obter

uma capacidade de planta “ociosa”.

Hoffman- LaRoche

Captura e acesso a

conhecimento relacionado

previamente aprovado

O tempo de aprovação do FDA (Federal Drugs

Administration) reduziu-se de três anos a 9

meses.

Honeywell Cria, captura, compartilha e

utiliza conhecimento organi-

zacional

Aumento de 46% na taxa de propostas ganhas.

Os custos foram reduzidos em 35%

aproximadamente.

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

Todas essas condições impõem a necessidade da existência de uma memória

corporativa que esteja baseada em um modelo organizacional que permita

expressar os aspectos citados, principalmente os referentes a situações

estratégicas. No entanto, observa-se que a área de modelagem organizacional

carece de modelos que atendam essas características específicas. Uma forma de

satisfazer essa necessidade de contar com um instrumento de memória corporativa

que facilite o armazenamento e recuperação da informação estratégica é o

estabelecimento prévio de um modelo de negócio que envolva as questões

anteriormente referenciadas.

Na literatura de memórias corporativas (AskMe, 2001; Abecker et al., 1998;

Basili & McGarry, 1997; Attar, 2003; Gdss, 2003) percebe-se que estas têm

negligenciado ou dado pouca importância à utilização de modelos de negócio que


ajudem a lidar com essa problemática e atendam satisfatoriamente a esses

requisitos. Estes têm sido, fundamentalmente, repositórios de documentos e de

dados orientados aos processos. Vale enfatizar que a operacionalização de uma

memória corporativa não é uma tarefa trivial, pois conhecimento relevante tem

que ser identificado, modelado e armazenado.

No âmbito acadêmico, no entanto, têm-se desenvolvido algumas propostas

(Chiu, 2003; Fiorini et al., 1996), as quais, embora tenham utilizado muitos

conceitos disseminados pela mídia como Gerenciamento da Qualidade Total

(TQM-Total Quality Management), Reengenharia de Negócios e Planejamento

Estratégico, têm “ ignorado” a existência de abordagens mais especificas sobre

como as organizações se comportam e interagem com seu ambiente externo e

interno, e como esse conhecimento poderia facilitar a elicitação dessas entidades e

atributos relevantes à organização. Duas das abordagens mais conhecidas e

estudadas com certa ênfase no âmbito acadêmico e de negócios, são a de

posicionamento -“positioning” (Porter, 1980; Porter, 1985) e a que enfatiza a

eficiência – “emphasizing efficiency” (Day et al., 1997; Teece et al., 1997), as

quais tentam explicar, a partir de uma ótica estratégica, como as organizações

podem alcançar 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 exploração das existentes competências internas e

externas especificas à firma em ambientes de mudança contínua, salientando a

importância da gestão do conhecimento organizacional. Outra abordagem não

menos importante é a de Imagens da Organização (Morgan, 1996) a qual olha à

organização sob as metáforas de máquina, organismo, cérebro, cultura, sistema

político, prisão psíquica, fluxo-e-transformação, bem como de instrumento de

dominação.

Uma das vantagens de possuir uma memória corporativa como parte de um

sistema de gestão do conhecimento é que esta encoraja o aprendizado

organizacional. Isso é resultado do fato que a memória corporativa como um todo,

não só armazena construtos da área de negócios como também armazena lições

aprendidas, fazendo com que os membros da organização aprendam com a

mesma. Isto é corroborado por Tsang (1997) quando afirma que as “ lições

aprendidas no passado, se apropriadamente armazenadas na memória

organizacional, são uma importante fonte de conhecimento para que os membros


da organização possam obtê-la” . Nessa mesma linha Simon (1991) afirma que

“toda aprendizagem toma lugar dentro da cabeça do ser humano” e como uma

organização pode somente aprender por meio de seus membros, conclui que o

vínculo entre o aprendizado individual e organizacional ocupa uma posição crítica

em qualquer teoria de aprendizagem organizacional. Finalmente, Walsh &

Ungson (1999), declaram que a memória organizacional ou corporativa “se refere

à informação armazenada a partir da história da organização e que pode ser

recuperada para suportar decisões 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 série de fatores, tais como

os métodos usados para coletar e analisar os dados, o sistema de interpretação

existente na organização (Daft & Weick, 1984) e seu arcabouço ou “ frame” de

referência. (Shrivastava & Schneider, 1984).

1.3 Objetivo da Tese

Como descrito na seção anterior um sistema de gestão do conhecimento tem

dois componentes: o componente gerencial ou administrativo e o componente

tecnológico. Tem-se notado também, que embora as ferramentas de suporte ao

processo de gestão do conhecimento negligenciem os aspectos estratégicos

focando principalmente o aspecto operacional e o tratamento de documentos,

estas contribuíram para que as organizações alcancem resultados altamente

positivos. Por exemplo, só o acesso às melhores práticas pelos funcionários da

Ford, representaram economias de US$.1.25 bilhões segundo dados da AskMe

Corporation (vide Tabela 1.1).

O objetivo desta tese é propor uma arquitetura de memória corporativa com

ênfase nas questões estratégicas, daí o nome de Memória Corporativa Estratégica

(Strategic Corporate Memory – SCM), a qual leva em consideração a situação de

competitividade do mercado global. Argumenta-se que os avanços de modelagem

tanto na Engenharia de Software como na Engenharia de Requisitos, podem servir

de base para a proposta de uma arquitetura de Memória Corporativa adequada às

condições de mudança contínua.


A arquitetura do SCM terá como componente principal o Organizational

Baseline (Mamani-Macedo & Leite, 2001), o qual é o repositório de

conhecimento que visa satisfazer esse leque de necessidades de informação, com

estrutura baseada no modelo conceitual do negócio. A modelagem (abstração) do

modelo do negócio será conduzida tendo como fonte de inspiração as diferentes

abordagens da análise estratégica, notadamente as visões “positioning” (Porter,

1980; Porter, 1985) e “emphasizing efficiency” (Day et al., 1997; Teece at al.,

1997), utilizando-se, portanto, uma visão integrada dessas propostas e enriquecida

com uma análise dos processos e funções sob uma orientação de qualidade total e

das metáforas sobre as imagens da organização (Morgan, 1996). Junto ao baseline

organizacional também será criado um repositório de casos com experiências

passadas. Ambos repositórios facilitarão, assim, o compartilhamento do

conhecimento e experiências em todos os níveis hierárquicos da organização,

promovendo tanto a criação de novo conhecimento como a melhora das

habilidades e capacidades de seus membros, conforme apresentado na Figura 1.1.

Figura 1.1 Memória Organizacional

Para a organização do modelo do negócio 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 especificação da conceituação do

conhecimento de um domínio (Gruber, 1993). Na presente tese, cada uma das

visões representa um ponto de vista da organização, de cuja análise obtiveram-se

Competitiva Estratégia Dinâmica

Disseminação do

Conhecimento Organizational

Baseline

Organização Tomada de

Decisões

Elicitação de Requisitos

Informação estratégica (cultura, DO, TQM pensamentos, atitudes, valores, ambiente) estruturada e não estruturada, obtida do ambiente externo e interno

Case Base

DO: Desenvolvimento Organizacional TQM: Total Quality Management (Gerenciamento da Qualidade Total)


ontologias parciais do negócio, pois cada visão traz um conhecimento embutido

na mesma. Essas ontologias parciais, como dito antes, foram enriquecidas com a

análise de funções e processos, e com as metáforas de Morgan. Da integração de

todas elas obteve-se o Organizational Baseline.

Como o SCM vai armazenar informações do tipo estratégico e em alguns

casos informações de tipo tático e operacional quando relevantes, seu público alvo

são tanto os membros da alta direção das empresas, gerentes de linha, executivos e

analistas de negócio da área de gestão administrativa, bem como os engenheiros

de requisitos e de software na área de informática. Os primeiros, que ocupam

cargos gerenciais, com o propósito de satisfazer questões de negócios e os

segundos, engenheiros de requisitos e de software, com a intenção de que o SCM

contribua a elicitação de requisitos organizacionais, pois como se sabe todo

sistema de software tem um componente tecnológico e social (Jirotka & Goguen,

1994). As questões que a ontologia empresarial tenta responder são as referentes

à estratégia de negócios, processos e funções, com o intuito de que esse

conhecimento possa ajudar a melhorar a competitividade das organizações em

ambientes de mudança contínua, assim como aprimorar o conhecimento

organizacional dos engenheiros de requisitos e de software. Estratégias sobre

como o SCM pode ser vinculado aos requisitos dos sistemas de aplicação podem

ser encontradas em Fiorini (1995) e Mamani-Macedo (1999).

Para a implementação 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 características

exigidas pelo SCM, tais como, aparente inteligência, habilidade social, capacidade

de aprendizado, adaptabilidade e capacidade de tomada de decisões orientada às

metas. Estas características são coincidentes com os mecanismos de varredura

(scanning): sensor, filtragem, prova e rejeição, que propõe Xu et al. (2003) para

um sistema de radar corporativo.

Finalmente, as contribuições de nossa pesquisa são:

• Criação de um modelo conceitual de negócio baseado em teorias da

administração, que sirva de base para a estruturação do Organizational

Baseline, repositório principal da memória corporativa estratégica;


• Criação de uma arquitetura de software de memória corporativa

estratégica em três camadas: fontes, serviços de software e repositórios;

• Apoiar a operacionalização de um sistema de gestão de conhecimento

fornecendo uma arquitetura de ferramenta de memória corporativa que

implemente as características requeridas pelo SCM, tais como aquisição,

armazenamento, compartilhamento e disseminação.

A arquitetura será validada, por meio de um protótipo onde será mostrado as

vantagens da proposta apresentada, em particular as características de aquisição,

busca e disseminação. Para povoar os dados do protótipo será utilizado um estudo

de caso extraído do livro Imagens da Organização de G. Morgan (1996), com o

protótipo e esses dados estaremos mostrando que os objetivos propostos foram

atingidos, pois, como dito antes, serão apresentados além da aquisição duas das

características principais de nossa proposta de arquitetura, os serviços de busca e

disseminação.

1.4 Organização da Tese

A tese está organizada da seguinte forma:

Neste capítulo foram apresentadas as motivações para a pesquisa, seus

objetivos, as questões consideradas como tópicos em aberto no contexto das

memórias corporativas (problemas), as contribuições esperadas para resolver

algumas destas questões e, finalmente esta seção sobre a organização da tese.

No Capítulo 2, será apresentada a metodologia utilizada, tanto aquela

empregada na criação do Organizational Baseline como aquela utilizada na

construção da arquitetura.

No Capítulo 3 serão apresentados os resultados relevantes da revisão da

literatura sobre memórias corporativas, tanto as propostas surgidas no meio

acadêmico como na indústria. Neste último caso, mostraremos alguns produtos

que existem no mercado, pertinentes à de Gestão do Conhecimento.

No Capítulo 4 é explicado o referencial teórico utilizado, incluindo todas as

definições conceituais que consideramos necessárias para o desenvolvimento do

presente trabalho, tais como: as teorias de estratégia de negócios (abordagens


“positioning” e “resource-based view”) e as metáforas de Morgan; a conceituação

da Gestão do Conhecimento, a tecnologia de ontologias (utilizada para organizar

os construtos extraídos do passo anterior) e a abordagem de agentes (para a

implementação de nossa proposta).

No Capítulo 5, são apresentados os resultados da pesquisa, destacando-se

(1) o Modelo de Negócio base do Organizational Baseline; (2) a arquitetura

proposta com sua representação gráfica, funcionalidades e componentes; e (3) a

especificação dos agentes de software com sua representação gráfica e sua

documentação.

No Capítulo 6, é apresentado uma visão do protótipo desenvolvido para

demonstração de nossa tese.

Finalmente, o capítulo 7 contem uma síntese das contribuições, sugestões

para trabalhos futuros e algumas considerações finais.

2 Estratégia Proposta

Entende-se por estratégia um plano de ação ou método cuidadosamente

trabalhado com o intuito de atingir um determinado objetivo. Assim, uma

representação diagramática da metodologia utilizada nesta fase é apresentada, a

seguir, na Figura 2.1:

ER: Entidade-Relacionamento

Figura 2.1 Metodologia para o desenvolvimento da Arquitetura

As etapas de nossa estratégia ou metodologia para construção da arquitetura

proposta são descritos a continuação:

• Analisar

O primeiro passo foi analisar e estudar as teorias pertinentes à análise

estratégica, necessárias para a elicitação de “construtos” relevantes à organização.

Para este fim, foram utilizadas as seguintes teorias da administração de negócios:

• a gestão do conhecimento nas suas vertentes gerencial e tecnológica;

• as visões “positioning” e “ emphasizing efficiency” para a análise estratégica;

• a análise de funções e processos;

• o gerenciamento da qualidade total (Total Quality Management - TQM) e,

em forma ortogonal a todas as anteriores;

• as metáforas de Morgan.

CRIAR

ANALISAR

Teorias de Administração

Tecnologia de Ontologias

PROJETAR

Ontologia do Negócio

Modelo ER

Organizational Baseline

Tecnologia Agentes

Arquitetura da Memória Corporativa

IMPLEMENTAR Protótipo


A organização de tais “construtos” foi feita por meio da utilização da

tecnologia de ontologias.

• Criar

O segundo passo foi o de criar um modelo de negócio como base para a

construção do repositório de conhecimento, denominado o Organizational

Baseline (Mamani-Macedo & Leite, 2001), o qual tinha que incluir informações

estratégicas, táticas e operacionais relevantes, sejam estes, conhecimentos tácito

ou explícito e o armazenamento de casos de experiências passadas. Para a

construção do Organizational Baseline utilizou-se a visão 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 execução dos processos,

como por efeito do feedback como decorrência de mudanças no ambiente,

manutenção do baseline.

Figura 2.2: O Contexto do Organizacional Baseline

Na figura apresentada mostra-se ambas evoluções, do processo fornecendo

indicadores, e das áreas funcionais que são permeadas pelas mudanças no

ambiente. Ao mesmo tempo mudanças nas áreas funcionais afetam os processos,

originando novas versões destes, afetando a informação contida no baseline.

Ambos eixos, são enriquecidos pelo feedback (retroalimentação) contínuo. Desde

outra ótica, os processos em tempo de execução originam informações e

Organizational Baseline (Strategic Corporate Memory)

Feedback

Área 1 Área 2 Área 3

Processo

Versão

Tempo de Execução Tempo de Manutenção


experiências que devem ser capturadas no baseline. A figura mostra, também, que

a mudança contínua do ambiente causa que o baseline necessite de uma

manutenção dinâmica.

• Projetar

O terceiro passo foi de projetar a arquitetura genérica do SCM, a qual foi

desenvolvida em três camadas: de fontes, middleware ou de serviços de software e

de repositórios. A arquitetura proposta também 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 protótipo com a aplicação da arquitetura da

memória corporativa, o qual incluiu o módulo de busca e o módulo de atualização

do Organizational Baseline, tendo entre as suas funcionalidades as de criação do

log da aplicação, a atualização dos indexes (tanto do log como de leitura do log –

ponteiro de posicionamento) e a disseminação dessas mudanças entre os usuários

previamente cadastrados e que precisam desse tipo de informação.

O protótipo foi desenvolvido utilizando-se a linguagem de programação Java,

como banco de dados utilizou-se o sistema de armazenamento relacional MS-

Access. Os dados utilizados para efeitos de mostrar o funcionamento do protótipo

foram extraídos e adaptados de um estudo de caso apresentado por Morgan

(1996).

3 Revisão da Literatura

No meio acadêmico e na indústria têm-se desenvolvido diversas propostas e

produtos de memórias corporativas como uma forma de operacionalizar a gestão

do conhecimento. Entre os exemplos oriundos do meio acadêmico podemos citar:

o Know More de Abecker et al. (1998) e a Fábrica de Experiências 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 descrição de todos esses

sistemas assim, como uma avaliação e comparação entre os mesmos.

3.1 Know More (Abecker et al., 2003)

Esta proposta está orientada ao usuário que executa tarefas de conhecimento

em um processo organizacional. Em geral, as tarefas de conhecimento, também

chamadas de tarefas intensivas em conhecimento, são complexas, difíceis e

importantes por natureza e para a sua execução é necessária a participação de

especialistas que possuam tanto habilidades quanto capacidades. Entre as

capacidades se destaca o conhecimento. Dadas as características destas tarefas,

uma completa automação, ou mesmo uma partilha em subtarefas é usualmente

não factível, uma vez que não existe nenhuma seqüência de tarefas

predeterminadas, que se executadas, garanta o resultado desejado.

Para lidar com esta problemática, a abordagem de Abecker et al. modela e

executa os processos e tarefas, atuando assim sobre o nível de aplicação. Logo,

quando um trabalhador reconhece uma necessidade de informação, uma consulta à

memória organizacional (OM) é realizada. A abordagem tem outros dois níveis, o

nível de objetos, que está caracterizado por uma variedade de fontes heterogêneas

de informação e o nível de descrição de conhecimento, que permite o mapeamento

do nível de aplicação ao nível de objetos, utilizando-se de três tipos de ontologias:

ontologia da empresa (estrutura empresarial), ontologia do domínio (específico ao


tema sob estudo) e ontologia da informação (genérico às fontes de informação -

documentos). Vale ressaltar, que esta proposta está orientada à recuperação de

documentos e à localização de pessoas especialistas em um determinado tópico.

3.2 Experience Factory (Basili et al., 1997)

Esta abordagem define um “ framework” para o gerenciamento de

experiências e reconhece a necessidade da existência de um orgão separado que

trabalhe com a organização de projetos para o gerenciamento dessas experiências.

Esta proposta tem sido aplicada com sucesso nos projetos de desenvolvimento de

software da NASA por mais de 25 anos. O modelo da Fábrica de Experiências

esta alinhado à organização do projeto. Assim, os dados produzidos como

resultado da execução do planejamento do projeto são capturados pela fábrica de

experiências, para sua análise, síntese e empacotamento em uma base de

experiências, a qual vai dar suporte ao negócio quando forem planejados outros

projetos similares no futuro.

A fábrica de experiências permite tratar os seguintes tipos de problemas:

• Encontrar a pessoa adequada ou o “especialista” para solucionar um

problema;

• Criar modelos baseados na experiência para melhorar a estimativa de

custos;

• Identificar padrões e agir sobre eles;

• Capturar, organizar e disseminar lições aprendidas;

• Reusar todas as categorias ou tipos de experiência documentada, por ex.

propostas, orçamentos, etc.

Neste sentido, a Fábrica de Experiências faz uso de uma espécie de

Raciocínio Baseado em Casos (Case-Based Reasoning – CBR) (Wangenheim von

& Rodriguez, 2000), orientado ao domínio de Engenharia de Software.


3.3 O AskMe Enterprise™ - AskMe Corporation (AskMe, 2001)

Este produto é uma solução de software que oferece, segundo os seus

desenvolvedores, uma maneira comprovada para capturar, gerenciar e reutilizar o

conhecimento dos funcionários, bem como o armazenamento e recuperação de

experiências passadas na forma de documentos. Utiliza-se de uma série de

algoritmos para casamento probabilístico de padrões, busca de conhecimento e

inferência, com o intuito de:

• Compartilhar as melhores práticas da empresa;

• Promover a inovação, antes que a re-invenção;

• Incrementar a produtividade dos seus funcionários que realizam tarefas

intensivas em conhecimento;

• Melhorar a profundidade e amplitude das habilidades dos trabalhadores;

• Dar respostas rápidas a questões do negócio, melhorando a tomada de

decisões;

• Criar, automaticamente, uma base de conhecimento a partir do capital

intelectual existente visando ganhar uma vantagem competitiva

sustentável.

O objetivo amplo deste produto é ajudar as corporações a otimizarem a

entrega de conhecimento especifico ao domínio, em qualquer local dentro da

organização, quando procurado pelos funcionários, sem importar se esse

conhecimento já foi documentado ou não. Esta abordagem de entrega de

conhecimento específico ao problema é denominada de Gerência da Cadeia de

Conhecimento (KCM-Knowledge Chain Management). Usualmente, uma cadeia

de conhecimento é gerada quando os funcionários:

• se consultam entre si para resolver problemas de negócios;

• compartilham informação acerca dos processos internos ou dos

competidores externos;

• procuram informação na intranet; ou

• participam de reuniões formais com outros colaboradores.

Os objetivos específicos do AskMe Enterprise são:


(1) gerenciar e otimizar as cadeias de conhecimento para dinamizar os

processos internos e a tomada de decisões;

(2) equipar os funcionários com a informação que eles precisam para que

façam seus trabalhos eficientemente;

(3) capturar essas trocas de conhecimento de modo que o desempenho dos

funcionários possam ser melhorados no futuro.

A ferramenta AskMe Enterprise é formada por três camadas, sendo uma de

integração, outra de serviços e o repositório de dados.

A camada de integração, permite a ligação à atual infraestrutura de

tecnologia de informação e às aplicações existentes, como portais, máquinas de

busca e diretórios corporativos. Incluí ferramentas de conexão a essas aplicações,

bem como ao gerenciador de documentos, ao criador automático de perfis e aos

“plug-ins” de configuração, como por exemplo de e-mails.

A camada de serviços, tem como funcionalidades:

• A Mineração de Conhecimento: Permite aos gerentes de negócios fazer

inferências e tomar decisões, baseado no conhecimento compatilhado na

organização;

• O Compartilhamento de Conhecimento: Facilita o descobrimento de

soluções a problemas de negócios, fornecendo ferramentas que ajudam a

compartilhar eficientemente o “know how” e as melhores práticas dos

usuários;

• A Gerência de Aplicações: Permite que o público alvo (gerentes), faça o

gerenciamento de taxonomias de conhecimento, usuários e conteúdo,

assim como também sua condução e uso;

• A Administração do Sistema: Fornece as ferramentas para o

monitoramento e a manutenção do sistema.

A camada de repositório de dados é onde se armazena a taxonômia do

conhecimento, os perfis dos especialistas e os diversos documentos (textos,

artigos ou mensagens) que foram trocados entre os empregados.


3.4 XpertRule Knowledge Builder � – Attar Software Limited (Attar, 2003)

Trata-se de um ambiente para o desenvolvimento e uso de aplicações e

componentes baseados em conhecimento, incorporando regras, experiências,

“know-how”, procedimentos, políticas e regulamentos, sob o nome de “Regras de

Negócio” . Esta ferramenta tenta automatizar qualquer função (atividade) baseada

em conhecimento dentro da organização, como por exemplo:

• Fazer recomendações e dar conselhos sobre produtos, serviços e cursos

de ação, facilitando o compartilhamento de conhecimento e reforçando as

melhores práticas;

• Pesquisar defeitos nas aplicações de suporte e de ajuda aos clientes,

facilitando a captura do conhecimento dos defeitos e seus diagnósticos,

com o intuito de dar suporte aos usuários internos e clientes;

• Monitorar e Avaliar Condições e os seus Riscos, por exemplo na área de

manufatura e nos processos, onde poderia se detectar antecipadamente os

sinais de advertência de falhas;

• “Workflow”, as regras podem ajudar a decidir sobre as próximas ações e

tarefas, baseadas nos atuais eventos e na data disponível.

O “Knowledge Builder” utiliza para a representação dessas regras árvores

de decisão e tabelas de casos. As árvores de decisão estão relacionadas a um

resultado ou decisão, dado um conjunto de atributos. As tabelas de casos contêm

uma lista de exemplos ou regras mostrando como um resultado ou decisão se

relaciona a uma combinação de valores de atributos. A ferramenta permite que um

atributo dentro de uma árvore de decisão ou tabela possa ser representada por

outra árvore de decisão ou tabela. Esta representação é 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 usuário (telas) que capturam as questões e idéias-chave durante as


reuniões (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 conversação IBIS (Issue Based

Information System) de Conklin & Begeman (1987), o qual classifica

qualquer conversação em quatro elementos simples: questões, idéias,

prós e contras;

• Interface do Usuário: um sistema de software de hipertexto, o qual

suporta a estrutura do QuestMap;

• Banco de dados: Armazena os mapas de discussão prévios,

possibilitando a busca e navegação dentro desta base de conhecimento

informal.

3.6 Avaliação das propostas e dos produtos

A seguir se fará uma breve análise dos diferentes propostas e produtos de

memórias corporativas:

O “Know More” está orientado basicamente a suportar os processos de

negócio com tarefas intensivas em conhecimento. Este produto faz uso de

ontologias para mapear os processos aos objetos (repositórios de dados),

fornecendo os links de onde é possível encontrar informação relevante a essas

tarefas (documentos), não fornecendo informação específica. As ontologias ao

nível de tratamento da informação estão relativamente bem definidas, no entanto

as ontologias ao nível da estrutura empresarial e do domínio estão em alto nível de

abstração.

A Fábrica de Experiências 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. Não trata, por

exemplo, de informação do tipo estratégico.

O “AskMe Enterprise” , está voltada principalmente para a busca de

documentos e pessoas, não tratando de forma explicita tópicos estratégicos. Mas

os documentos ou as pessoas podem conter ou possuir esse tipo de informação.


O “XpertRule Knowledge Builder” , tenta formalizar as “regras de negócio”

sob a forma de árvores de decisão, capturando tanto conhecimento formal quanto

informal que possa ser representado em regras. Não trata também aspectos

estratégicos de uma forma estruturada.

O QuestMap é similar ao XpertRule ao tentar capturar o conhecimento

informal por meio de uma seqüência de passos, uma espécie de regras baseadas no

modelo de conversação IBIS. Como no caso do XpertRule não dão a devida

importância a questões estratégicas, pois só acessa seus próprios repositórios de

dados onde armazena os mapas de discussão.

Na Tabela 3.1 mostra-se um quadro comparativo das diferentes propostas

antes mencionadas. Nela observa-se que quase todas as ferramentas estão

orientadas principalmente ao nível tático. Isso não quer dizer que estas

ferramentas não tratem com aspectos estratégicos, senão que a ênfase não está

nesses aspectos. Nesse sentido, o SCM está orientado basicamente ao nível

estratégico, pela base teórica utilizada na criação do seu principal repositório, o

Organizational Baseline (OB). Encontra-se também que o KnowMore é a única

ferramenta que modela explicitamente os processos de negócio. Tanto a proposta

da Fabrica de Experiências como o SCM, se bem elicitam informações dos

processos não a tratam no detalhe do KnowMore.

De todas as ferramentas, a que melhor lida com as regras de negócio é o

XpertRule, o QuestMap utiliza uma espécie de regras a efeitos de tratar processos

de raciocínio. Nenhuma das ferramentas estudadas utiliza algum modelo de

negócio para armazenar informação estratégica, esta é a maior vantagem do SCM,

o qual operacionaliza esse modelo na forma de um repositório 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 domínio orientado à estratégia de

negócios. Todas as ferramentas de uma ou outra forma tratam com a gestão de

documentos, mas algumas delas estão restringidas aos documentos digitais que as

mesmas geram como é o caso do QuestMap e XperRule. Uma das características

do AskMe é a localização de pessoas, esta é parcialmente tratada pelo KnowMore

e a Fabrica de Experiências, a arquitetura do SCM considera esta característica

quando modela aos usuários.


Nenhuma das ferramentas estudadas faz gestão de conceitos de estratégia de

negócios, como se o faz o SCM, isto se deveria ao fato que todas elas não

consideram a existência de um modelo de negócio. Outra característica do SCM é

que esta é proativa, o AskMe na sua última versão introduz esta característica para

o caso das lições aprendidas. Finalmente, todas elas incluindo, evidentemente, o

SCM fomentam o aprendizado organizacional.

Memória Organizacional Academia Indústria

Características KnowMore Fab.Exp. AskMe XpertRule QuestMap SCMTM

Orientação . Usuários (nível tático) V V V V V + ou – 11 . Executivos e Eng.. de Requisitos + ou - 1 + ou – 2 + ou – 4a + ou – 6 + ou – 8 V Foco . Global (qualquer organização) V X V V V V . Especifico (Engen. de Software) V Modela . Processos e Tarefas V + ou – 3 X X X + ou - 12 . Toda a Organização X X X X X V . Regras de Negócio X X + ou – 4b V + ou – 9 X . Lições Aprendidas X V V X V V Faz uso de Ontologias com V X + ou – 4c X X V Ênfase em: . Gestão de documentos V V V + ou - 7 + ou – 10 V . Localização de pessoas V V V X X V . Gestão de conceitos X X X X X V Ferramenta . Proativa X X + ou – 5 X X V . Fomenta o aprendizado V V V V V V LEGENDA V: Cumpre a característica X: Não cumpre a caracter. + ou - : Cumpre mais ou menos a característica

Tabela 3.1 Quadro Comparativo: Ferramentas de Gestão do Conhecimento

1 Orientado aos usuários a nível tático-operacional, mas que fazem uso intensivo de

conhecimento. Portanto podem ser incluídos executivos de nível intermédio e eventualmente engenheiros de requisitos, quando o precisarem.

2 A Fabrica de Experiências é uma proposta orientada a capturar conhecimento na área de Engenharia de Software, portanto, focada a executivos dessa área.

3 Os processos não são tratados no detalhe como se são tratados pelo KnowMore. 4a Trata informação estratégica quando contida em documentos ou quando possuída pelos

funcionários. Fornece plug-ins para fazer vínculos com outros repositórios ou portais. 4b Regras simples que classificam as solicitudes de informação baseados na origem, contexto e

tempo esperado de resposta. 4c Estas podem disparar uma notificação ou encaminhar a solicitude a um determinado

especialista ou iniciar um processo de aprovação automatizado (por ex. de lições aprendidas). 5 Focado nas melhores práticas, a ferramenta comunica as pessoas interessadas, previamente

cadastradas, as atualizações havidas no repositório de lições aprendidas. Faz uso de taxonomias. 6 A ênfase esta no nível tático, mas pode ser, eventualmente, utilizado no nível estratégico

pelos executivos. 7 Documentos digitais gerados pela própria ferramenta. 8 Esta ferramenta é de grande utilidade para capturar conhecimento informal, embora tenha

uma orientação às regras, seu uso é adequado para capturar processos de raciocínio. 9 Não trata regras de negócio, mas bem captura os processos de raciocínio na forma de regras.


10 Faz gestão de documentos digitais gerados pela própria ferramenta. 11 A arquitetura está orientada ao nível executivo – estratégico, mas isso não impede, como

que deve ser, também ser utilizada nos níveis táticos. 12 Captura informações dos processos, indicadores e benchmarking, mas não com o detalhe do

KnowMore.

4 Referencial Teórico

Para a realização do presente trabalho foram utilizadas diferentes

abordagens provenientes de diferentes áreas do conhecimento. Primeiro, estudou-

se os conceitos e variações (viés) da gestão do conhecimento, nas suas vertentes

gerencial e tecnológica, dado que a criação de uma memória corporativa é uma

forma de operacionalizar o processo de gestão do conhecimento. A seguir, com

base na estratégia de negócios, analisou-se a escola estrutura-conduta-desempenho

(“positioning” – “modelo de Porter” e “modelo ambiental” ) e a visão que enfatiza

a eficiência (“emphasizing efficiency” – “resource-based view” e “dynamic

capabilities”). Estudou-se, também, a análise de funções e processos, o TQM

(Total Quality Management) e as metáforas de Morgan (1996), como elementos

base de onde elicitar os conceitos e atributos relevantes para a construção do

modelo de negócio da memória corporativa. Para modelar esse conhecimento

elicitado, empregou-se a tecnologia de Ontologias e o modelo de Entidade-

Relacionamento. Para a criação dos componentes de software que farão parte da

arquitetura utilizou-se a tecnologia de agentes. A seguir descreveremos cada uma

dessas teorias, visões, tecnologias e modelos, com o intuito de melhorar o

entendimento dos capítulos subseqüentes.

4.1 Gestão do Conhecimento

É um fato conhecido que na última década (anos 90) as organizações têm

reconhecido que o seu ativo mais importante são os seus funcionários, os quais

possuem o know-how ou conhecimento organizacional tácito. Assim sendo, é de

natureza crítica a elicitação desse conhecimento organizacional para torná-lo

explicito na organização. O conhecimento explicito mantém-se geralmente nos

manuais de procedimentos e funções da organização.

A seguir é apresentada uma breve explicação da área de gestão do

conhecimento, com base nos estudos realizados pelo grupo de Knowledge


Management (KM) da Graduate School of Business, University of Texas at

Austin (2003) (UT-Austin).

4.1.1 Uma aproximação à definição de Conhecimento

De acordo com a definição encontrada no Merrian-Webster's Dictionary

(Merrian Webster, 2003), conhecimento (1) é o fato ou condição de conhecer

alguma coisa com a familiaridade adquirida com a experiência ou associação

cognitiva, (2) entendimento de uma ciência, arte ou técnica. (3) o fato ou a

condição de estar ciente de algo, (4) a soma daquilo que é conhecido: o corpo das

verdades, informações e princípios adquiridos pela humanidade. O conhecimento

pode, também, ser descrito como um conjunto de modelos que descrevem várias

propriedades e comportamentos dentro de um domínio específico. O

conhecimento, assim, pode estar registrado no cérebro da pessoa ou armazenado

nos processos organizacionais, produtos, sistemas e documentos. A definição de

conhecimento estabelecida pelo grupo de KM da UT-Austin, afirma que

conhecimentos são “as idéias ou entendimentos que uma entidade possui,

utilizadas para a tomada de uma ação efetiva com o intuito de atingir os objetivos

da entidade”. Este conhecimento é especifico a entidade que o criou. Uma

organização ou suas áreas funcionais são exemplos de entidades.

Atualmente, em função da rápida mudança no ambiente organizacional das

empresas, resultante principalmente, das inovações tecnológicas nas

comunicações, o conhecimento tornou-se, na prática, o único recurso para a

obtenção de vantagens competitivas sustentáveis. Portanto, este ativo deve ser

elicitado, armazenado, protegido, cultivado e compartilhado entre os membros da

organização. A empresa que aproveitara seu capital intelectual pode aplicar esses

ativos intangíveis aos desafios e oportunidades do negócio que se

apresentarem. Assim, a adequada utilização do conhecimento organizacional

(explicito e implícito) junto com o potencial das habilidades individuais,

competências, pensamentos, inovações e idéias permitirão que a organização

possa competir mais efetivamente.

É evidente que muito conhecimento vital do funcionamento das empresas

estão com os indivíduos da organização, e que o grande desafio é torná-lo

disponível. Mas ao mesmo tempo, muitas companhias não percebem que possuem


sua própria “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 gestão do conhecimento envolve,

necessariamente, não apenas compromissos ou aspectos gerenciais, como

também, recursos financeiros para torná-la viável, seja na forma de um programa

de desenvolvimento organizacional que motive o compartilhamento do

conhecimento entre seus membros ou mediante o desenvolvimento ou aquisição

de ferramentas que suportem o processo de gestão de conhecimento.

4.1.2 O Que é Gestão do Conhecimento ?

Gestão do Conhecimento é o processo de encontrar, elicitar, selecionar,

organizar, armazenar, proteger, compartilhar, disseminar e apresentar o

conhecimento em uma forma que melhore a compreensão em determinada área de

interesse. A gestão do conhecimento ajuda a organização a ganhar intuição e

entendimento a partir de sua própria experiência. As atividades de gestão do

conhecimento contribuem para que a organização se foque na aquisição,

armazenamento e utilização do conhecimento na solução de problemas, no

aprendizado organizacional dinâmico, no planejamento estratégico e na tomada de

decisões. Também protege aos ativos intelectuais de sua deterioração, bem como

agrega inteligência à organização, fornecendo-lhe uma crescente flexibilidade.

Em muitas empresas têm-se constatado que estas “não sabem o que elas

sabem". Essa situação pode conduzir à duplicação de esforços, consumindo tempo

e dinheiro. Assim, deduz-se que as organizações devem perguntar a si mesmas

duas importantes questões: (UT-Austin, 2003)

(1) Quais são nossos ativos de conhecimento?

(2) Como devemos gerenciar esses ativos para obter o máximo retorno?

Segundo o grupo de KM da UT-Austin, não existe uma resposta certa ou

errada a essas questões. Esta depende de diferentes fatores, como o tipo de

organização, sua cultura e suas necessidades específicas. No entanto, uma efetiva

gestão do conhecimento foca-se em soluções que envolvam a empresa como um

todo, incluindo a sua organização, pessoas e tecnologia. É evidente que os


computadores e os sistemas de comunicação são adequados na captura,

transformação e distribuição do conhecimento altamente estruturado,

independente da sua dinâmica ou evolução. Portanto, a tecnologia alavanca uma

adequada gestão do conhecimento na organização, podendo esse conhecimento

ser utilizado para aprimorar sua tomada de decisões, alocar recursos, gerenciar

sistemas, acessar e promover o processo de elicitação do know-how, tudo isso

com o intuito de aprimorar o seu desempenho global e como uma maneira de

desenvolver seu núcleo de competências estratégicas distintivas. Assim, qualquer

organização pode efetivamente usar a gestão do conhecimento para se

desenvolver e melhorar seu desempenho, controle e efetividade.

Uma das abordagens da análise estratégica que estuda o uso dos recursos

intelectuais (competências) como uma forma de obter vantagem competitiva é o

“resource-based view”, a qual é enfatizada pelo framework das “capacidades

dinâmicas” (dynamic capabilities), que é uma evolução da baseada em recursos,

esta argumenta que não basta acumular ativos de conhecimento, pois o

importante é que a organização tenha a capacidade de gestão destes para

coordenar e recolocar efetivamente as competências internas e externas (Teece,

1997). O termo “dinâmico” , refere-se à capacidade da organização de renovar as

suas competências, de forma a atingir uma congruência com as mudanças que

acontecem no ambiente de negócios. O termo “capacidades” , enfatiza o papel

chave da gestão estratégica na adaptação, integração, e re-configuração das

habilidades, recursos e competências funcionais organizacionais, internas e

externas, para casar com os requisitos de um ambiente em mudança contínua. Um

aspecto estratégico é a identificação e o desenvolvimento de competências difíceis

de imitar ou copiar, as quais suportem a criação de produtos e serviços valiosos.

Em outras palavras, o objetivo é como obter vantagem competitiva por meio

dessas competências distintivas.

A implementação da gestão do conhecimento nas organizações tem duas

vias, uma gerencial vinculada à gestão, desde o ponto de vista administrativo, e

outra tecnológica, a qual busca operacionalizar o processo de gestão do

conhecimento por meio de sistemas e ferramentas de software, as quais suportem

as atividades de elicitação, seleção, refinamento, compartilhamento e

disseminação oportuna aos membros da organização, quando necessitado. Uma

forma de operacionalizar o processo de gestão do conhecimento é por meio da


criação de um sistema de memória corporativa orientado à estratégia de negócios,

o qual possuía os repositórios necessários para armazenar os ativos intelectuais da

organização.

4.2 Estratégia de Negócios

A escolha de uma estratégia de negócios é uma tarefa necessária para a

formulação de qualquer estratégia global de negócios. No desenvolvimento de um

plano estratégico, no entanto, podem-se encontrar os seguintes problemas:

• Incerteza no ambiente;

• Falta de informação;

• Informação pouco confiável;

• Falta de uma equipe suficientemente preparada.

de Atividade Empresarial Processos

I nterfuncionais

Rec.Humanos Logística/ Produção

Marketing

Finanças

Órgãos de Apoio

Concorrência Clientes

Fornecedores Novos Concorrêntes

Empresas de Produtos Substitutos

Forças Competitivas no Setor

da Atividade Empresarial

Aspecto Sócio - Cultural

Aspecto Tecnológico

Aspecto econômico

Aspecto Político

AM BIENTE INDIRETO

AM BIENTE DIRETO INTERNO

AM BI ENTE

Figura 4.1 A Organização e seus ambientes - adaptado de Stoner (1986)

O primeiro passo do planejamento estratégico é a análise do ambiente

indireto, o segundo, é a análise do ambiente direto, que inclui a análise do setor

onde esta desenvolve suas atividades operacionais, e o terceiro, é a análise do

micro ambiente, vide Figura 4.1. Os dois primeiros passos levam à determinação

das oportunidades e dos riscos do negócio e o terceiro conduz à determinação dos

pontos fortes e de melhoria da empresa. Como conseqüência da análise destes

resultados, define-se ou redefine-se a atividade empresarial da organização. Em

todos os níveis está presente o conceito de qualidade em seu senso mais amplo de


busca de melhoria contínua de todos os produtos e processos da empresa dentro de

um enfoque estratégico, o qual muitos chamam de qualidade total. Baseada em

Mamani-Macedo et al. (1992) e Aybar et al. (1989).

Esse processo de planejamento estratégico pode ser realizado de acordo

com, pelo menos, duas abordagens distintas de gestão estratégica de negócios: as

visões “positioning” (estrutura-conduta-desempenho) e de “emphasizing

efficiency” (enfatizando a eficiência), a primeira, orientada à análise 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 visão afirmam que o desempenho da organização está

influenciada, basicamente, pela estrutura da indústria, a qual delineia uma conduta

(estratégia) que se reflete no desempenho da indústria, em geral, e da organização

em particular. Destacam-se dois modelos:

4.2.1.1

O Modelo de Porter

Baseado na teoria da organização industrial de Mason (Chabert, 1998),

enfatiza a importância da análise da estrutura da indústria para o melhor

entendimento da estratégia da organização e do seu desempenho. Porter

argumenta que o grau de competição na indústria, vai além do comportamento dos

seus próprios competidores. Assim, propõe que a análise estratégica seja baseada

nas seguintes cinco forças competitivas: da concorrência, a das empresas com

produtos substitutos, a dos clientes (compradores), a dos fornecedores e os

possíveis novos concorrentes, chamados de novos entrantes. Esta análise é

denominada por Porter, como a Análise das Forças Competitivas, conforme

explicada no seu livro Estratégia Competitiva (Porter, 1980). Porter também

ressalta a importância da análise do setor, dai sua inclusão no modelo de negócio

proposto.

a) Análise do Setor: A análise setorial, tem por objetivo estabelecer as

características principais do setor para o qual se orienta a empresa, em


termos de exploração ou produção. Por exemplo, de que maneira o setor

ao qual pertence a empresa está contribuindo para o desenvolvimento do

país? Quais políticas 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

análise do setor pode-se realizar ou dar sob os seguintes aspectos:

importações, exportações, investimentos estrangeiros e transferência

tecnológica.

b) Clientes: Deve analisar-se tanto os atuais clientes como, também, aos

potenciais clientes e às condições 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 negociação frente

a seus fornecedores e, portanto, podem influir na rentabilidade potencial

da empresa. Assim, estes podem forçar a diminuições de preços, maiores

serviços e melhores condições de pagamento.

c) Fornecedores: Os fornecedores são os que provêm bens ou serviços à

organização, e têm também um poder sobre esta, o qual pode-se refletir

na possibilidade de aumentar seus preços, 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,

através de seus produtos/serviços, são a entrada para o processo de

transformação que realiza a empresa, para logo oferecer o resultado deste

aos seus clientes.

d) Concorrência: O objetivo da análise do concorrente é desenvolver um

perfil da natureza e do sucesso das mudanças de estratégia, que cada

concorrente fez no passado e que poderia fazer no futuro; da provável

resposta de cada concorrente à gama de possíveis movimentos

estratégicos que outras empresas pudessem iniciar e; a reação provável

de cada concorrente frente às mudanças que no setor e no entorno

pudessem acontecer. Existem quatro componentes básicos para o

diagnóstico de um concorrente: os seus objetivos futuros, os seus

supostos de atuação (premissas), a sua estratégia atual e as suas

capacidades.


e) Produtos Substitutos: Os produtos substitutos são os produtos que

desempenham a mesma função para o mesmo grupo de consumidores,

mas que se sustentam em uma tecnologia diferente. Os riscos de

ingressos de produtos substitutos depende de duas condições:

• quando é mais atrativo o preço comparativo do produto substituto;

• quando os custos pela mudança do produto da indústria por seu

substituto são relativamente baixos.

A presença de produtos substitutos está determinada pelas inovações

tecnológicas resultantes de trabalhos de pesquisa e desenvolvimento que se

realizam permanentemente na indústria.

f) Novos Entrantes: São aquelas empresas que estão prestes a ingressar no

mesmo setor onde a organização desenvolve suas atividades

empresariais, e que esta não conhece com certeza nem com que

capacidade ou força, estes irão se comportar. A ameaça de novos

entrantes potenciais deve motivar à empresa, no sentido de melhorar

permanentemente suas formas de oferecimento de bens e serviços a seus

clientes, assim como de inovar ou criar novas formas ou alternativas de

serviço, melhorar a apresentação de seus produtos e dar facilidades de

financiamento. Embora tal estratégia, 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 situação atual das

diversas variáveis do ambiente, que se encontram fora do controle da direção da

organização, mas que têm uma influência muito importante para o

desenvolvimento das operações empresariais. Os fatores estudados neste modelo

são: (Austin, 1990), (Aybar et al.,1989)

a) Aspecto Social/Cultural: A sociedade e a cultura fixam as fronteiras de

ação de uma organização, exercendo sua influência na maneira como esta


funcionará, assim como no modo de agir de seus gerentes e funcionários,

os quais atuarão dependendo de sua procedência geográfica, clima, nível

social e educacional, dentre outros. Por outro lado, a sociedade tende a

agrupar-se em famílias, as quais influem sobre as organizações através do

mercado de consumidores e do mercado do trabalho. Uma análise geral

das necessidades desse mercado de consumidores irá ajudar a determinar

as oportunidades iniciais de se manter no negócio.

b) Aspecto Econômico: A influência das variáveis econômicas no

desenvolvimento empresarial tais como: o Produto Interno Bruto, a

inflação, a taxa de juros, o tipo de câmbio, as reservas internacionais, o

déficit fiscal, afetam o desenvolvimento das empresas e, principalmente,

o mercado. Aqui, também, deve-se considerar os impactos que da

economia mundial refletem na empresa (globalização).

c) Aspecto Político: A política do governo é outra variável 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 país, se dão os denominados

“ instrumentos de política” , que são de diversas índoles, tais como a

política fiscal, a política de emprego, a política cambial, a política de

alfândega, a política monetária e a política industrial, entre outros.

d) Aspecto Tecnológico: Desde sempre, e especialmente nos últimos anos,

observa-se que a tecnologia tem um papel relevante nos diferentes níveis

de decisão: estratégico, tático e operacional. A tecnologia pode ser vista

como uma ferramenta que alavanca, quando bem estruturada, a obtenção

de vantagens competitivas, o qual se reflete na produtividade,

rentabilidade e desenvolvimento de novos mercados e produtos. As

mudanças de tecnologia são um problema que deve-se contemplar e

tratar nas empresas, porque implicam custos, tais como os custos de

aquisição, de treinamento e de disseminação.


4.2.2 A Abordagem “ emphasizing efficiency” ou a que enfatiza a eficiência

Esta abordagem tem dois frameworks, o “resource-based view” e a sua

evolução, o “dynamic capabilities” .

4.2.2.1 A Visão “ resource-based view”

Os proponentes da perspetiva baseada em recursos, chamada “resource-

based view”, (Day et al, 1997, Rumelt et al., 1991, Wernerfelt, 1984), vinculam o

desempenho superior aos recursos da organização. Estes recursos são uma

combinação de ativos e competências que refletem a historia da organização, e

como tal, podem limitar a sua habilidade para a mudança. Os ativos e

competências determinam como efetivamente a companhia desenvolve e executa

as suas atividades funcionais. Em outras palavras, um conjunto crítico de ativos e

capacidades são subjacentes à vantagem posicional da firma. Assim, a fim de

atingir uma posição favorável no mercado, a organização deve fazer o esforço de

entender e mapear os seus recursos. A literatura classifica estes recursos em duas

categorias: Ativos Superiores, referem-se aos recursos com qualidade tangível

que podem ser etiquetados com um preço (valorizados) e, como tais, são

contabilizados em termos monetários; e Ativos ou Aspectos Distintivos de

Competência, que contribuem à integração dos ativos superiores da organização

(é a colagem que os mantêm unidos). Cada uma dessas competências representa

um complexo pacote de habilidades e conhecimento, sendo operacionalizadas

pelos processos organizacionais do negócio, servindo na coordenação das suas

atividades e na utilização dos seus ativos, com o intuito de continuamente

aprender e melhorar. As competências não são fáceis de mensurar nem de atribuir-

lhes um preço, sendo mais um patrimônio cultural da organização. Além disso, a

maioria delas refere-se a conhecimento tácito, o qual pode ser classificado nas

seguintes quatro dimensões (Day et al., 1997):

• Conhecimento dos empregados;

• Conhecimento embutido nos sistemas (software, banco de dados, e

processos formais);

• Sistemas de gerenciamento do conhecimento;


• Políticas de informação.

Para efeitos de análise, esses ativos e competências podem ser elicitados

tomando como base as funções de uma organização, as quais são:

a) Organização: A estrutura organizacional de uma empresa depende do

tamanho, número de funcionários, tipo de negócio (varejo, atacado,

comercial, industrial ou de serviços), tipo de organização (centralizada,

descentralizada ou matricial). A estrutura organizacional pode ser por

funções ou por processos e por produtos ou mercados.

b) Marketing: Compreende o estudo da oferta e demanda dos produtos da

empresa sob análise, suas estimativas e a escolha dos segmentos

potenciais de mercado. Assim, Kotler (1988) a define como: “a análise,

planejamento, implementação e controle de programas destinados a

produzir intercâmbios convenientes com determinado público, a fim de

obter ganhos pessoais ou comuns. Depende grandemente da adaptação e

coordenação do produto, preço, publicidade e praça, para lograrem uma

reação efetiva” , dando uma definição bem mais abrangente e bastante

aceita no meio acadêmico e na indústria.

Cadeia de Valor de

Comprador

Cadeia de Valor do

Fornecedor

Cadeia de Valor da Empresa

Cadeia de Valor do Canal

Sistema de Valores

INFRA-ESTRUTURA DA EMPRESA

GERENCIA DE RECURSOS HUMANOS

DESENVOLVIMENTO DE TECNOLOGIA

AQUISIÇÃO

LOGISTÍCA INTERNA

OPERAÇÕES LOGÍSTICA EXTERNA

MARKETING & VENDAS

SERVIÇO

LUCRO

ATIVIDADES PRIM ÁRIAS

ATIVIDADES DE APOIO

Cadeia de Valor do Produtor

Figura 4.2 Cadeia do Valor (Porter, 1985)

c) Produção: O nível de desempenho de uma empresa mede-se,

basicamente, por meio da sua produtividade na geração de bens ou

serviços, e depende da sua organização, planos, nível tecnológico,


financiamento, matérias primas, mão-de-obra e muitos outros aspectos.

Note-se que da problemática de gerenciar com qualidade os processos de

logística na produção de bens, (vide Figura 4.2), surgiu a idéia de ampliar

este conceito a todos os processos da organização, denominando essa

abordagem de qualidade total. A gerência deste tipo de organização,

orientada à qualidade total, é realizada através da gestão por processos

(de negócios), a qual leva implícito o conceito de gestão de processo.

d) Finanças: O objetivo das finanças em uma empresa está orientado a

desenvolver roteiros e ações com a finalidade de conseguir o máximo

rendimento dos ativos sob sua responsabilidade. Isto passa por obter

recursos monetários ou quase-monetários, das diversas fontes de

financiamento, procurando sempre os menores juros e os prazos mais

longos, para aplicá-los na aquisição de matérias-primas, remuneração da

mão-de-obra, pagamentos dos serviços básicos, e em oferecer facilidades

de crédito a seus clientes.

e) Recursos Humanos: Como é evidente, o sucesso da firma depende do

pessoal em quem se confia a execução das diversas operações para que

esta alcance os seus objetivos. Portanto, deve-se pôr uma ênfase especial

nos funcionários, oferecendo-lhes um ambiente adequado para o

desenvolvimento das suas habilidades e capacidades. No entanto, isto

deve estar acompanhado de estratégias adequadas de motivação, tais

como: remuneração justa, treinamento e prêmios, visando sempre o

enriquecimento do trabalho.

4.2.2.2 O framework “ dynamic capabilities”

O framework do “dynamic capabilities” é uma evolução do “resource-based

view”, enfatizando a característica dinâmica das capacidades que uma

organização deve possuir para lidar com um ambiente em mudança contínua. As

batalhas competitivas globais nas indústrias de alta tecnologia, por ex. as de

semicondutores e software, têm demonstrado a necessidade de uma extensão ao

paradigma de recursos. As companhias ganhadoras no mercado global têm sido

aquelas que demonstraram respostas oportunas, e uma rápida e flexível inovação


de produto, acoplado com a capacidade efetiva de coordenar e recolocar as

competências internas e externas da organização nas diferentes áreas que as

precisarem, caracterizando, assim, o uso dinâmico destas.

Teece et al. (1997) definem as capacidades dinâmicas como a habilidade da

firma para integrar, criar e re-configurar as competências internas e externas para

acompanhar o ambiente em mudança contínua. As capacidades dinâmicas, assim,

refletem a habilidade da organização para atingir novas e inovadoras formas de

vantagem competitiva dadas as dependências e condições do mercado (Leonard-

Barton, 1992). Este framework define como competências aos ativos intelectuais

específicos à empresa, mas que estão ensamblados ou imersos em conjuntos

integrados e estendendo-se além dos indivíduos e grupos que existem na

organização, permitindo a realização de atividades distintivas (rotinas e

processos). Tais competências são tipicamente viabilizadas através de múltiplas

linhas de produto e podem se estender a parceiros externos na forma de alianças

estratégicas.

4.3 A análise de processos e o TQM

Tendo como premissa que uma organização somente alcançará o sucesso se

possuir adequados níveis de qualidade na execução de suas atividades de

produção, de apoio e de negócio, 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 missão, objetivos e procedimentos, com o propósito

de implementar medidas corretivas e de consolidação, conforme seja o caso.

Na atualidade, com os mercados altamente competitivos, é fundamental que

as organizações entendam o conceito de qualidade, embora este seja um termo

bastante abstrato e subjetivo, pois depende do ponto de vista e da abordagem.

Diferentes definições podem ser encontradas na literatura, no entanto, acredita-se

que a definição de qualidade total a seguir preenche adequadamente a idéia de

qualidade sob um enfoque global: “Qualidade Total é uma estratégia 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 liderança

gerencial e envolvimento das pessoas, de todos os níveis da organização, em um


esforço conjunto e integrado de melhoria contínua e inovação dos processos,

produtos e serviços, 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 Gestão por Processos ou de Gerenciamento da Qualidade Total

(TQM - Total Quality Management), a qual está orientada a garantir que os

processos-chave do negócio sejam monitorados, acompanhados e melhorados

permanentemente. Esta é definida por Magalhães (1993) como o conjunto de

“estratégias que envolvem toda a organização, tratando a questão de qualidade

como um objetivo estratégico a ser alcançado através do melhoramento contínuo

de produtos e serviços, em função de especificações, 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 serviço antes de chegar às mãos do

cliente, de modo que em cada passo cabe agregar valor ao produto/serviço. A

gestão por processos requer técnicas específicas de gestão de processos orientadas

à solução de problemas, a melhoria de processos e, a identificação e

documentação de processos chave.

4.4 As Metáforas de Morgan

Do ponto de vista da Modelagem Empresarial, a análise organizacional pode

ser uma importante fonte para identificar as diversas entidades e os atributos

relevantes ao negócio. No entanto, a análise organizacional tem evoluído desde

aquela visão que enxergava a organização como uma estrutura estática e isolada,

para uma mais ampla, que considera o contexto onde esta atua e as suas inter-

relações com o ambiente, bem como o seu comportamento. Nesse sentido, em

Morgan (1996) encontra-se uma proposta interessante para olhar à organização

sob diferentes óticas ou visões, que ele chama de metáforas: Máquina,

Organismo, Cérebro, Cultura, Sistema Político, Prisão Psíquica, Fluxo e

Transformação, e Instrumento de Dominação.


Cada uma dessas metáforas fornece uma abordagem específica de análise

organizacional, mas todas elas em conjunto oferecem uma visão mais rica e

abrangente da organização, fazendo com que a análise do conjunto seja maior que

a soma das análises parciais.

4.4.1 A Organização vista como Máquina

Esta metáfora está sustentada na “ teoria clássica da administração” e na

“administração científica” . Os teóricos clássicos, ao projetarem as organizações,

agiram exatamente como se estivessem projetando uma máquina. No caso da

administração científica, defendeu-se o uso de estudos de tempos e movimentos

como meio de analisar e padronizar as atitudes de trabalho. Este tipo de

organizações são chamadas burocracias e são consideradas como sendo mais

eficazes em ambientes estáveis ou protegidos, e menos eficazes em ambientes

turbulentos e competitivos, como os vividos na atualidade (2003). As

organizações burocráticas, de forma geral, têm maior dificuldade em se adaptarem

a situações de mudança, porque são planejadas para atingir objetivos

predeterminados e não para a inovação.

4.4.2 A Organização vista como Organismo

A idéia de que as organizações são parecidas com organismos vivos dirigiu

a atenção para assuntos mais genéricos, tais como sobrevivência, eficácia

organizacional e a sua relação com o ambiente. Isto levou a compreender a

importância das necessidades sociais no local de trabalho e como os “grupos de

trabalho” podiam satisfazer essas necessidades. Descobriu-se também, que a

“organização informal” podia existir junto à organização formal, concebida pela

visão mecanicista.

O “enfoque de sistemas” , definido inicialmente por Bertalanffy (1950),

sustenta-se no princípio de que as organizações vistas como “organismos”, são

entes abertos ao meio ambiente e devem, portanto, atingir uma relação apropriada

com este, caso queiram sobreviver. Este enfoque preocupa-se com a atividade

“ambiental imediata” , definida pelas interações organizacionais diretas (clientes,


fornecedores, organizações governamentais e não governamentais), bem como do

contexto mais amplo ou “ambiente mediato” (aspectos sociais, econômicos

políticos e tecnológicos), conforme definido anos depois em Porter (1985) e Day

et al. (1997).

4.4.3 A Organização vista como Cérebro

Esta metáfora parte da premissa que a organização, de modo similar ao

cérebro, é um sistema de processamento de informações capaz de aprender a

aprender, e que ambos podem ser concebidos para refletir os princípios

holográficos. Isto significa que a organização toda pode ser contida em todas as

suas partes ou funções ou unidades que a compõem, de maneira que a partir de

cada uma delas esta possa ser reconstruída, pois cada uma das partes poderia

representar o todo.

4.4.4 A Organização vista como Cultura

A metáfora da cultura foca a atenção no lado humano da organização,

ressaltando o significado simbólico de cada aspecto virtual da vida organizacional.

Estes aspectos podem ser a linguagem, normas, folclore, cerimônias e outras

práticas sociais que comunicam ou expressam ideologias-chave, bem como os

valores e crenças que guiam a ação. Daí o interesse por administrar a cultura

corporativa, como se esta fosse o “ elemento de ligação normativo” (amálgama)

que mantém a organização unida. Nesse sentido, as crenças e as idéias que as

organizações possuem de si mesmas, bem como daquilo que pensam fazer com

respeito a seu meio ambiente, influenciam sobremaneira na materialização de seus

objetivos, encorajando-os também para a formulação e o estabelecimento da sua

estratégia empresarial.

4.4.5 A Organização vista como Sistema Político

À diferença de outras visões que olham às organizações como

empreendimentos interligados e racionais que perseguem um objetivo comum, a

metáfora política encoraja olhar as organizações como redes de pessoas


interdependentes com interesses divergentes que se unem com o propósito de

satisfazer as suas necessidades básicas (ganhar dinheiro), desenvolver uma

carreira profissional ou de perseguir metas fora de seus trabalhos (lazer, religião).

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 questões de personalidade, atitude, crenças, etc. e o terceiro com

o seu relacionamento com o mundo exterior.

4.4.6 A Organização vista como Prisão Psíquica

Esta metáfora sugere que as organizações são fenômenos psíquicos, ou seja,

o produto de processos conscientes e inconscientes, no qual as pessoas podem

ficar prisioneiras das imagens, idéias, pensamentos e ações que esses processos

acabam gerando. Assim, pressupostos falsos, crenças preestabelecidas, regras

operacionais sem questionamento e numerosas outras premissas e práticas podem

combinar-se para formar pontos de vista muito estreitos do mundo, fornecendo

tanto uma base como uma limitação para ações organizadas. Pois, enquanto criam

um modo de enxergar, sugerindo uma forma de agir, tendem também a gerar

maneiras de não ver e de eliminar a possibilidade de ações associadas a visões

alternativas da realidade.

4.4.7 A Organização vista como Fluxo e Transformação

Morgan destaca que uma organização que realmente queira entender o seu

ambiente, deve começar primeiro a tentar entender-se a si mesma, uma vez que a

compreensão do ambiente é sempre uma projeção de si própria. Para isto, baseia-

se na teoria da autopoiesis (Maturana & Varela, 1980), a qual argumenta que o

fato do sistema interagir com seu ambiente facilita a sua própria auto-reprodução.

De acordo com esta ótica, muitas organizações se encontram com sérios

problemas de lidar com o mundo exterior por não reconhecerem que este é uma

parte de seus respectivos ambientes. Nesse sentido, deve-se considerar que as

organizações mudam e se transformam em conjunto com seu meio ambiente

(fornecedores, clientes, trabalhadores, coletividade, concorrência, entre outras),


levando a compreender que o padrão de organização que se vai revelando com o

passar do tempo é evolutivo.

4.4.8 A Organização vista como Instrumento de Dominação

Morgan afirma que o real valor desta perspectiva é que a mesma demonstra

“ que até as formas mais racionais e democráticas de organização podem resultar

em modelos de dominação...” , por exemplo, objetivos racionais de maior

rentabilidade ou de crescimento organizacional provocam, não poucas vezes,

impactos negativos intrínsecos nas organizações, tanto nos empregados como no

seu ambiente, embora estes não sejam necessariamente intencionais. Assim, uma

maior rentabilidade pode significar um maior esforço dos funcionários, o qual não

necessariamente implique uma melhoria nas suas remunerações. Em outros

termos, aquilo que é racional desde o ponto de vista da organização pode ser

catastrófico na ótica do funcionário.

4.5 Ontologias

Um sistema de memória corporativa (SCM) é um tipo de sistema baseado

em conhecimento (Knowledge Based System - KBS) e, portanto no seu

desenvolvimento surgirão problemas de:

• Aquisição de conhecimento;

• Conceituação;

• Formalização;

• Implementação e;

• Manutenção.

Para lidar com as três primeiras utiliza-se a abordagem ontológica, onde

uma ontologia define um conhecimento do domínio de uma maneira genérica tal

que o entendimento do mesmo é aceito pela comunidade desse domínio. Em

outras palavras, uma Ontologia especifica um conhecimento conceitual para uma

determinada área do conhecimento, sendo a essência do conhecimento desse

domínio. A justificativa para a utilização de ontologias é que esta permite a


reutilização desses conceitos, facilitando ao mesmo tempo o seu

compartilhamento e disseminação (Van Heijst et al., 1996).

Do ponto de vista da apresentação, uma ontologia pode ser:

Altamente informal � quando é realizada em linguagem natural, ex.

glossários;

Semi-informal � quando esta em uma forma restrita e

estruturada de linguagem natural, ex. glossários

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

semântica formal, com teoremas e provas de tais

propriedades, como completude e validade, ex.

TOVE (Grüninger & Fox, 1996).

4.5.1 Definições

Na literatura encontram-se muitas definições de ontologias. A seguir

apresentam-se algumas delas:

“Uma ontologia é uma especificação explicita de uma conceituação”. (Gruber,

1993).

Uma ontologia pode ser vista como: (Guarino & Giaretta, 1995)

“uma especificação de uma conceituação”

“uma disciplina filosófica”

“um sistema conceitual informal”

“uma conta semântica formal”

“uma representação de um sistema conceitual via uma teoria lógica”

“o vocabulário utilizado por uma teoria lógica”

“uma meta-especificação de uma teoria lógica”


“Uma ontologia define os termos básicos e os seus relacionamentos,

compreendendo o vocabulário de uma área-tópico, bem como as regras para

combinar esses termos, e os relacionamentos para definir extensões a esse

vocabulário” . (Neches et al., 1991)

“Uma ontologia é um conjunto de termos estruturado hierarquicamente para

descrever um domínio que pode ser utilizado como fundamento para uma base de

conhecimento”. (Swartout et al. 1997)

“Uma ontologia provê os meios para descrever explicitamente a conceituação que

está por atrás do conhecimento representado em uma base de conhecimento”.

(Bernaras et al. 1996)

Entretanto, para efeitos do presente trabalho utilizaremos a seguinte

definição:

”Uma ontologia é uma especificação explícita e formal de uma conceituação

compartilhada”, pelas seguintes razões: (Studer et al., 1998)

Formal, implica que pode ser interpretado pelo computador;

Explícito, quer dizer que os conceitos, propriedades, relacionamentos,

funções, restrições e axiomas são explicitamente definidos;

Compartilhada, significa que é um conhecimento consensual; e

Conceituação, nos diz que é um modelo abstrato de algum fenômeno do

mundo real.

Uma questão relevante de mencionar é que a abordagem ontológica traz o

compromisso de um acordo para o uso do vocabulário de uma maneira coerente e

consistente.

4.5.2 Componentes de uma Ontologia

Os principais elementos de uma ontologia são conceitos, relacionamentos

e axiomas. Os conceitos são a sua unidade básica e estão vinculados entre si

através de uma rede de relacionamentos. A ontologia é formada por um grupo de


conceitos e cada conceito tem um conjunto de propriedades que são denominados

de atributos. Ex. o conceito Fornecedor tem como atributos código, nome,

endereço. Os axiomas são regras que prevalecem em uma dada ontologia

(Martinez-Bejar, 2000, Fernandez-Breis et al., 2002, Fernandez-Breis et al.,

2001), são sentenças que são sempre verdadeiras. Ex. Funcionário.idade é igual a

data_de_hoje menos Funcionário.data_de_nascimento. Os axiomas podem ser

estruturais, por ex. A is_a B e não estruturais, por ex. F=m.a (Força é igual a

massa pela aceleração). Os relacionamentos são qualquer subconjunto de um

produto de n conjuntos, ou seja R: C1xC2x ... x Cn. Alguns tipos de

relacionamentos ontológicos são:

• Taxonomia: - especializa conceitos e usa noções de classe e sub-classe

em uma hierarquia is-a. Este relacionamento tem as propriedades de ser

não-reflexiva, transitiva e assimétrica. Ex. Estudante e Funcionário é

um tipo de Pessoa.

• Mereologia: - é um relacionamento part-of e possui as propriedades de

ser não-reflexiva, não-transitiva e assimétrica. 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 Pistão é parte do Motor e por sua vez o Motor é parte do Carro.

• Temporal ou Cronológica: - é um relacionamento de precedência entre

os conceitos relacionados, por ex. Trocar_Lampada só acontece depois

que Lampada_Queimada. Este relacionamento possui as propriedades de

ser não-reflexiva, transitiva e assimétrica. 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

conexões entre conceitos, por ex. A se conecta a B. Possui as

propriedades de ser reflexiva, não transitiva e simétrica. Se A se conecta

a B, então B se conecta a A. Este relacionamento é útil quando se quer

extrair da ontologia que outros conceitos estão relacionados a um

determinado conceito. No entanto na modelagem de sistemas é muito

mais relevante o conceito de influência, o que seria também uma

conexão, mas só em um sentido. No presente trabalho se utiliza esta


última conceituação. Assim, A afeta B, mas B não afeta A ou B é afetada

por A.

Alguns autores consideram como mais um componente as instâncias, que

são elementos de um conceito.

4.5.3 Tipos de Ontologia

As ontologias podem ser classificadas de acordo com o seu conteúdo em:

Ontologia do Domínio, 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 específica, por exemplo a ontologia do

procedimento de compras e; Ontologia de uso Geral, quando se elicita termos de

uso comum como coisas, eventos, tempo espaço, comportamento, função

(Mizoguchi et al., 1995). Por outro lado, a ontologia pode também ser classificada

de acordo com questões da sua conceituação como: Ontologia da Representação,

a qual elícita os termos para formalizar um certo tópico, por exemplo os

formalismos para recuperação do conhecimento; Ontologia Genérica, quando esta

é reutilizável através de vários domínios; Ontologia do Domínio, reutilizável no

domínio e; Ontologia da Aplicação, quando é somente utilizável em uma

aplicação específica. (Van Heijst et al., 1997).

4.5.4 Ontologia da Organização Empresarial

No campo da organização e da empresa encontra-se um conjunto de

ontologias para a modelagem empresarial. Entre estas temos: (Uschold e

Grüninger, 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 Organização: Define os conceitos de Unidade

Organizacional, Entidade, Controle e Posse;


• Ontologia da Estratégia: Define os conceitos de Propósito, Estratégia,

Meta e Suposições;

• Ontologia de Marketing: Define os conceitos de Venda, Produto,

Vendedor, Cliente e Mercado.

Observa-se que as três primeiras estão conceitualizadas para um nível de

análise alto e médio, enquanto as duas últimas são orientadas à definição de uma

ontologia para tópicos específicos como são Estratégia e Marketing, não tratando

detalhes de mais baixo nível, como por exemplo os atributos destas entidades,

itens que são relevantes para uma ontologia a nível de estratégia de negócios que

sirva de base para a criação de uma memória corporativa estratégica. Justamente

esta ausência, da existência de uma ontologia nesse nível de detalhe e

abrangência, motivou o estudo de uma série de teorias e abordagens da análise

estratégica, as quais foram analisadas sob a abordagem ontológica, tendo como

resultado a definição de um conjunto de conceitos, atributos e os seus

relacionamentos que foram, logo, utilizados na criação da base de conhecimento

da memória estratégica.

Neste ponto é relevante enfatizar algumas características das Ontologias:

(Faquhar em [email protected] electronic mailing list (Gomez-Perez,

1999)

• Uma ontologia expressa o consenso do conhecimento de uma

comunidade de pessoas em um domínio;

• As pessoas utilizam a ontologia como uma referência 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 é estável;

• Uma ontologia pode ser utilizada para resolver uma variedade de

problemas desse domínio;

• Uma ontologia pode ser utilizada como ponto de partida para a

construção de múltiplas aplicações.


4.5.5 Métodos para a Descrição de Ontologias

Entre os métodos mais representativas para a descrição de ontologias temos:

(Fernandez-Lopez, 1999)

• TOVE – TOronto Virtual Enterprise (Grüninger & 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): (Grüninger & Fox, 1996)

Este método esta baseado na experiência do desenvolvimento da ontologia

do projeto TOVE, o qual modelou o domínio dos processos e atividades do

negócio. O método envolve previamente a criação de um modelo lógico de

conhecimento que precisa ser especificado por meio da ontologia. Grüninger e

Fox propõem o seguinte roteiro:

• Definir um conjunto de Cenários de Motivação;

• Definir um conjunto de Questões de Competência Informais que a

ontologia deve responder a fim de suportar os cenários de motivação;

• Definir a Terminologia da ontologia para o qual utiliza-se uma Lógica de

Primeira Ordem (First-Order Logic);

• Redefinir formalmente as Questões de Competência usando a

terminologia e a lógica de primeira ordem;

• Definir a semântica e as restrições sobre a terminologia usando a lógica

de primeira ordem.

4.5.5.2 Methodology for Building Ontologies (Uschold & King, 1995)

Este método esta baseado sobre as experiências no desenvolvimento do

Enterprise Ontology, uma ontologia para modelagem de negócios. O método


estabelece um conjunto de linhas de ação para o desenvolvimento de ontologias,

tendo estas a seguinte seqüência:

• Identificar o propósito e escopo;

• Criação da ontologia;

• Captura da ontologia;

• Codificação da ontologia;

• Integração das ontologias existentes;

• Avaliação;

• Documentação;

• 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 tradução via máquina. O roteiro deste método é o

seguinte:

• Identificar os termos base (“semente”);

• Vincular os termos base à ontologia SENSUS (manualmente);

• Incluir os nós que estão na rota à raiz;

• Agregar todas as sub-árvores envolvidas, utilizando a heurística: “se

muitos nós em uma sub-árvore são relevantes, então os outros nós na

sub-árvore também são 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 quão fatível era o re-uso de

conhecimento em sistemas técnicos complexos e o papel que podiam cumprir as


ontologias para suporta-las. O método sugere a criação de uma ontologia

preliminar para o seu posterior refinamento e aumento com novas definições. A

seguir detalha-se o processo:

• Especificação da aplicação sob estudo, para a qual se cria a ontologia;

• Projeto preliminar baseado em categorias ontológicas relevantes de alto

nível. Pode-se optar pelo reuso quando existirem ontologias de aplicação

já prontas, ou pela criação de uma nova desde o scratch (inicio) quando o

reuso não seja possível;

• Refinar e estruturar a ontologia do domínio, a mesma que foi definida no

passo anterior.

4.5.5.5 Methontology (Gomez-Perez98)

Este método foi desenvolvido pelo Laboratório de Inteligência Artificial da

Universidad Politecnica de Madrid, Espanha. O Methontology permite a

construção de ontologias no nível de conhecimento e para sua realização propõe

três camadas de atividades:

• Gerência: Inclui o Planejamento, Controle e Segurança da Qualidade;

• Desenvolvimento: Inclui a Especificação, Conceituação, Formalização,

Implementação e Manutenção;

• Suporte: Inclui a Aquisição de Conhecimento, Integração, Avaliação,

Documentação e Gerência de Configuração.

4.6 Arquiteturas de Software

É conhecido que o tamanho e a complexidade dos sistemas de software gera

problemas no desenho da arquitetura, indo além das questões de algoritmos e da

estrutura de dados. A arquitetura de software inclui aspectos estruturais como:

(Garlan & Shaw, 1994)

• a organização total do sistema e a criação de uma estrutura de controle;

• a existência de protocolos de comunicação, sincronização e acesso aos

dados;

• a atribuição de funcionalidades aos elementos do projeto;


• a sua distribuição física;

• a composição dos elementos do projeto;

• o seu escalonamento e desempenho;

• a seleção entre alternativas de projeto.

4.6.1 Definição

Segundo Myron Ahn (Hohmann, 2003) uma “arquitetura de software é a

soma de módulos não triviais, processos e dados, as suas estruturas e

relacionamentos, fornecendo uma visão 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

formação de um plano para a implementação ou modificação do sistema”.

4.6.2 Características

Em geral, utilizam-se arquiteturas porque uma boa arquitetura é um

elemento chave para o sucesso do sistema no longo prazo. Assim, entre as suas

características desejadas temos: (Hohmann, 2003)

• Fomentar a longevidade: A maioria das arquiteturas vivem mais que as

equipes que a criaram;

• Estabilidade: Assegura-se que uma mínima quantidade de re-trabalho

seja necessária quando as funcionalidades do sistema precisem ser

estendidas;

• Suportar uma Mudança Gradativa e Natural: Facilitando uma mudança

natural do sistema;

• Lucrativa: Assegura que a estrutura de custos associada a sua

sustentabilidade seja razoável, isso acontece quando for bem feita;

• Favorecer a Limitação do escopo: Influenciando naquilo que deve estar

“dentro” e “ fora do sistema”.

As arquiteturas também favorecem à criação de uma estrutura social na

organização de desenvolvimento de software, pois alavanca os pontos fortes da


equipe que criou a arquitetura e minimiza os seus pontos fracos. Assim mesmo,

também pode criar uma vantagem competitiva sustentável no tempo, quando a

arquitetura é tecnicamente sofisticada e difícil de duplicar.

4.6.3 O Processo de Criação de uma Arquitetura

Segundo Hohmann (2003) qualquer arquitetura de software começa com a

apresentação das intenções do projeto por parte da equipe de desenvolvimento.

Essa versão inicial pode-se ver como um ser humano quando criança, todo

completo, mas imaturo e possivelmente instável. No decorrer do tempo a

arquitetura amadurece e se robustece, na medida que seus usuários e criadores

ganham confiança, sendo tudo isso um processo iterativo. Isto nos induz a pensar

que a criação de uma arquitetura deve estar baseada em uma abordagem

pragmática, sustentada em padrões arquiteturais “provados” e “refinados” . Onde

“provado” significa que este tem sido utilizado efetivamente em não poucas

aplicações e “refinado” significa que alguém se ocupou de pesquisar, entender,

codificar e documentar esse padrão, de tal maneira que possa ser comunicado a

outros arquitetos. Em outras palavras, é um conhecimento “assimilado” que

qualquer um pode utilizar.

4.6.4 Princípios Arquiteturais

Os padrões arquiteturais capturam as “organizações estruturais”

fundamentais dos sistemas de software. Cada padrão aponta questões técnicas da

arquitetura, fornecendo descrições dos subsistemas, as suas responsabilidades e

explicando como estes interagem para resolver um problema particular. A

abordagem pragmática, quando cria uma arquitetura de software, explora os

vários padrões arquiteturais e seleciona um que razoavelmente trate essa situação

particular. Portanto, é necessário adaptar a arquitetura que satisfaz essas

necessidades. O Processo de adaptação e as escolhas de projeto são guiadas pelos

seguintes princípios arquiteturais. (Hohmann, 2003)


• Encapsulamento: A arquitetura é organizada ao redor de peças separadas

e relativamente independentes que ocultam detalhes internos de

implementação, um do outro;

• Interfaces: Deve-se definir a forma em que os subsistemas interagem;

• Acoplamento (Fraco): Refere-se ao grau de interconexões entre as

diferentes partes do sistema;

• Granularidade Apropriada: É determinada pelas tarefas associadas ao

componente, esta relacionado ao tamanho do componente;

• Coesão Alta: Descreve as atividades relacionadas dentro de um

componente ou entre um grupo de deles;

• Parametrização: O número de parâmetros deve ser apropriado, assim

como os seus tipos. Estes permitem ao usuário ajustar as operações do

sistema;

• Deferimento: Adiar decisões arquiteturais quando exista algum tipo de

incerteza.

4.6.5 Estilos Arquiteturais

Embora não exista ainda uma bem aceitada taxonomia para arquiteturas de

software, pode-se identificar uma série de padrões ou estilos arquiteturais que,

atualmente, formam o repertório básico 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 saídas. Cada componente recebe uma série de dados de

entrada, processa estes dados, envia os dados resultantes para os tubos de

saída. Os conectores são os tubos de dados (pipes). Especializações deste

estilo são os pipelines;

b) Organização Orientada a Objetos e á Abstração de Dados: Este estilo

possui como característica forte o fato dos dados e das operações estarem

encapsulados em um componente, o qual chama-se de objeto. A

comunicação entre componentes ocorre a partir da troca de mensagens

entre esses.


c) Invocação Implícita, 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 invocação de procedimentos

em outros módulos;

d) Camadas: O estilo camada é organizado de maneira hierárquica. Cada

camada tem o objetivo de prover serviços bem definidos para a camada

seguinte, a qual funciona como um cliente para a camada anterior. Cada

camada pode possuir vários outros componentes. A alteração de uma

camada não pode atingir mais de duas outras camadas, visto que uma

camada se comunica, no mínimo, com uma camada e, no máximo, com

duas. Esta característica torna este estilo forte para reuso;

e) Repositórios: No estilo repositórios, existem dois elementos distintos: a

base central de dados (blackboard) e os componentes que executam

operações na referida base, inclusive suas intercomunicações. Os

componentes são chamados de fontes de informação (knowledge source).

Os estados assumidos pela base central de dados é o principal motivador

de disparo de ações nos componentes que executam tarefas. Uma

categoria alternativa é quando dado um fluxo de entradas de transações,

estas acionam a seleção de processos a executar-se, neste caso o

repositório pode ser um banco de dados tradicional;

f) Interpretadores: Inclui o pseudoprograma que esta sendo interpretado e a

máquina de interpretação. O pseudoprograma inclui por sua vez o

programa e o estado da sua execução que esta sendo simulado;

g) Outras arquiteturas: Entre estas se têm: Processos distribuídos (anel -

ring- e estrela - star), organizações de programa principal e sub-rotinas,

específicas ao domínio, de transição de estado e de controle de

processos.

4.7 A Tecnologia de Agentes

Durante a ultima década, a abordagem de agentes tem sido desenvolvida

com certa ênfase no campo da Inteligência Artificial e recentemente, também, da

Engenharia de Software. Em conseqüência, muitos exemplos podem ser


encontrados em uma ampla variedade de aplicações, variando desde pequenos

sistemas, como filtros para e-mails, a sistemas complexos e de missão crítica,

como os de controle de tráfico aéreo.

4.7.1 Agentes - Conceitos

Definições concretas acerca de agentes de software ainda não existem na

literatura, porque cada autor as define sob sua própria ótica e, portanto, de forma

diferente. Uma das definições mais freqüentemente citadas é a de Woldridge &

Jennings (1995), esta diz que: “um agente é um sistema de computação

encapsulado situado em um dado ambiente e capaz e executar ações autônomas e

flexíveis para alcançar os objetivos de projeto” . De uma forma mais detalhada,

podemos dizer que os agentes de software (Jennings, 2001):

• são entidades que resolvem problemas claramente identificados com

limites e interfaces bem definidos;

• são embutidos num ambiente particular sobre o qual eles tem um controle

parcial e capacidade de observação. Eles recebem inputs relacionados ao

estado do seu ambiente através de “sensores” e geram outputs no seu

ambiente através de “executores” ;

• são projetados para realizar um papel específico;

• possuem controle sobre seu estado interno e comportamento;

• são 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 informação, agentes de tarefa e agentes de interface, e cada um deles, por sua

vez, pode ter outras sub-classificações, por exemplo, os agentes de descoberta,

busca e recuperação são alguns tipos de agentes de informação.

Uma abordagem baseada em agentes é utilizada quando se requer do

software a desenvolver, que este tenha características quase-humanas como:


aparente inteligência, habilidade social, capacidade de aprendizado,

adaptabilidade, tomada de decisões orientada às metas. A principal razão de não

usar objetos é que estes são baseados sobre uma analogia com objetos

inanimados, enquanto os agentes são baseados sobre uma analogia com objetos

animados (tipicamente seres humanos). Noutras palavras, os objetos - encapsulam

estado e são reativos, ou seja, sempre executam métodos quando invocados;

enquanto os agentes - encapsulam estado e comportamento, são pró-ativos,

orientados às metas, tentando atingir um propósito determinado.

4.7.2 Propriedades

Para que uma entidade de software seja considerada um agente, são

necessários pelo menos três propriedades: autonomia, interatividade e

adaptatividade. Outras propriedades são opcionais. A seguir apresentamos essas

propriedades:

1. Autonomia. Habilidade de alcançar seu objetivo sem intervenções

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 dinâmica, quando o agente de

software pode dizer “vamos” fazer algo, caraterizando a proatividade e o

ser imprevisível, quando o agente de software pode dizer “não” .

2. Interatividade (ou Habilidade Social). Habilidade de se comunicar com o

seu ambiente e outros agentes (quando necessário) visando completar seu

objetivo.

3. Adaptatividade (ou Aprendizado). Habilidade de acumular conhecimento

baseado nas experiências passadas e conseqüentemente modificar seu

comportamento em resposta as mudanças no ambiente. A inteligência de

um agente é a quantidade de comportamento aprendido e a possível

capacidade de raciocínio que o agente possa adquirir.

4. Persistência. Habilidade de executar continuamente mantendo seu

estado interno consistente.

5. Mobilidade. Habilidade de se transportar para um outro ambiente onde

será executado.


4.7.3 Tipos de Agentes

Da mesma forma que existe inúmeras definições de agentes, encontra-se na

literatura uma grande diversidade de taxonômias de agentes, uma delas é a que os

classifica em agentes interface, tarefa e de informação (Sycara et al., 1999), vide

Tabela 4.1.

Tabela 4.1 Tipos de Agentes

Os Agentes de Interface, interagem com o usuário recebendo as suas

especificações e entregando-lhe resultados. Estes agentes adquirem, modelam, e

utilizam as preferências dos usuários para guiar a coordenação do sistema, com o

propósito de suportar as tarefas dos usuários. Por exemplo, uma aplicação que

filtra e-mails de acordo as preferências do usuário é um agente interface. As

principais funções de um agente interface incluem; (1) coletar informação

relevante dos usuários para iniciar uma tarefa, (2) apresentar informação relevante

incluindo resultados e explicações, (3) perguntar ao usuário por informação

adicional durante a solução do problema e, (4) perguntar ao usuário pela

confirmação, quando necessário. Assim mesmo, permite às aplicações interagir

somente através de agentes de interface relevantes, dessa forma o agente tarefa

“oculta” o recolhimento da informação distribuída subjacente e a complexidade da

solução do problema.

Os Agentes Tarefa, suportam a tomada de decisões via a formulação de

planos de solução de problemas, sendo executados através de consultas e trocas de

informações junto a outros agentes de software. Este tipo de agentes têm

conhecimento do domínio da tarefa e de quais outros agentes tarefa ou de

informação são relevantes para executar varias partes da mesma. Adicionalmente,

Agentes Descrição

Interface Coleta e apresenta informações relevantes podendo interagir com o usuário para obter informações adicionais e confirmação. Suporta várias interfaces de consulta (telas – formulários, gráficos, menus e linguagens).

Tarefa Recebe a consulta do usuário via o agente Interface. Com a ajuda dos Brokers, determinam quais dos agentes contém informações relevantes para uma dada consulta. Decompõe o plano de consulta para que seja executada por vários agentes. Combina os resultados parciais obtidos. Faz uso de ontologias.

Informação Fazem a interoperabilidade entre fontes de dados e aplicações. Podem ter várias funcionalidades: conversão de formato para a fonte (wrapper), monitoramento das fontes, análise de dados, etc.


possuem estratégias para resolução de conflitos e para fusionar a informação

recuperada por meio dos agentes de informação.

Um Agente de Informação, é um tipo especial de agente de software que

deve prover acesso a uma ou mais fontes de informação heterogêneas e

distribuídas, sobre as quais proativamente recupera, analisa, manipula e integra

informações relevantes em prol dos seus usuários ou de outros agentes, de forma

preferencialmente just-in-time (Klusch, 1999). Um agente de informação deve

satisfazer uma ou mais das seguintes características:

• Gerência e Aquisição de Informação: capacidade de prover acesso

transparente para as fontes de informação. Deve poder recuperar, extrair,

analisar e filtrar dados, monitorar fontes e atualizar informações

relevantes em prol de seus usuários ou agentes;

• Gerência e Aquisição de Conhecimento: habilidades de adquirir e manter

conhecimento sobre ele mesmo e seu ambiente através da representação e

processamento de ontologias, metadados, perfis, mudança de formato de

dados e técnicas de aprendizado de máquina;

• Apresentação e Síntese de Informação: habilidade de juntar dados

heterogêneos e prover, aos seus usuários, uma visão unificada e

multidimensional sobre as informações relevantes.

Outras características desejáveis são:

• Produzir interações longas: que envolvem monitoramento de suas fontes

visando determinadas condições tal como a atualização da fonte;

• Fornecer informações em diferentes tempos: imediato, periódico e

condicional. A Tabela 4.2 exemplifica as três 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 requisições).

Tempo Exemplo de consulta: Imediato Forneça a cotação das ações da empresa x Periódico Forneça a cotação das ações de x a cada 30 minutos Condicional Forneça a cotação das ações de x somente quando subir 10 pontos

Tabela 4.2 Formas de consulta temporal de um agente


Quando uma aplicação é desenvolvida para ambientes de rede aberta,

distribuída e altamente dinâmica, como é o caso da internet, utiliza-se um tipo de

agente chamado de “middle” . Estes recebem anúncios das capacidades de outros

agentes e os armazenam em um banco de dados interno. Dois tipos destes agentes

são o agente matchmaker e o agente broker. O primeiro encontra, dado um serviço

requerido, qual agente pode satisfaze-lo. O segundo, além de localizar outros

agentes, com funcionalidades apropriadas, gerência o namespace de serviços e, a

comunicação entre vários agentes, bancos de dados e aplicações dentro do

ambiente. É pertinente observar que o agente matchmaker atua na realidade como

um agente de informação, pois seu objetivo é encontrar um agente que possa

atender uma determinada requisição. No caso do agente broker, este além de atuar

como um agente de informação, também 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 classificação

de agentes em interface, tarefa e informação, é 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 contém

agentes que interagem para solucionar problemas complexos que estão além de

suas capacidades individuais. Assim, fazendo uma analogia com a teoria de

sistemas, pode-se dizer que o sistema resultante deve ter capacidades além da

simples “soma” das capacidades dos agentes. Para modelar as aplicações de

sistemas multi-agentes existem diversas metodologias, sendo uma delas

MESSAGE (Methodology for Engineering System of Software Agents)

(Eurescom, 2001b), a qual é uma extensão de metodologias existentes para o

desenvolvimento de software orientado a objetos, para aplicações orientadas a

agentes, vide detalhes na seção 4.7.

É relevante mencionar que o termo “agente de informação” é muitas vezes

usado na literatura (Klusch, 1999; Klusch, 2001) para representar sistemas de

recuperação/integração de informação baseados em um conjunto de agentes de

software que interagem para fornecer determinada informação ao usuário. Nesse


contexto, um agente de informação é 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 inúmeras arquiteturas de sistemas MAS que integram diversos tipos

de informações com o propósito de auxiliar aos usuários na execução efetiva e

eficiente de tarefas complexas tais como diagnósticos médicos, projetos de

engenharia, decisões bancárias. Nelas é comum encontrar a utilização de agentes

que auxiliam a descoberta e localização de informações e serviços, bem como a

disseminação de conhecimento. Um dos desafios de qualquer arquitetura é

balancear a autonomia das fontes de dados e das aplicações mediante o uso de

agentes de software para a execução de um trabalho cooperativo.

De uma forma geral, a arquitetura baseada em agentes representa um nível

mais alto de abstração se comparada com a arquitetura de objetos, pois permite a

cooperação entre agentes, em vários níveis, produzindo sistemas de informação

cooperativos. Outro aspecto da arquitetura é a interoperabilidade semântica, onde

ontologias são usadas para descrever os significados dos recursos e das aplicações

(serviços), ou seja, é utilizada como base na troca de informações entre agentes,

reduzindo ou eliminando os efeitos da discrepância nos termos.

No caso de MAS abertos para a internet, um dos problemas básicos

enfrentados pelos projetistas é o problema da conexão entre os agentes, ou seja,

encontrar um ou mais agentes que podem ter informações (ou outras capacidades)

necessárias a um outro agente. O fato desse sistema ser aberto (i.e. os

participantes entram e saem a qualquer momento do sistema) e distribuído sobre a

internet, impede que haja soluções de comunicação do tipo broadcast, pois a rede

ficaria sobrecarregada. As duas soluções que tem sido propostas para resolver este

problema de conexão são: Matchmaking e Brokering (Sycara et al, 1999), sendo a

última a mais utilizada. Essas abordagens podem ser definidas em termos de ações

básicas de requisição/resposta entre agentes.


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 três diferentes tipos (papeis) de agentes, vide Tabela 4.3.

Agente Requester tem um objetivo que será alcançado por outro agente (Server) Agente Matchmaker 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 Funções dos agentes no processo Matchmaking

As interações entre os três tipos de agentes é mostrada na Figura 4.3.

Figura 4.3 Interação entre agentes no processo Matchmaker

Para cada requisição recebida de um agente Requester, o agente

Matchmaker tentará associar a requisição com o conjunto de classes de serviços

registradas pelos Servers. Se ele encontrar, então, retorna, ao agente Requester,

um conjunto ordenado (ranking) dos nomes dos agentes Servers (e respectivas

classes de serviço) que podem atender o serviço requerido. Um exemplo do

serviço do Matchmaker é o de “páginas amarelas” . Agindo como agente de

informação um agente Matchmaker deve informar ao Requester sobre a

entrada/saída de agentes do ambiente do sistema.

Agente Matchmaker

Id do agente

Classe do serviço

custo confiabilidade duração características

Agente Requester

Agente Server

Resposta: Id dos n Servers

Requisições para os n Servers Execute o serviço

Resultado do serviço:

Notifica/desabilita seus serviços Requisição para

serviço: Quais os Servers que podem atender meu pedido de serviço?


4.7.5.2 O processo de Brokering

O processo de Brokering determina como um agente virá a ter seu objetivo

alcançado por um outro agente. Assim como no Matchmaker, o processo de

Brokering envolve três diferentes tipos (papeis) de agentes: Requester, Broker e

Server. Na Tabela 4.4 mostra-se as suas funções.:

Agente Requester tem um objetivo que ele deseja que seja alcançado por outro agente Agente Broker conhece os nomes de muitos agentes e suas respectivas capacidades e

anuncia suas próprias capacidades como uma função de capacidades destes agentes. É indistinguível 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 Funções dos agentes no processo Brokering

As interações entre os três tipos de agentes é mostrada na Figura 4.4.

Figura 4.4 Interação entre agentes no processo Brokering

Para cada requisição recebida do agente Requester, o agente Broker tenta

associar a requisição com o conjunto de classes de serviços registrados. Se

encontra algum, o Broker redireciona a requisição 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 seleção de um agente

Server é feito não só levando em conta a satisfação em atender a requisição, mas,

também, visando o balanceamento de carga, ou seja, otimizar o uso de recursos

dos agentes Servers. Isso implica que um agente Server não pode se registrar em

mais de um Broker. Além disso, o agente Broker precisa gerenciar o montante do

trabalho realizado em cada requisição e os recursos disponíveis em cada Server.

Agente Broker

Id do agente Info.Balanceamento de carga

Outras características do serviço

Agente Requester

Agente Server

Resultado do serviço Id1, id2,...

Execute o serviço Notifica/desabilita

seus serviços Resultado do serviço

Requisição para serviço: Execute o serviço


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 características de três 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 método está orientado às fases de análise e projeto dentro do processo de

desenvolvimento de software, assim, através das especificações e das

representações resultantes do modelo de análise, a fase de projeto necessita apenas

trabalhar o refinamento desses resultados. O método propõe cinco diagramas: (1)

O Diagrama da Organização (DO) da aplicação, (2) O Diagrama do Domínio

(DD), (3) O Diagrama de Meta/Tarefa (DMT), (4) O Diagrama de Agente/Papel

(DAP) e, (5) O Diagrama de Interação (DI).

A metodologia MESSAGE também define a estrutura dos agentes de

software para a fase de implementação, a arquitetura do agente MESSAGE é

tratada na seção 4.8.6.

4.8.1 O Diagrama da Organização

Focaliza a estrutura da organização e os relacionamentos entre os agentes

que ela contêm. Desta forma, o DO visa definir a estrutura e o comportamento de

um grupo de agentes, no sistema e na organização externa, trabalhando juntos

para atingir objetivos comuns. O DO esta composto por dois modelos básicos: o

modelo estrutural e o modelo comportamental.

a) O Modelo Estrutural: Permite a visualização 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


exemplo usuários, 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

estereótipos.

b) O modelo de familiaridade ou de conhecimento (acquaintance):

Mostra, em um primeiro nível, os relacionamentos de familiaridade entre

o sistema multiagente e as principais entidades externas a esta, como, por

exemplo, outras organizações de agentes, papeis de usuários ou recursos

(bancos de dados, catálogos). Em um segundo nível pode mostrar um

maior detalhe de granularidade explodindo o sistema multiagente.

4.8.2 O Diagrama do Domínio de Informação

Mostra os conceitos e relacionamentos específicos ao domínio que são

relevantes para o sistema sob desenvolvimento. Como resultado, se obtêm

entidades, gerentes de entidades e tarefas. Este diagrama pode ser construído em

paralelo com todos os outros diagramas MESSAGE. Na prática, novas classes e

relacionamentos são progressivamente adicionadas quando o desenvolvedor

define que elas são úteis ou necessárias para a construção dos outros modelos.

4.8.3 O Diagrama de Meta/Tarefa

Descreve como as metas de alto nível, são decompostos em metas de mais

baixo nível, da mesma forma que tarefas são decompostas em conjuntos de sub-

tarefas. Uma meta descreve uma motivação, ao passo que uma tarefa descreve

uma atividade. Uma meta é uma situação, 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 utiliza-

se esquemas e diagramas. Os agentes podem ser identificados através dos pontos

de interseção entre as metas e as tarefas/ações, existindo três formas através das

quais a identificação de um agente pode ser abordada:


a) Decomposição de metas: As metas do sistema são decompostas em

submetas, e agentes são construídos ao redor destes grupos;

b) Decomposição de tarefas/serviços: Os serviços que um MAS precisa

prover são analisados e agentes são construídos ao redor destes grupos;

c) Decomposição orientada à responsabilidade: Os agentes são

identificados para manipular relacionamentos com agentes externos e

recursos.

4.8.5 O Diagrama de Interação

Captura a forma na qual os agentes ou papéis trocam informações, entre

eles, assim como com o seu ambiente. O diagrama consiste de um conjunto de

interações e de uma representação detalhada em termos de protocolos de

interação.

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 aplicações. 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 Percepção e Comunicação (Perception & Communication

Layer - PCL): Contêm os processadores de percepção e comunicação

para obter informação do ambiente e interagir com outros agentes.

b) Camada de Decisão e Gerenciamento (Decision & Management Layer -

DML): Controla ações do agente através de decisões deliberativas.

Também trata o gerenciamento do agente (criação, destruição e

monitoramento do agente).

c) Camada do Domínio (Domain Layer - DL): Agrupa entidades especificas

do domínio. Pode conter também os componentes que representam os

efeitores do agente (p.ex. execução de tarefas), desde que elas sejam

dependentes do domínio.


d) Camada de Recursos (Resource Layer - RL): Inclui os recursos internos

que o agente pode necessitar. Estes devem ser distinguidos dos recursos

da organização, desde que estes últimos pertencem ao sistema. Exemplos

de recursos internos são os recursos GUI (interfaces gráficas de usuário).

Esta arquitetura permite definir um amplo espectro de agentes. Para cada

uma das camadas são identificados componentes, os quais dependem dos

requisitos da aplicação. Em tal sentido, é pertinente salientar que é possível, por

exemplo, restringir um agente às camadas de Percepção e Comunicação e de

Recursos. Este é o caso de um agente puramente reativo. Por outro lado, agentes

cognitivos poderiam instanciar a arquitetura completa.

Figura 4.5 Arquitetura em camadas do agente MESSAGE (Eurescom, 2001a, Eurescom 2001b )

O principal propósito para a utilização de um MAS no SCM é poder delegar

aos agentes uma série de tarefas trabalhosas e exaustivas, tais como monitorar o

ambiente, manter a base de conhecimento, o Baseline Organizacional, e tomar

decisões sobre o melhor caminho quando necessário. Em ambientes altamente

dinâmicos e com grande quantidade de componentes, estas tarefas são

extremamente trabalhosas e seriam, praticamente, de grande dificuldade de serem

realizadas por agentes humanos.

Decision & Management

Layer (DML)

Perception & Communication Layer (PCL)

Domain Layer (DL)

Guia as comunicações / modifica a perceção

Ordena executar ações sobre o ambiente

Usa recursos

Resource Layer (RL)

Executa atos comunicativos

Recebe informações de baixo nível do ambiente

Recebe informações de alto nível do ambiente

Executa ações sobre o ambiente através dos recursos

Executa ações sobre os recursos / envia mensagens a outras entidades

Recebe mensagens de outras entidades/recebe informações dos recursos

Fornece informações do gerenciamento

Executa funções de gerenciamento


4.9 A Técnica do CBR (Wangenheim von & Rodriguez, 2000)

O CBR (raciocínio baseado em casos) é uma técnica de raciocínio que, a

partir de experiências prévias, armazenadas como casos, simula processos de

pensamento e raciocínio. O CBR armazena uma variedade de soluções para

problemas passados de acordo com certos critérios ou índices que são as

características relevantes para encontrar casos similares. Quando confrontados

com um problema similar, o CBR busca na base de casos e seleciona as soluções

dos problemas passados que mais se assemelham a este problema. É pertinente

mencionar que se definidas as métricas apropriadas de distância, casos corretos

poderão ser selecionados, os quais podem fornecer conhecimento útil do domínio,

seja na forma de uma solução completa ou mesmo de soluções parciais que

ajudem a resolver o problema atual. Por outro lado, muitos pesquisadores

asseguram que os casos suportam melhor que as regras, a propagação e

comunicação do conhecimento (Riesbeck & Schank, 1989). Assim mesmo, a

complexidade dos problemas do mundo real torna algumas vezes difícil, senão

impossível, generalizar regras a partir de casos.

Como dito no parágrafo anterior, é necessário o estabelecimento de atributos

e métricas que devem ser definidas de acordo com o domínio sob análise. Ao

mesmo tempo é necessário definir o algoritmo que permita encontrar o caso mais

aproximado e que melhor satisfaça aos requerimentos do problema vigente. No

trabalho sobre gerenciamento das experiências na área da Engenharia de Software

(Wangenheim von & Rodriguez, 2000), encontra-se um algoritmo para

recuperação de casos baseado em medidas de similaridade, definindo-se a medida

sim, a qual é parametrizada para um objetivo específico, tendo as seguintes

assunções:

Dependendo da meta de recuperação g, um particular conjunto de indices

Ig={ Ig1, Ig2, ...., Ign} é definido para a recuperação do caso ou casos mais similares.

A faixa de valores do atributo Igi é definido pela respectiva faixa definida em Wi.

A situação do problema presente (Sit’ ) é avaliado baseado no conjunto de índices

Igi da meta de recuperação, onde:

Sit’={ (Igi,si) � Sit / o fator de relevância (Si) � essencial}


tal que os atributos Igi � Ig e os seus valores si � Wi. Um caso de experiência,

casok representa uma experiência Ck={ (Ck1, ck1), (Ck2, ck2), ..., (Ckn, ckn)} com os

atributos Cki e seus valores cki � Wi e, com C’k ⊆ Ck e C’ki � Ig e, os seus

respectivos valores c’ki � Wi. As medidas de similaridade local v(si, c’ki) � [0,1]

para todos os Wi definidos. Introduzem-se condições de similaridade local θi �

[0,1] para cada índice Igi, com o intuito de determinar se os valores são

considerados o suficientemente similares. Para cada índice Igi � ao conjunto de

índices Ig, um fator de relevância ωgi � [0,1] é definido. Para cada meta de

recuperação os fatores de relevância são representados pelo vector de relevância

Rg={ ωg1, ωg2, ..., ωgn} com Σωgi=1 normalizado. A fim de explicitamente lidar

com conhecimento incompleto, a similaridade de dois objetos é expressa através

de um contraste linear de diferencias ponderadas entre as suas características

comuns e diferentes (Tversky, 1977). Na Tabela 4.5 mostrá-se os diversos

conjuntos de índices definidos.

E: Conjunto dos índices de uma situação dada e os casos armazenados

E={ Igi / (Igi � Sit’ ∩ C’ ki) e v’ (si, c’ ki) ≥ θi}

W: Conjunto de índices que contradizem a situação dada e os casos armazenados

W={ Igi / Igi � Sit’ ∩ C’ ki) e v’ (si, c’ ki) < θi}

U: Conjunto de índices desconhecidos na descrição da situação atual

U={ Igi / (Igi � C’ ki – Sit’ )}

R: Conjunto de índices redundantes não contidos nos casos armazenados

R={ Igi / (Igi � Sit’ – C’ ki)}

Tabela 4.5 Conjunto de índices definidos para a medida sim

Para cada conjunto de características, são definidos os pesos específicos α,

β, γ, δ ∈[0,1] na formula da medida de similaridade global:

α Σsi ∈ E ωik v’ (si, c’ ki)

Sim(Sit’ , C’ k) = ---------------------------------------------------------------------------------

αΣsi ∈ E ωikv’(si,c’ ki) + βΣsi ∈ W ωik(1- v’ (si,c’ ki)) + γΣsi ∈ U ωik + Σsi ∈ R ωik

Baseado no valor calculado de similaridade, um casok é considerado como

candidato a reuso, se todas as características marcadas como essenciais na

situação dada se assemelham as respectivas características do caso, e se

sim(Sit’ , C’k) ≥ a condição de similaridade global εk.

5 Resultados da Estratégia Proposta

Como dito no Capítulo 4, o primeiro passo foi estudar as diversas teorias,

visões e abordagens da análise estratégica, a análise de funções e processos, o

gerenciamento da qualidade total e, em forma ortogonal, as metáforas de Morgan,

com o propósito de extrair os construtos mais relevantes para a criação do

esquema conceitual da memória corporativa, o modelo de negócio. A tecnologia

utilizada para essa tarefa foi a de ontologias, a qual permitiu gerar uma ontologia

empresarial orientada à estratégia de negócios em ambientes de mudança

contínua.

Das diferentes metodologias de ontologias descritas na seção 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 também o

uso de Methontology, mas esta não 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 elicitação de uma ontologia empresarial.

5.1 A Ontologia Empresarial orientada à Estratégia de Negócios

O propósito da utilização da tecnologia de ontologias é detectar quais são os

construtos mais relevantes na área de estratégia de negócios que servem de base

para a criação do modelo de negócio, 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 propósito: Estabelecendo os fatos que motivam a sua

criação, como esta será utilizada e os possíveis mecanismos para seu uso;


b) Determinar o nível de formalização da ontologia: Em geral, o grau de

formalidade requerida aumenta com o grau de automação das tarefas que

a ontologia irá suportar;

c) Delimitar o escopo da ontologia: Determina-se através do uso de

cenários de motivação, os quais ajudarão ao estabelecimento de um

conjunto de questões de competência que a ontologia deverá satisfazer.

Muitas vezes utiliza-se também a técnica de “brainstorming” ;

d) Criar a ontologia: Envolve a captura da ontologia em si, identificando os

conceitos chave e os seus relacionamentos no domínio de interesse

(escopo). Também inclui a produção de definições precisas e não

ambíguas, a determinação dos termos que melhor as identifiquem e a

codificação em alguma linguagem formal;

e) Avaliar a ontologia: Refere-se a fazer um julgamento técnico da

ontologia, do ambiente de software associado e da documentação com

respeito ao frame de referência (domínio);

f) Documentar a ontologia: Envolve a descrição das assunções ou supostos

assumidos com respeito aos principais conceitos, as especificações de

requisitos, as questões de competência, bem como as primitivas

utilizadas para expressar as definições na ontologia (meta-ontologia).

Nas próxima seções desenvolve-se cada um dos itens acima citados.

5.1.1 Identificando o Propósito

Uma ontologia tem como propósito básico servir como um meio de

comunicação entre as pessoas, dentro de algum contexto ou domínio, facilitando o

seu reuso. Um outro propósito 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 negócio) da memória

corporativa orientada à estratégia de negócios (Strategic Corporate Memory -

SCM), a qual é uma aplicação baseada em conhecimento. Nota-se que sendo a

estrutura do repositório do SCM baseado em uma ontologia, esta facilita a

aquisição de conhecimento, bem como a identificação de requisitos e


especificações da arquitetura do sistema a desenvolver, tudo isso com o intuito de

obter um software mais confiável.

Na seção 4.5.3 estudou-se que uma ontologia pode ser de domínio, tarefa,

aplicação e representação (meta-ontologia). A ontologia empresarial proposta é de

domínio, sendo per-se genérica ao domínio em estudo. Isto porque está baseada

em teorias da estratégia de negócios aceitas tanto pela comunidade acadêmica

como de negócios e, portanto, aplicável em um alto nível a qualquer tipo de

organização, mas, obviamente, com os ajustes pertinentes, pois os construtos a

nível de ativos e capacidades vão depender necessariamente da atividade principal

da organização (core do negócio). Esta ontologia não só pode ser utilizada para

estruturar a base de conhecimento do SCM, como também poderia ser utilizada

por outro tipo de aplicações mais especificas, como por exemplo na área de

recursos humanos ou de marketing.

5.1.2 O Nível 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 representação

semi-informal em linguagem natural estruturada e restrita. A ontologia foi

documentada na ferramenta Protégé (2003), a qual permitiu expressá-la em uma

linguagem de representação semi-formal, o RDF-XML.

Anota-se que uma ontologia fornece um modelo semântico dos conceitos

existentes em um repositório, independente da estrutura existente em um

determinado momento. Portanto, o conceito de ontologia é análogo ao modelo

conceitual utilizado em bancos de dados convencionais, podendo se dizer que o

modelo de banco de dados em um domínio de aplicação especifico pode refletir a

representação de uma ontologia de aplicação. Isto se sustenta na afirmação de

Gruber (Guarino, 1998) de que “esquemas em bancos de dados relacionais

também servem como ontologias pela especificação das relações que podem

existir em algum banco de dados compartilhado e as restrições que devem ser

manipuladas pelo banco” . Assim, é possível descrever uma ontologia sob o

modelo ER, embora se saiba as suas limitações, tal como a impossibilidade de


representar regras e axiomas. Porém, considerando-se que no presente trabalho

não são tratados aspectos de inferência baseada em regras, essa limitação não foi

restritiva.

5.1.3 O Escopo da Ontologia

O escopo da ontologia empresarial esta delimitada à estratégia de negócios

em um ambiente competitivo de mudança contínua. Dado esse escopo, estudou-se

as teorias de estratégia de negócio mais relevantes, sob o marco de um

planejamento estratégico, o qual inclui tanto os aspectos do ambiente externo

indireto, ambiente externo direto e ambiente interno. É a partir dessas abordagens

mais específicas que é criada a ontologia empresarial no presente estudo. O

Planejamento Estratégico de Negócios, que integra as diferentes escolas da analise

estratégica, “positioning” e “emphasizing efficiency” , é uma abordagem bastante

utilizada na área de estratégia organizacional, seja no meio acadêmico, indústria

e/ou de consultoria. Esta tem suas origens no planejamento do longo prazo, sendo

seu objetivo central o estabelecimento de uma estratégia que envolva a definição

de missão, visão, objetivos estratégicos, políticas e planos de contingência. Dada

essa abrangência decidiu-se que a estrutura do repositório do SCM poderia estar

baseada nesta abordagem integradora, considerando que esta tinha sido estudada

em profundidade e comprovada a sua validade no ambiente de negócios.

5.1.4 Criando a ontologia

Delimitado o escopo da ontologia, o passo seguinte é selecionar quais

teorias, visões ou abordagens a satisfazem. Assim, determinou-se que para a

análise do ambiente externo indireto se utilizaria a análise ambiental (Aybar et al.,

1989; Austin, 1990) da escola “positioning” , a qual classifica o ambiente em

quatro grandes áreas: aspectos socioculturais, econômicos, políticos e

tecnológicos. Para a análise do ambiente externo direto utilizou-se o modelo de

Porter (1980) ou das cinco forças competitivas, também da escola “positioning” .

Finalmente, para a análise do ambiente interno aplicou-se a escola que enfatiza a

eficiência (“emphasizing efficiency”), a visão “resource_based view” e o


framework “dynamic capabilities” (Day et al., 1997, Teece et al., 1997). Estas

escolhas foram realizadas baseadas em que as mesmas são aceitas e amplamente

estudadas no meio acadêmico, bem como utilizadas por importantes empresas de

consultoria, PricewaterhouseCoopers, Ernst & Young, Deloitte Touche Tohmatsu,

KPMG (Klynveld, Peat, Marwick, Goerdeler). É relevante citar que como

decorrência do processo de planejamento estratégico estabelece-se uma estratégia

global, a qual está baseada nas oportunidades e riscos (resultado da análise do

ambiente externo indireto e direto e da análise do setor) e, nas fortalezas e pontos

de melhoria da organização (resultado da análise do ambiente interno). A

ontologia de negócio foi também enriquecida com a teoria de TQM (Total Quality

Management), a análise de funções e processos e as metáforas 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 domínio 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 negócios.

Entretanto, apesar da relevância da Enterprise Ontology, decidiu-se analisar em

detalhe as teorias e abordagens provenientes da ciência administrativa, pois

acredita-se que sendo esta uma área relativamente madura, seria adequado criar a

ontologia empresarial orientada à estratégia de negócios a partir dessas teorias,

mas que no futuro esta poderia ser enriquecida com a meta-ontologia e as

ontologias parciais de estratégia, atividade e organização da proposta de Uschold

et al. Considera-se essa extensão como um tópico para futuros trabalhos do SCM.

Na atualidade existem diversos possíveis critérios para o desenvolvimento

de uma ontologia na forma de uma hierarquia de conceitos e relacionamentos

ontológicos, sendo estes Top-Down, Bottom-Up e Middle. Um processo de

desenvolvimento Top-Down começa com a definição dos conceitos mais gerais

no domínio, com a subseqüente especialização desses conceitos. O processo

Bottom-Up começa, pelo contrario, com a definição dos conceitos mais

específicos, as folhas da hierarquia, para logo agrupá-las em conceitos mais

gerais. O terceiro critério, o Middle, é uma combinação dos dois anteriores, este


Companhia (Organização)

Forças Competitivas

Estratégia Global

PART-OF PART-OF PART-OF PART-OF Funções Processos

PART-OF PART-OF

Ambiente Organizacional

Fatores Socioculturais

Fatores Econômicos

Fatores Políticos

Fatores Tecnológicos

PART-OF PART-OF PART-OF PART-OF


Negócio

primeiro define os conceitos mais relevantes e logo os mesmos são

apropriadamente especializados e/ou generalizados. Salienta-se que nenhum

desses métodos é melhor ou pior que o outro: o critério selecionado dependerá

fortemente da visão do domínio que tenha o pessoal responsável da criação da

ontologia. No presente trabalho, adotou-se de modo geral o critério Top-Down,

dado que a abordagem de planejamento estratégico empresarial utilizada fornece

uma visão sistemática que vai do aspecto geral às questões mais especificas,

facilitando a aplicação do critério antes citado.

No Capítulo 4, quando estudou-se o tópico da estratégia de negócios

escreveu-se que o primeiro passo do planejamento estratégico era a análise do

ambiente externo indireto. O segundo passo era a análise do ambiente externo

direto, esta inclui o setor onde a organização desenvolve as suas atividades, e o

terceiro passo era a análise do ambiente interno. Isto é reafirmado na seção 5.1.3

quando se define o escopo da ontologia. Baseado nessa linha de raciocínio, as

Figuras 5.1, 5.2, 5.3 e 5.4 mostram a aplicação das visões do negócio utilizadas no

planejamento estratégico para a criação da ontologia em termos dos conceitos e os

seus relacionamentos.

Figura 5.1 Ontologia da Organização e do Ambiente Organizacional

Como decorrência desse processo de raciocínio definiu-se uma primeira

hierarquia de conceitos (modelo global da organização), utilizando-se o critério

Top-Down sob um relacionamento1 mereológico, vide Fig. 5.1, onde o conceito

Ambiente Organizacional refere-se ao ambiente externo indireto; as Forças

1 Nesta versão do SCM não se modelou os axiomas da ontologia.

Nome, Descrição , Matriz


Competitivas, incluindo a analise do setor, ao ambiente externo direto; a análise

do Negócio, Funções e Processos ao ambiente interno e a Estratégia Global que

define a missão, visão, políticas, objetivos, estratégias, é o resultado do processo

de planejamento estratégico como um todo. O detalhe desta primeira classificação

de conceitos é mostrada na mesma Figura 5.1 para o conceito Ambiente

Organizacional. O detalhe dos conceitos Forças Competitivas e análise do

Negócio é mostrado na Figura 5.2. Os conceitos Estratégia Global e Processos

são mostrados na Figura 5.3. A ontologia do conceito Funções é detalhada na

Figura 5.4.

Companhia Mecan. Organ. Cerebro Cultura Político Prisão Fluxo Domin.

Nome da Empresa V

Descrição V

Matriz V

Estrutura Organizacional V V

. Funcional V

. Divisionalizada V

. Matricial V

. Por Processos V

. Simples V

. Ad-Hoc V

Estilo de Liderança V V V V

. Impeditiva V

. Negociadora V

. Competitiva V

. Acomodatícia V

. Colaboradora V

Forma de Governo V V V V

. Autocracia V

. Burocracia V V

. Tecnocracia V

. Co-gestão V

. Participativo V

Setor de Atuação V

Mercado de Atuação V

Diagnostico Geral V

LEGENDA:

V: Satisfaz a metáfora

Tabela 5.1 O conceito Companhia e as metáforas 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, Econômicos, Políticos e Tecnológicos. A Tabela 5.1

mostra o conceito Companhia (organização) e alguns dos seus atributos mais

relevantes. Nota-se como as metáforas de Morgan ajudaram na elicitação de

atributos mais específicos e em alguns casos, como nos itens estrutura

organizacional, estilo gerêncial e forma de governo, conseguiu-se obter sub-


atributos. Também observa-se a importância de todas as metáforas, a exceção da

metáfora do organismo e do fluxo e transformação. Para efeitos de exemplificar a

ontologia do negócio, adaptou-se o estudo de caso da empresa Multicom

apresentado em Morgan (1996). Na Tabela 5.2 mostra-se uma instância do

conceito Companhia com dados da Multicom.

Tabela 5.2 Uma Instância do Conceito Companhia

A Figura 5.2 mostra o detalhe das Forças Competitivas e da análise de

Negócio, a primeira usa o relacionamento taxonômico, a segunda o

relacionamento mereológico. As forças competitivas, baseada no modelo de

Porter são: Compradores, Fornecedores, Concorrentes, Empresas de Produtos

Substitutos e Novos Concorrentes. Para a análise do Negócio, baseado no

planejamento estratégico empresarial, determinou-se como construtos relevantes

os conceitos Pontos Fortes, Pontos de Melhoria, Mercado de Atuação,

Oportunidades, Riscos e Medidas, utilizando-se o relacionamento mereológico.

Logo, para o conceito Medidas aplicou-se o relacionamento taxonômico obtendo-

se os conceitos Resultados e Benchmarking, estes últimos foram inspirados no


TQM, o que propõe o uso de indicadores de medição para avaliar o desempenho

da organização. Os indicadores do tipo resultado são conseqüência da atividade

própria do negócio, os indicadores do tipo benchmarking podem ser internos,

quando são resultados passados ou externos, quando obtidos de instituições

representativas ou de consultorias. Os indicadores externos por sua vez são de

índole local, estadual, regional ou internacional.

Figura 5.2 Ontologia das Forças Competitivas e da Análise do Negócio

A Tabela 5.3 mostra o conceito Concorrentes e a influência das metáforas

de Morgan para a determinação de seus atributos. A Tabela 5.4 mostra uma

instância deste conceito, utilizando-se o caso da Multicom.

Concorrentes Mecan. Organ. Cerebro Cultura Político Prisão Fluxo Domin.

Nome V V V

Descrição V V V

Endereço V V V

Telefone V V V Tipo (Varejo, Atacado, Distribuidor, Produtor) V V V

Pontos Fortes V V V

Pontos Fracos V V V

Participação do Mercado V

LEGENDA:

V: Satisfaz a metáfora Tabela 5.3 O Conceito Concorrência e as metáforas de Morgan

A Figura 5.3 especifica os conceitos Estratégia Global e Processos, o

primeiro baseado no processo do planejamento estratégico, utiliza os

relacionamentos mereológico junto com o relacionamento temporal (conceito

Fatores Críticos), o segundo baseado na análise de processos, usa um


Fornecedores Concorrentes Novos Concorrentes

Empresas de Produtos Substitutos

IS-A IS-A IS-A IS-A

Compradores IS-A

Negócio

Mercado de Atuação Oportunidades Riscos Medidas

PART-OF PART-OF PART-OF PART-OF

IS-A IS-A Benchmarking Resultados

Pontos Fortes

Pontos de Melhoria

PART-OF PART-OF


IS-A

relacionamento mereológico, em um primeiro nível, e um relacionamento

taxonômico e temporal (conceito Resultados) em um segundo nível. A Tabela 5.5

mostra a definição, em detalhe, do conceito Objetivos, da qual uma instancia é o

objetivo estratégico.

Entidade: Concorrentes Nome Media 2000

Descrição

Companhia dedicada aos serviços de Marketing e Publicidade. As suas atividades incluem: Desenho Gráfico para a identificação das empresas através de logotipo ou marcas; Criação e produção de catálogos, manuais, brochuras, cartazes, mala direta.

Endereço Rua Santa Catarina, 244 8o andar- conj. 805 CEP 09510-120 Rio de Janeiro – RJ

Telefone (21) 2224-5657

Tipo

• Varejo

• Atacado

• Distribuidor

• Produtor X

Pontos Fortes Sócios principais com ampla experiência, portafólio de clientes pequenos, mas lucrativos. Ambiente de trabalho amplamente estimulante. Companhia inovadora e talentosa.

Pontos de Melhoria Companhia nova no mercado, pouca experiência gerencial dos principais sócios, estrutura financeira não muito sólida.

Participação de Mercado Pequena (2%)

Tabela 5.4 Uma instancia do Conceito Concorrentes

Figura 5.3 Ontologia da Estratégia Global e dos Processos

Ações (Atividades)

PART-OF

Medidas Cliente do Processo

PART-OF PART-OF Fornecedor do Processo

PART-OF

I IS-A

Resultados Benchmarking

Indicadores

AFTER IS-A IS-A

Pessoa Unidade

IS-A IS-A

Pessoa Unidade

Inputs Outputs

{ Nome, Descrição, Dono de Processo Escopo, Tipo, Nível, Suporte Critico, Representação, Políticas, Padrões, Procedimentos}

PART-OF PART-OF Atores

(Pessoas)

PART-OF

Processos

Políticas Objetivos PART-OF PART-OF PART-OF PART-OF

After

Fatores Críticos

Medidas

Estratégia Global

Estratégias

Visão, Missão

Análise do Setor

PART-OF


�� !�!�"�!��#��$��%&�'�(��)��$�*�+�� ,&�$ !�-�!� .$�/)�$%�,�"� #0$� 12��"�$�!� 34%��65��7�8,�� :9��!�!;!� �< !�6� �!� �$#�=��$%>9�?!@�� ,��$%A,��B� � ��!� �!�!#&�6�$�$%DC�� $�!%D !�

EF�!�4G��'�� -H!5!@�� ,'� ��$ !��I1J� 9��

• K %L�� '�(M$�� ,�� N• 1)C'�� ,��

• O 9$�!� �$,'� ��$�!��2P .$�!�• �Q ��:� �� %L�� !#�0$� N

• /)�!9$�!� �(��+�!�'�(�

• R �$#�0$�• S � ��T'�'�(�� $%�U �"P �� ,��!% T$5!�$,'� ��$C��"� ��%WV�5��!� � X(� ,��$ !��%�YZ�$V�5�� 9$��+�!�'�(��%W ��8�!� �(�8V�5��!� � ��$ !�$YZ@$��$%A,��[�(�'�(��%A�$��!�\,��$ !�

R 5!9�� (��U �"� �� ,�� Q%�9��$%�%��!�$%7� �$%9$��$%'C'.!�!� %] ��'.!�!�^��!�_��'`�9��!�"� a��,� �-� �$V�5��!�"� !��Ib��79$�$,c�(��% R �!� .!� #��!%]��9�� ! �5[�(�!%] !�7V 5$�!� � !�$ ��I

Tabela 5.5 Conceito Objetivos

A Figura 5.4 detalha o conceito Funções, que faz parte do conceito

Companhia, utilizando os relacionamentos taxonômico e mereológico. De acordo

com a analise de funções, uma organização pode ser organizada em quatro

funções básicas: Administração e Recursos Humanos, Marketing, Finanças e

Produção e, Logística. No entanto, devido à importância que nas ultimas décadas

os sistemas de informação têm tido, esta área tornou-se, na prática, uma nova

função, responsável pela gerência dos recursos informáticos da organização, daí

acreditou-se que era conveniente mostrá-la como uma área independente. Assim

mesmo, determinou-se que, para efeitos de uma melhor apresentação, era

adequado separar os conceitos de Administração e Recursos Humanos,

inicialmente juntos. Cada uma das funções tem por sua vez um conjunto de ativos

e capacidades distintivas, o que é resultado do uso da escola “emphasizing

efficiency” . Não detalhou-se os ativos e capacidades distintivas da organização

porque estes construtos, como afirmado na seção 5.1.1, vão depender

necessariamente do core do negócio.

Figura 5.4 Ontologia das Funções

Funções

Produção Recursos Humanos Marketing Finanças

IS-A IS-A IS-A IS-A

Administraçãon

Sistemas Informação

IS-A IS-A

Ativos Ativos Ativos Ativos Ativos Ativos PART-OF PART-OF PART-OF PART-OF PART-OF PART-OF

Capaci- dades

Capaci- dades

Capaci- dades

Capaci- dades

Capaci- dades

Capaci- dades

Políticas, Padrões e Procedimentos


Antes de finalizar a elicitação dos construtos em um alto nível, vamos

analisar alguns dos já elicitados. Por exemplo, o construto Pessoa pode ter vários

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 não o estiverem. As Funções vão ter

também um conjunto de posições ou Cargos, os que vão estar alocados a

determinadas Pessoas. Por último toda organização tem um conjunto de Padrões,

e Procedimentos constituindo estes em novos construtos da ontologia.

5.1.5 Avaliação

Na presente pesquisa definiu-se o frame de referência do domínio como a

área de estratégia de negócios em ambientes de mudança continua, para a qual é

criada uma arquitetura de memória corporativa. Tendo delimitado nosso escopo,

utilizou-se a abordagem do planejamento estratégico empresarial que integra

teorias da análise estratégica (“positioning” e “emphasizing efficiency”), junto

com a análise de funções, processos, TQM e as metáforas de Morgan, para a

elicitação da ontologia empresarial. Estas teorias, visões e abordagens têm sido

aceitas e validadas tanto no âmbito da consultoria de negócios como no meio

acadêmico. Portanto, acredita-se ter feito uma abordagem com sólida base teórica

a qual garante a validade da análise para criação da ontologia empresarial e em

conseqüência a ontologia em si mesma.

5.1.6 Documentação

A ontologia empresarial anteriormente mostrada, foi documentada na

ferramenta Protégé. O Protégé é um software que permite definir os conceitos,

atributos, os seus relacionamentos e as suas instâncias. Na presente tese não se

utilizou a última opção, porque nossa abordagem foi criar um repositório 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 assunções ou supostos assumidos na


criação da ontologia têm sido detalhadas, como observado, no percurso da seção

5.1.

Figura 5.5 Os conceitos da Ontologia do Negócio no Protege

5.2 O Modelo de Negócio – O Organizational Baseline

Baseada na ontologia apresentada na seção 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 domínio. Este foi feito em um contexto geral, porque,

como mencionado antes, utilizou-se como base teórica um conjunto de

abordagens amplamente aceitos e utilizados na ciência administrativa.

A seguir extrai-se do modelo ER do Organizational Baseline, as entidades2 e

relacionamentos3 listadas abaixo.

1. Toda organização (Companhia) possui um conjunto de Objetivos

Estratégicos, unidades de negócio (Negócio), Funções e Processos. Os

processos têm escopo, representação, Inputs, Outputs, Clientes do

2 As entidades são marcadas em negrita. 3 Os relacionamentos são marcados em cursiva.


Processo, Fornecedores do Processo e vários níveis hierárquicos. Cada

processo é coordenado por uma Equipe de trabalho composto de atores

(Pessoas). Os Resultados são gerenciado(s) por Pessoas.

2. Os Objetivos Estratégicos são afetado(s) pelos Fatores Críticos, os

quais são controlado(s) pelos Indicadores de Benchmarking.

3. Comparando os Resultados com os Índices de Benchmarking pode-se

executar uma avaliação contínua da organização nos níveis de unidades

de negócio (Negócio), Funções e Processos. Quando necessário

determinadas Ações de Melhoria são tomadas afetando as unidades de

negócio (Negócio), Funções, Processos, Clientes do Processo, e

Fornecedores do Processo.

4. A Companhia ao relacionar-se com o ambiente é afetado pelas Forças

Competitivas como são: os compradores, fornecedores, concorrência,

nova concorrência, companhias ou empresas de produtos substitutos;

pelo Ambiente Organizacional formado pelos aspectos: socioculturais,

econômicos, políticos e tecnológicos; e pela Análise do Setor .

5. Os Padrões, Procedimentos e Políticas podem ser aplicados a (são

possuídos pela(s)(os)) Funções e Processos. Os Objetivos

Operacionais referem-se às (são possuídos pelas) Funções 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 nível genérico, no entanto

apesar que o trabalho tenha enfatizado a integração de conceitos via uma

abordagem ontológica, acredita-se que um maior detalhe é necessário, por

exemplo, na descrição dos indicadores de benchmarking, os quais deverão ser

baseados em um programa de medição da qualidade. A integração de um

programa de medição com o aprendizado continuo poderia, por exemplo, ser

executado usando a abordagem proposta por Cantone et al. (2000). Outra

importante característica do modelo é a descrição das relações sociais, isto é

conseqüência da nossa preocupação com os atores organizacionais (Pessoas e

Funções) e as suas responsabilidades (Papéis e Procedimentos), ressaltando-se

assim, a importância dos aspectos sociais no processo de tomada de decisões. Por

outro lado, apesar da presente proposta do Organizational Baseline incluir


construtos relevantes aos níveis estratégico, tático e operacional, enfatizou-se a

dimensão estratégica na criação do SCM.

<?xml ver si on=' 1. 0' encodi ng=' I SO- 8859- 1' ?>

<! DOCTYPE r df : RDF [

<! ENTI TY r df ' ht t p: / / www. w3. or g/ 1999/ 02/ 22- r df - synt ax- ns#' >

<! ENTI TY a ' ht t p: / / pr ot ege. st anf or d. edu/ syst em#' >

<! ENTI TY SCM ' ht t p: / / pr ot ege. st anf or d. edu/ SCM#' >

<! ENTI TY r df s ' ht t p: / / www. w3. or g/ TR/ 1999/ PR- r df - schema- 19990303#' >

] >

<r df : RDF xml ns: r df =" &r df ; "

xml ns: a=" &a; "

xml ns: SCM=" &SCM; "

xml ns: r df s=" &r df s; " >

<r df s: Cl ass r df : about =" &SCM; Admi ni st r aÃ§Ã£o"

r df s: l abel =" Admi ni st r aÃ§Ã£o" >

<r df s: subCl assOf r df : r esour ce=" &SCM; FunÃ§Ãµes" / >

</ r df s: Cl ass>

<r df s: Cl ass r df : about =" &SCM; Ambi ent e Or gani zaci onal "

r df s: l abel =" Ambi ent e Or gani zaci onal " >

<r df s: subCl assOf r df : r esour ce=" &r df s; Resour ce" / >

</ r df s: Cl ass>

<r df s: Cl ass r df : about =" &SCM; Anal i se do Negoci o"

r df s: l abel =" Anal i se do Negoci o" >

<r df s: subCl assOf r df : r esour ce=" &r df s; Resour ce" / >

</ r df s: Cl ass>

<r df : Pr oper t y r df : about =" &SCM; At i v i dades"

r df s: l abel =" At i v i dades" >

<r df s: r ange r df : r esour ce=" &r df s; Li t er al " / >

</ r df : Pr oper t y>

<r df s: Cl ass r df : about =" &SCM; At i vos"

r df s: l abel =" At i vos" >

<r df s: subCl assOf r df : r esour ce=" &SCM; Pr oduÃ§Ã£o" / >

</ r df s: Cl ass>

<r df s: Cl ass r df : about =" &SCM; At or es"

r df s: l abel =" At or es" >

<r df s: subCl assOf r df : r esour ce=" &SCM; Pr ocessos" / >

</ r df s: Cl ass>

<r df s: Cl ass r df : about =" &SCM; AÃ§Ãµes"

r df s: l abel =" AÃ§Ãµes" >


</ r df s: Cl ass>

<r df s: Cl ass r df : about =" &SCM; Capaci dades"

r df s: l abel =" Capaci dades" >

<r df s: subCl assOf r df : r esour ce=" &SCM; Pr oduÃ§Ã£o" / >

</ r df s: Cl ass>

<r df s: Cl ass r df : about =" &SCM; Cl i ent e Pr ocesso"

r df s: l abel =" Cl i ent e Pr ocesso" >


</ r df s: Cl ass>

<r df s: Cl ass r df : about =" &SCM; Compr ador es"

r df s: l abel =" Compr ador es" >

<r df s: subCl assOf r df : r esour ce=" &SCM; For Ã§as Compet i t i vas" / >

</ r df s: Cl ass>

<r df s: Cl ass r df : about =" &SCM; Concor r ent es"

r df s: l abel =" Concor r ent es" >

<r df s: subCl assOf r df : r esour ce=" &SCM; For Ã§as Compet i t i vas" / >

Figura 5.6 O Arquivo RDF Schema da Ontologia (vista parcial)


Figura 5.7 O Modelo E-R do Organizacional Baseline do SCM

Negócio Companhia Objetivos

Estratégicos Fatores Críticos

Benchmarking Indicadores

Resultados Funções*

Processos

Pessoas

Equipe Ações de

Melhoria

Pessoas* Clientes Processo Fornecedores

Processo

Outputs

Benchmarking Indicadores*

1,n 0,n

0,n afeta/

afetado-por faz-parte gerenciado-por

afeta / afeitado-por

gerencia / gerenciado-por

afeta/afetado-por coordenado-por

sofre

1,1

1,n

0,n 0,n

0,n 0,1

1,n

1,n 0,n 0,n 0,n 0,n

1,1 1,n

1,1

1,n 0,n

0,n 1,n

1,n tem

controlado -por afetado-por

/ afeta

executado-por

R-Matriz

possui

comparado R-Atravessa

1,n 1,1

1,n

* Definido em outra parte afeita / afeitado

Inputs

Modelo E-R

Setor Análise do

tem

afetado-por / afeta


1,n

1,n

1,n

1,1

Funções

possui 1,n

Objetivo Operacional

Políticas, Padrões e

Procedimentos

1,1

1,n

0,n


Equipe Informal Papéis

1,n 0,n

1,n composto-de

0,n

0,n 0,n

afetado-por / afeta

produz/ melhora produz /

melhora

produz / melhora

1,1

0,1

1,n 0,n

0,n

1,n 0,1

0,n

1,n

1

1,n

1,1 1,n 1,1

faz-parte

tem / faz-parte

1,1

tem 1,1

1,1

1,n

possui 1,n 0,n

afetado-por afeita

0,n

1,n possui

afetado-por / afeta

afetado-por/afeta possui

possui

possui

possui

Benchmark Indicadores*

0,n

alimenta tem

tem (fornece)

faz-parte tem/

alimenta

alimentado-por

composto de afeta/ afetado-por

0,1

Nível Hierárquico

1,n

1,n

1,n

1,n

0,n

1,n

0,n 0,n

0,n

0,n 0,n

gera

1,n 1,1

0,n

1,1

0,1

0,n

0,n


5.3 A Arquitetura Genérica do SCM (Strategic Corporate Memory)

Na criação da arquitetura do SCM utilizou-se um estilo arquitetural

heterogêneo, combinando, principalmente, a arquitetura de camadas e a

arquitetura de repositório, vide seção 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 integração de dados heterogêneos e

distribuídos é um tema de pesquisa atual e com muitos problemas em aberto na

área de banco de dados, pois não existe uma solução global que seja adequada ou

que se ajuste aos diversos problemas de integração (Barbosa, 2001). Ao mesmo

tempo conhece-se a existência de uma grande variedade de problemas, soluções e

de potenciais usuários com relação à integração de dados heterogêneos.

Duas alternativas de como tratar a integração de dados são: a abordagem

materializada e a não 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 criação de uma memória corporativa implica, por definição, a

integração de dados das mais diferentes fontes (legados, web, bancos de dados

relacionais e de objetos) e tipos (dados textuais e multimídia). Isto levou a

procurar uma solução baseada em uma das abordagens de integração antes citada.

Assim, no presente estudo decidiu-se pela opção materializada e escolheu-se que

o SCM deveria ter um repositório de conhecimento adaptado à estratégia de

negócios, tendo as seguintes características: (Rundensteiner et al., 2000)

• Em tempo de configuração, informação relevante é extraída desde

diferentes fontes de informação (web, sistemas legados, bancos de dados

existentes e seres humanos) por meio da utilização de agentes de

software. Esta informação é transformada, depurada e juntada com

informação de outras fontes, quando necessária, para logo ser carregada

dentro do repositório (Organizational Baseline);

• Em tempo de processamento, consultas são submetidas ao sistema

(SCM), sendo por este avaliada sem precisar interagir com as fontes

originais;


• Em tempo de execução, modificações no conteúdo das fontes são

filtradas para atualizar o repositório do SCM, logo são propagadas

(disseminadas) utilizando agentes de software.

A decisão anterior baseou-se no fato de que os dados do repositório não

sofreriam uma grande quantidade de mudanças, como sim acontece com

aplicações orientadas à transações, por exemplo vendas e compras. Outra razão 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 recuperação de informação utilizando esta abordagem faz-se diretamente a

partir dos arquivos fonte. Em vista de tais argumentos decidiu-se pelo tipo de uma

integração de informação materializada.

Na Figura 5.8 apresenta-se a proposta de camadas da arquitetura física do SCM,

nela observa-se que esta tem três camadas, uma camada de fontes, outra de

serviços ou middleware e, finalmente uma de repositórios, sendo parte desta

última o Organizational Baseline ou repositório de conhecimento.

Figura 5.8 Arquitetura de Camadas do SCM (Strategic Corporate Memory)

CAMADA DE REPOSITÓRIOS

WEB Seres Humanos

CAMADA DE FONTES

Decision Making

AGENTES MIDDLEWARE Query Engine Data Loader View Maintainer Metaknowledge Manager

Metaknowledge


Case Base

LOG

Interface

Busca &

Descobrimento Descobrimento

Descobrimento

CAMADA MIDDLEWARE

HR DB

Logistic DB

Interface

MK DB

Temporal Metadata DataBase

Repositorios: Ontology,

HyperlinksHistory, Users


5.3.1 A camada de Fontes

Considerando que a proposta arquitetural do SCM, é uma arquitetura de

integração de informação materializada, esta inclui, como dito na seção 5.3, fontes

tão diversas tais como: sistemas legados, bancos de dados relacionais ou orientado

a objetos, Web sites HTML, documentos SGML ou XML, ou mesmo dados

multimídia. Outra fonte, não menos importante, para a elicitação do conhecimento

que alimente o repositório do SCM são os seres humanos. As fontes de

informação do SCM são 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 factível porque, em primeiro lugar,

muito da informação e conhecimento relevante que alimenta o Organizational

Baseline será extraída dos bancos de dados que possui a organização, o que

implica no conhecimento detalhado da estrutura interna dessas fontes. No caso

dos sistemas legados também não haveria dificuldade pois, como na situação

anterior, a sua estrutura é conhecida pela organização.

No caso de fontes da web, poderia acontecer que em alguns casos não se

possa extrair o conteúdo, 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 informação. Nos últimos

tempos, com o surgimento de aplicações web baseadas em XML, essa dificuldade

inicial pode ser superada aos poucos. Isto porque essas aplicações, usualmente,

deixam à disposição do público usuário a estrutura de seus arquivos ou mesmo o

seu modelo de dados. Por último, se os dados fossem extraídos dos seres

humanos, seria necessário criar adequadas interfaces de usuário, sob a forma de

formulários que permitam a estes preenchê-los e assim alimentar o repositório da

base de conhecimento. Estes dados devem ser filtrados pela equipe de gerência do

conhecimento.

Na Figura 5.9 observa-se, também, que as tomadas de decisões (Decision

Making) efetuadas pelos executivos e/ou pessoal técnico são armazenadas em

uma base de casos, para a sua posterior recuperação quando necessária. Esta base

de casos constitui o que se chama arquivo de boas práticas e acumula experiências


positivas ante determinadas situações e, em não poucos casos, quando o

engenheiro de conhecimento o considere oportuno, também deve-se armazenar

experiências negativas, para não se voltar a cometê-las. Maiores detalhes serão

tratados quando se explicar os diferentes repositórios que formam parte do SCM e

quando se descrever a arquitetura do middleware de serviços de software através

do uso dos componentes-agentes de software na seção 5.5.7. Finalmente, ressalta-

se que os dados podem ser classificados como qualitativos (Qualitative Data),

textos ou imagens ou som, e quantitativos (Quantitative Data), dados numéricos,

essa classificação é mostrada na Figura 5.9.

Fig. 5.9 Visão Arquitetural do Strategic Corporate Memory

5.3.2 A Camada Middleware ou de serviços

O software responsável por facilitar os diferentes serviços aos usuários do

SCM encontra-se na camada média ou middleware layer. Esta consiste em uma

coleção de ferramentas encarregadas da exploração da informação fornecida pelas

fontes individuais e do apropriado gerenciamento do SCM como um todo.

Exemplos de tais ferramentas são: programas para filtrar e juntar informação de

diferentes fontes, programas para o gerenciamento da meta-descrição do espaço

de informação e programas para a manutenção do SCM quando houver alguma

notificação de mudança das fontes. O middleware será desenvolvido sob uma

abordagem de agentes, assim, por exemplo, os agentes wrapper são os

responsáveis de capturar informação relevante das fontes e alimentar a base de

conhecimento, o Organizational Baseline.

E-mail, Portal

RH MK

Case Base BD

Qualitative Data

Quantitative Data

Log Build

Intelligent Agents

WEB

Strategic Corporate Memory SCM

Temporal Metadata Database

Decision Making

Log


O meta-conhecimento das fontes facilita o descobrimento e a integração do

seu conteúdo no Organizational Baseline. Tipicamente, o middleware contém

alguma informação acerca dos esquemas e facilidades de todas as fontes de

informação registradas. A camada média inclui também os agentes usuários, que

capturam as principais características e funcionalidades dos executivos da

organização. Salienta-se que a sua modelagem deva ser feita com muito cuidado,

para determinar o conjunto de suas necessidades de informação, bem como as

suas tarefas específicas. A definição dos agentes usuários permite, portanto, o

mapeamento dessas necessidades ao repositório de conhecimento. Assim, dada a

ontologia empresarial, faz-se um mapeamento de cada termo a todos os usuários

para os quais esse tipo de informação é relevante. Então, cada vez que o

repositório é atualizado, um agente ouvinte que está rodando em background

dispara uma mensagem a esses usuários, executando dessa forma o processo de

disseminação de informação e conhecimento. Na realidade, vide Figura 5.9, cada

vez que o repositório é atualizado, se cria um registro no arquivo LOG do sistema

(Log Build) onde se armazena os metadados da atualização (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, então

o agente ouvinte envia uma mensagem aos usuários que têm mapeado esse termo.

O detalhe desta camada é tratado na Seção 5.5.

5.3.3 A Camada de Repositórios

A terceira camada é a de repositórios (repository layer), podendo ser de

conhecimento como: o Organizational Baseline e o Case Base (documentos e

experiências passadas) e auxiliares como: os de Business Ontology, Hyperlink

History, Upgrading Organizational Baseline e Users. No entanto, um importante

desafio é como recuperar a informação mais adequada dos repositórios de

conhecimento, para satisfazer a necessidade de um usuário particular. Justamente

para lidar com essa problemática utiliza-se esse conjunto de repositórios

adicionais para auxiliarem na extração e disseminação do conhecimento contido

no Organizational Baseline e o Case Base. Na Figura 5.10, mostra-se todos esses


repositórios. Nela ressalta-se pela sua importância o Organizational Baseline, pois

é onde mantêm-se toda a informação estratégica relevante à organização. A

seguir detalha-se cada um destes:

a) Organizational Baseline: Desenvolvido e baseado nas visões

“positioning” e “resource-based” da estratégia de negócios. Inclui

também aspectos da análise interna dos processos e das suas funções sob

um enfoque da qualidade total, bem como aspectos das metáforas de

Morgan. Toda essa base teórica 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

sistêmica e objetivando futuras mudanças na própria organização.

Portanto, o seu objetivo primário é representar o contexto organizacional

com o propósito de explicitar informações úteis e relevantes. Na Figura

5.10, no interior do Organizational Baseline, apresenta-se algumas das

entidades de informação que precisam ser coletadas para se poder mapear

e gerenciar a informação contida nele. Estes itens de informação são

coletados, como dito antes, de forma manual e automática a partir da

camada de fontes.

b) Case Base: Reúne experiências de projetos ou problemas resolvidos no

passado e que pela sua importância são armazenados para o seu posterior

reuso. Estas experiências podem ser consultadas para encontrar know-

how relevante que sirva para guiar e dar suporte à organização no seu

processo de tomada de decisões. As experiências relevantes são

identificadas neste repositório baseadas nas características do contexto,

do tipo de problema ou dos objetivos, utilizando heurísticas de

similaridade. As candidatas relevantes a reuso são sugeridas ao usuário

via um sistema de navegação (hyperlinks), o qual permite a exploração

interativa das candidatas.

c) Business Ontology: Armazena a ontologia de domínio do SCM incluindo

os conceitos e relacionamentos das entidades e atributos que formam parte

do Organizational Baseline, com o intuito de facilitar o suporte semântico

para o acesso a determinadas informações de interesse presentes neles, por

ex. quando um usuário quer fazer uma pesquisa no SCM que retorne


informação relevante ao termo “estrutura da organização” , 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. Além disso, em alguns casos mostra-se

também os seus possíveis relacionamentos com os outros elementos. No

caso de não existir o termo, o SCM mostra, se possível, as entidades que

são mais similares e onde é provável que exista alguma informação

relevante, utilizando o mesmo raciocínio anterior.

Figura 5.10 Visão Estrutural dos Repositórios

d) Hyper link History: Armazena o número de “hits” para cada uma das

entidades do Organizational Baseline ou do Case Base, com a finalidade

de fornecer ao usuário uma classificação baseada nas estatísticas de acesso

de como outros usuários fizeram a sua escolha em situações 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

Company Competitive

Forces Organizational Environment

SectorAnalysis

Business Process

Functions Benchmark

Results (Measures)

Produce/Improve Produce/Improve

Produce/Improve Compare


CaseBase (Repository) Users Hyperlinks

History

Organizational Baseline Business

Ontology

SCM

Affected-by Affected-by

Affected-by Own Own Own

Temporal Metadata DB

Provide


facilita que a cada certo tempo alguns usuários, cujo perfil diga que eles

utilizam esse tipo de informação nas suas atividades, sejam comunicados

oportunamente (recuperação automática). Isto se faz por meio de um

agente sensor que esta observando as mudanças que acontecem no

repositório. A comunicação pode ser feita por meio de uma mensagem

sobre o browser do usuário ou através de um e-mail ou portal, vide Figura

5.9. Com respeito ao Case Base, futuros trabalhos devem avaliar a opção

de cadastrar cada caso dentro de um tópico e cada tópico para

determinados usuários.

f) Users: Armazena o cadastro de todos os usuários do SCM, explicitando as

suas principais características (atributos), necessidades de informação e

relacionamentos entre eles, quando houver.

Em resumo, o SCM para fazer a busca no repositório de conhecimento do

Organizational Baseline utiliza mapeamentos pre-estabelecidos, o qual permite a

recuperação de entidades mais pertinentes dada uma consulta em particular. As

palavras chave fornecidas são comparadas com a estrutura ontológica como base

para encontrar a entidade / atributo mais adequada. No caso do repositório do

Case Base, a busca se realiza utilizando heurísticas de similaridade, vide detalhes

na Seção 5.5.7. Extensões ao presente trabalho devem tratar o uso de outras

heurísticas de similaridade, para ter novas alternativas nas buscas por

aproximação.

5.4 Desenvolvendo a Arquitetura de Software (Middleware)

A arquitetura de software do SCM está baseada nas técnicas de

componentes e a sua implementação 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

criação dos componentes de software, no seu mais alto nível, para logo passar à

etapa de desenvolvimento de cada um deles. O método utilizado sugere que se

utilize um conjunto de diagramas como detalhados na seção 4.8.


5.4.1 O Diagrama Organizacional do SCM

O Diagrama Organizacional da Metodologia MESSAGE provê uma

abstração muito importante e útil para o entendimento dos outros diagramas do

método. O diagrama organizacional foca-se na estrutura da organização de

software e nos relacionamentos entre os elementos que ela contêm. Desta forma o

diagrama define a estrutura e o comportamento do SCM dentro da organização

empresarial à qual esta se refere. O diagrama é composto por dois modelos

básicos: o modelo estrutural e o modelo de familiaridade.

a) O modelo estrutural: O modelo estrutural pode ser representado através

de uma arquitetura composta de três entidades básicas: funções/

processos / sistemas, pessoas e repositórios (bancos de dados), vide

Figura 5.11.

b) O modelo de familiaridade ou de conhecimento (acquaintance): Na

Figura 5.12 mostra-se as relações 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 usuários. Observa-se que o SCM

interage com os papeis Administrador do SCM e Usuários e com os

bancos de dados LOG, OB e CB. Além disso, também interage com as

equipes que conformam as áreas funcionais e de processos, ambas

alimentam os repositórios do SCM com informação relevante.

Figura 5.11 Diagrama do SCM dentro da Organização

Gerência do Conhecimento

t

SCM Funções ProcessoAdmin.

SCM

LOG OB

LEGENDA LOG: Log das transações (Metadados) OB : Organizational Baseline CB : Base de Casos (experiências passadas)

CB

Repositórios (Banco de dados)

Organização (funções, processos, sistemas)

Pessoas (Papeis)


Figura 5.12 Diagrama de Familiaridade do SCM

5.4.2 O Diagrama de Meta / Tarefa

O principal objetivo funcional do SCM é fornecer assistência aos executivos

e engenheiros de requisitos, no entanto o SCM também deverá satisfazer outro

tipo de objetivos, os chamados requisitos não funcionais (RNFs), os quais são

mostrados na Figura 5.13. No presente trabalho não estudou-se em forma explícita

este tipo de requisitos, mas dada a sua relevância os mesmos serão tratados em

forma implícita durante todo o processo de desenvolvimento da arquitetura. Na

Figura 5.14 mostra-se como o RNF denominado de alta precisão na informação é

decomposto em objetivos mais específicos como precisão no cálculo, precisão na

escrita e precisão no tempo.

Fig. 5.13 Requisitos Não Funcionais do SCM

A noção de precisão apresentada descreve o desvio permissível entre os

valores atuais e os desejáveis. Na Figura 5.15 detalha-se o RNF precisão na

escrita derivando-se do mesmo os RNFs precisão na consistência interna,

precisão um-a-um nos conceitos, precisão nas propriedades, precisão na

Precisão na Informação

SCM Memória Corporativa

Estratégica

Usabilidade

Segurança (no acesso)

Confiabilidade

Portabilidade

Interoperabilidade

Manutebilidade

Meta

Desempenho

Alimenta

Alimenta Alimenta

Atende

Admin.SCM

SCM

Funções Pessoal

Processos Pessoal

LOG OB CB

Usuário

Cria Log AtualizaArmazena

Executivo ou Engenheiro deRequisitos

Bancos de Dados Fonte (RH, Mk, etc)


consistência externa e precisão na determinação das funcionalidades (Chung,

1993; Mamani-Macedo, 1999).

Figura 5.14 Requisitos Não Funcionais: Precisão da Informação

Figura 5.15 Requisitos Não Funcionais: Precisão na Escrita

Na Figura 5.16 mostra-se o RNF precisão na determinação das

funcionalidades, derivando-se os sub-objetivos qualidade na evocação de

conhecimento (das pessoas), aquisição de informação relevante (de valor) e gerar

uma base de conhecimento confiável. Na mesma figura observa-se os agentes que

realizam essas tarefas, em um alto nível, para atingir esses objetivos. Cada uma

dessas funcionalidades do software constituem, em uma primeira aproximação,

um conjunto de componentes do SCM. Na seção 5.5. cada um deles é estudado

em um nível de detalhe maior, mostrando a sua estrutura e comportamento.

Na Figura 5.17 analisa-se a tarefa elicitar conhecimento das pessoas. Esta

tem três sub-tarefas: definir as necessidades de informação, preparar o

questionário e desenvolver formulários para o ingresso dessas informações

(conhecimentos), a partir do qual logo se atualiza o Organizational Baseline. Na

Figura 5.18 analisa-se a tarefa preparar o questionário, a qual é explodida em três

sub-tarefas: entrevistar os executivos, avaliar questionários passados e analisar o

ambiente que rodeia o negócio. Observa-se que o processo de raciocínio utilizado

chegou até o nível de tarefas operacionais que são independentes do software, o

qual mostra a robustez do método empregado.

Precisão na Escrita

Precisão na Consistência Externa

Precisão um-a-um

Precisão nas Propriedades

Precisão na Consistência Interna

Precisão nas Funcionalidades

Precisão na Informação

Precisão na Escrita

Precisão no Tempo

Precisão no Cálculo


Figura 5.16 Requisitos Funcionais e Não Funcionais: Uma primeira aproximação para a

determinação dos Componentes do SCM

Figura 5.17 Tarefa: Elicitar Conhecimento

Figura 5.18 Tarefa Preparar o Questionário

Em conjunção com a decomposição dos RNFs é útil determinar quais serão

os serviços prestados pelo SCM, bem como mostrar o conjunto de tarefas

necessárias para atingir satisfatoriamente tais serviços. Estas tarefas devem casar

com as tarefas decorrentes da decomposição dos RNF’s. Na Figura 5.19 mostra-se

as duas tarefas básicas do SCM, os serviços consulta requerida e disseminação

automática, os quais são detalhados na mesma figura, a ordem descendente

indica o workflow de cada um deles. O serviço consulta requerida tem a sub-

tarefa busca da palavra chave no Thesaurus da ontologia, isto implica que

Preparar Questionário

Avaliar Questionários Passados

Analisar Ambiente

do Negócio

Entrevistar Executivos

Elicitar Conhecimento (das pessoas)

Preparar Questionário

Desenvolver Formulários

(Conhecimento)

Definir Necessidades de Informação

Precisão nas Funcionalidades

Base de Conhecimento

Confiável

Aquisição de Informação Relevante

Qualidade na Evocação do

Conhecimento

Agente Executivo

Agente Interface

Elicitar Conhecimento

Agente Informação

Capturar Informação

Agente Informação

Gerar Base de

Conhecimento

Atualização Base de

Conhecimento

Agente

Tarefa


previamente tem que ser mapeada a ontologia ao Organizational Baseline, sendo

assim, decidiu-se que esta deveria constituir-se, pela sua importância dentro do

SCM, em um componente separado. O serviço de disseminação automática 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 raciocínio anterior,

decidiu-se que a disseminação do LOG deveria constituir-se também em um

componente independente.

Finalmente, existe um conjunto de itens que não têm sido tratados até agora:

as lições aprendidas ou boas práticas as quais devem povoar a base de casos de

experiências passadas (CB), esta pela suas próprias características irá se constituir

também 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 máquina de inferência, mas como explicado antes, o escopo do presente

estudo não envolve o seu desenvolvimento, ficando assim como um tópico para

trabalhos futuros do SCM.

Figura 5.19 Outra Visão: Os serviços do SCM (requisitos funcionais)

Uma visão mais detalhada de todas essas funcionalidades e componentes

será fornecida nas seções 5.4.5 e 5.5, onde se mostrará primeiro, a visão de projeto

do SCM e, a seguir, a sua estrutura e comportamento.

Assistir ao Usuário

Consulta Requerida

Disseminação Automática

Requisitos da Consulta

(Palavra Chave)

Busca da Palavra chave no

Thesaurus Ontologia

Extração de Conhecimento

do OB

Notificar ao Usuário

Ler o LOG

Atualização Organizational

Baseline

Extração de Conhecimento

do OB

Notificar ao Usuário

Busca da Palavra chave nas

Regras da Ontologia


5.4.3 O Diagrama de Agente / Papel

Este modelo faz uso do diagrama estrutural de delegação, 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 serviços do SCM é explodido em

submetas obtidos como resultado da descomposição do objetivo macro “assistir ao

usuário” . Nota-se que cada meta irá gerar uma tarefa e cada tarefa será atribuída

aos agentes/papéis pertinentes que formam parte da organização de software do

SCM. Enfatiza-se que este diagrama não só está estritamente relacionado com o

diagrama de decomposição dos serviços prestados pelo SCM, como também deve

ser consistente com o mesmo, vide Figuras 5.19 e 5.20.

Figura 5.20 O Diagrama Estrutural de Delegação

Na Figura 5.20 mostra-se, em um primeiro nível, o principal serviço do

SCM: “assistir ao usuário” (executivo ou engenheiro de requisitos), o qual tem

dois sub-serviços ou metas “consulta requerida” e “disseminação”. Na figura

detalha-se o primeiro com os seus quatro sub-serviços meta/tarefa, requisitos da

consulta, busca no thesaurus, extração de conhecimento e notificação ao usuário.

Não aparece o serviço busca na máquina de regras da ontologia porque este não

está sendo tratado no presente trabalho. De forma similar, um diagrama workflow

deverá mostrar os papeis que devem cumprir os agentes na organização de

software, bem como a execução das tarefas necessárias para implementar o

serviço fornecido pela aplicação do SCM. Para cada agente / papel existe um

esquema que descreve as suas características, vide Tabela 5.6, na mesma nota-se

Consulta Requerida

SCM

Disseminação

Requisitos Busca Extração Notificação

Busca Maquina Regras

Agente Validação

Agente Busca

Thesaurus

Agente Extrator

Agente de

Notificação

Assistir ao Usuário


que o conteúdo destes esquemas é realizado em linguagem natural. (Eurescom,

2001b)

Esquema Agente / Papel

Agente Extrator

Metas Extrair informação relevante do Organizacional Baseline (OB) e/ou da Base de Casos (CB) de experiências passadas (lições aprendidas).

Capacidades Utilizando os índices de mapeamento deverá extrair a informação / conhecimento dos repositórios OB e/ou CB.

Conhecimento / Pensamentos

Deverá ter conhecimento de que ante consultas similares, por um usuário determinado, exista um arquivo histórico, o qual ajudaria ao agente de notificação ao escalonamento dos resultados.

Requisitos do Agente

Deverá receber do agente procura os índices de mapeamento (chave de acesso).

Tabela 5.6 Esquema Agente / Papel para o Agente Extrator (Eurescom, 2001b)

5.4.4 O Diagrama de Interação

Este diagrama ressalta qual, porque e quando os agentes / papéis necessitam

se comunicar, mas não trata detalhes de como a comunicação se efetua - isso será

tratado na fase de projeto mediante a utilização do protocolo FIPA (2003)

(Foundation for Intelligent Physical Agents). Usualmente este diagrama é refinado

através de um processo de várias iterações, tantas quantas sejam necessárias. O

diagrama de interação tem como elementos o iniciador, o respondente, o

motivador de uma interação (fornece o objetivo do iniciador), mais outras

informações opcionais como a condição do trigger (disparador) e as informações

fornecidas e obtidas por cada agente. A Figura 5.21 mostra o diagrama de

interação entre o agente busca e o agente extractor. O agente busca tem como

objetivo um requerimento de informação do motivador que é outro agente.

Figura 5.21 O Diagrama de Interação entre os agentes Extrator e Busca

No exemplo, o agente motivador faz um pedido ao agente busca de

determinada informação, o agente busca através de uma Solicitude de Notificação

Agente Busca

Agente Extractor

Iniciador Respondente (Colaborador)

Solicitude de

Notificação

Conceito / Atributo

Fornecimento de Informação

1..* 1

1

Requerimento Informação

e-Mail Agente

Motivador


encaminha ao agente extrator por esse Requerimento de Informação. O agente

extrator via outra Solicitude de Notificação faz o Fornecimento de Informação

dos conceitos/atributos relevantes. Logo, o agente busca encaminha essa

informação ao agente motivador.

De maneira similar funcionam todos os outros diagramas de interação dos

demais agentes de software. É importante declarar que a modelagem dos

protocolos de interação situam-se no limite entre as fases de análise e projeto.

Portanto, a interação pode ser detalhada em qualquer dessas fases.

5.4.5 Estruturando os Resultados de acordo aos diagramas organizacional, meta / tarefa, agente / papel e interação

A seguir, como resultado da análise estrutural do diagrama organizacional

da Metodologia MESSAGE e dos diagramas meta / tarefa e de interação mostra-

se, na Figura 5.22, um maior nível de detalhe do projeto arquitetural de software

do SCM.

Figura 5.22 Visão de Projeto do SCM

Observa-se que as principais tarefas do SCM são gerar a base de

conhecimento (GenerateKnowledge) o que reflete-se no Organizational Baseline;

Agent Roles

Control(Sensor) PurposeDescrip Organization Structure

SCM

Task

Workflow Structure

InformationEntity Results

GenerateKnowledge (From BD)

ElicitKnowledge (From people)

Knowledge Base Produce/Feed

Feed

CaptureKnowledge (From Internet)

F DisplayKnowledg

e (Browser) DisseminateKnowledge

Produce

CaseBase DecisionMaking StoreDecision

Making Produce

UpgraOrgBaseline OutputVector Statistics SearchKnowledge

Produce

Application Agent UserAgent

TaskAgent

Information

Interface

(Organizat.Baseline)

Produce


elicitar o conhecimento das pessoas (ElicitKnowledge); capturar conhecimento da

internet (CaptureKnowledge); disseminar conhecimento (Disseminate

Knowledge); armazenar tomadas de decisões (StoreDecisionMaking); atualizar o

Organizational Baseline (UpgraOrgBaseline) e busca de conhecimento nos

repositórios (SearchKnowledge). Os principais resultados além do Organizational

Baseline são mostrar conhecimento no browser (DisplayKnowledg); o repositório

de tomada de decisões (DecisionMaking CaseBase); o mapeamento da ontologia

ao Organizational Baseline (OutputVector) e as estatísticas de acesso (Statistics).

5.4.6 O Diagrama de Domínio

Segundo a Metodologia MESSAGE, o modelo de domínio pode ser

convenientemente representado através dos diagramas de classe UML, onde as

classes representam elementos específicos ao domínio da aplicação e os

relacionamentos as suas associações. Na Figura 5.23 mostra-se a relação que

existe entre a ontologia do domínio do negócio e o modelo do negócio.

Figura 5.23 AVisão de Domínio do SCM

Na Figura 5.24 mostra-se em detalhe a análise do domínio do processo de

busca, nela observa-se como o SearchQuery utiliza o relacionamento casar

Co

Competitive Forces Organizational Environment

SectorAnalysis

Business Process

Functions Benchmark

Results (Measures)

Produce/Improve Produce/Improve

Produce/Improve Compare

Organizational Baseline Affected-by

Affected-by Affected-by

Own Own Own

Concepts

Business Ontology

Offers

Name Attributes

1..*


(matches) para procurar o termo no thesaurus da ontologia do domínio (Thesaurus

Ontology), extrair os conceitos (ConceptList) e logo para cada conceito extrair os

usuários que poderiam estar interessados em possuir essa informação (UserList),

finalmente se efetua a disseminação via uma janela (WindowDissemination).

S e a r c h Q u e r y T h e s a u r u sO n to l o g y

C o n c e p tL is t1 ..n1 ..n

U s e r L i s t

1 ..n1 ..nW i n d ow D is s e m i n a t i o n

m a tc h e s

m a tc h e s

m a tc h e s

l is t

Figura 5.24 O Processo de Consulta do SCM

Na Figura 5.25 mostra-se o processo de disseminação automática

(AutomaticDissemination), o qual começa 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 são extraídos (matches) os usuários

relevantes e via e-mail (e-mailDissemination) essa informação é disseminada a

todos eles.

Autom aticDis s em ina tion m atches LogFile

C oncepts Lis t

1 ..n1 ..n

e-m a ilD is s em ina tion U s erL is t

1 ..n1 ..n

m atches

d is s em ination

m atches

Figura 5.25 Os Processos de Disseminação Automática do SCM


5.5 Descrição dos Componentes-Agentes da Arquitetura de Software

Uma arquitetura de software predefine um conjunto de componentes

funcionais, descritos em termos de seus próprios componentes e interfaces no qual

o sistema é dividido. Assim, uma descrição arquitetural está primariamente

preocupada com a estrutura do sistema e com a especificação de suas funções e

responsabilidades, mas trata também das regras e diretrizes que ajudam na

organização dos relacionamentos entre os componentes. Faz-se notar que o termo

componente, tal como empregado aqui, inclui componentes funcionais, agentes,

subsistemas e módulos (Eurescom, 2001a). Neste sentido, a arquitetura do SCM

fornece, em um alto nível, 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 domínio no qual se

insere a memória corporativa possui:

• um ambiente externo;

• objetivos a serem atingidos;

• capacidades (de negócio) necessárias para suportar esses objetivos e;

• um conjunto de planos (explícitos) a serem selecionados.

Por exemplo, se quisermos fazer um planejamento de marketing estratégico

(objetivo e planos específicos), será necessário determinar que informações 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 distribuído orientado ao negócio, lida com

aspectos de:

• aprendizado (capacidade de acumular conhecimento baseado em

experiências passadas, por exemplo a partir do arquivo LOG do sistema

pode se deduzir o tipo de informação que determinada área da empresa mais

utiliza, facilitando a disseminação automática);

• interatividade (capacidade de se comunicar com o seu ambiente e com

outros agentes, por exemplo recepcionar uma solicitude de busca); e


• autonomia (capacidade de acessar as fontes de informação e de forma

proativa recupera-as, analisa-as, manipula-as e integra-as).

Todas essas características são difíceis de serem alcançadas com abordagens

baseadas em objetos, devido a isto, tomou-se a decisão 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, é necessário a

utilização de uma plataforma de comunicação que facilite o seu gerenciamento.

Entretanto, anota-se que esta plataforma não é exclusiva para o uso dos agentes de

software, pode também ser utilizada para a comunicação entre componentes. Na

presente tese propõe-se a utilização da plataforma FIPA (2003) para a

comunicação entre os agentes do SCM.

Figura 5.26 Os Componentes da Arquitetura de Software do SCM (* Não 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 são resultado da

análise da seção 5.4.5, onde estruturou-se a visão de projeto do SCM, o qual

permitiu visualizar as suas principais funcionalidades, as mesmas que serviram

de base para a criação dos componentes do SCM. Salienta-se que a arquitetura de

Busca e Entrega

Armazenamento e

Disseminação

Armazenamento Lições Aprendidas

Interface Descobrimento Regras de Inferência *

Usuário

DataBases Seres Humanos

Organizational

Baseline Case Base Log

Metadata

Controle e Comunicação

CAMADA DE REPOSITÓRIOS CAMADA DE FONTES

CAMADA MIDDLEWARE

AGENTES - COMPONENTES


agentes Message, vide seção 4.8.6, utilizada para descrever os agentes de software

está orientada, fundamentalmente, ao desenvolvimento dos agentes de aplicação

do SCM. Um dos componentes do SCM, o de Controle e Comunicação não será

estruturado sob a arquitetura do agente Message. Primeiro, porque este não é de

aplicação e segundo, porque este componente está baseado no Projeto P815 da

Eurescom (2001a). A seguir descreve-se os diversos componentes e as suas

ligações com a visão de projeto do SCM mostrado na Figura 5.22:

• Controle e Comunicação: fornece a infra-estrutura básica para o

gerenciamento e a comunicação de agentes. É a plataforma sobre a qual

atuam os agentes;

• Interface: inclui formulários GUI para acesso às informações e

conhecimentos fornecidos pelos seres humanos. Possui as opções –

agregar, modificar, consultar e, eliminar. Reflete a funcionalidade

ElicitKnowledge da visão de projeto do SCM;

• Descobrimento: ao inicio é responsável pelo povoamento da Base de

Conhecimento, preenchendo o Organizational Baseline a partir da

captura de informação dos arquivos fontes previamente definidos, logo

faz a função de manutenção, atualizando o baseline quando houver

alguma mudança 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 visão de projeto do SCM;

• Busca e Entrega: dada uma requisição de informação/conhecimento,

consulta-se no repositório 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 repositório das

regras de inferência, para o qual deverá utilizar-se os axiomas da

ontologia para inferir respostas ante determinadas consultas. Está última

opção não é tratada no presente trabalho. Este componente reflete a

funcionalidade busca de conhecimento (SearchKnowledge), vide a Figura

5.22;


• Armazenamento e Disseminação: cada vez que o Organizational

Baseline é atualizado se cria um registro da transação no LOG com os

conceitos e atributos que tenham sido alterados. Logo, utiliza-se esse

arquivo para iniciar o processo de disseminação aos usuários

relacionados, os que deveram ter sido previamente cadastrados. Envolve

as funcionalidades ElicitKnowledge, CaptureKnowledge e

DisseminateKnowledge da visão de projeto do SCM. Este componente

agente interage com os componentes agentes Interface e Descobrimento.

• Usuário: cadastra os diferentes usuários da organização empresarial que

utilizarão o SCM, tendo em consideração as suas necessidades de

informação. Para definir o componente Usuário do SCM utilizou-se uma

instância do agente interface (Application Agent) da visão de projeto do

SCM;

• Armazenamento das Lições Aprendidas: povoa a base de casos com

experiências passadas, define também uma opção de busca por

similaridade. A funcionalidade armazenar tomadas de decisões

(StoreDecisionMaking) da visão de projeto é o origem deste componente.

5.5.1 O Componente Agente Plataforma de Controle e Comunicação

É o responsável por fornecer a infra-estrutura básica para o controle e

comunicação dos agentes de software. Essa infra-estrutura é operacionalizada por

meio de um conjunto de facilidades que são detalhadas a seguir (Eurescom,

2001a):

• Gerenciamento de agentes: inclui a criação, eliminação, registro

(marcação) e de-registro (desmarcação) na plataforma de controle e

comunicação;

• Negociação dos serviços do agente: representado pelo serviço de páginas

amarelas;

• Fornecimento de uma linguagem de comunicação de agentes e de uma

linguagem de conteúdo;

• Comunicação de agentes e de linguagem de conteúdo, representado pelos

protocolos de comunicação;


• Segurança da plataforma de controle e comunicação de agentes e de cada

agente em si.

O componente de plataforma de controle têm por sua vez os seguintes

componentes: o Facilitador de Diretório (Directory Facilitator – DF), o Sistema

de Gerenciamento de Agentes (Agents Management Sytsem - AMS) e o Canal de

Comunicação de Agentes (Agents Communication Chanel – ACC). Todos eles

são tipos específicos de agentes que suportam o gerenciamento e comunicação

entre sistemas de agentes. O AMS e o ACC suportam a comunicação entre

agentes, o ACC suporta a interoperabilidade dentro e através de diferentes

plataformas.

O primeiro caso acontece quando se tem um só SCM. O segundo, não

tratado no presente trabalho, acontece quando dois ou mais SCMs de diferentes

organizações querem se comunicar. Isto é possível hoje em dia, pois o mundo dos

negócios mudou, sendo comum o estabelecimento de redes de organizações na

forma de joint ventures, alianças estratégicas e fusões com clausulas que deixam

aberta a possibilidade de no futuro volver a separar-se.

Todos os agentes antes mencionados se comunicam através de um serviço

de roteamento (encaminhamento) de mensagens, o qual é denominado de

Transporte de Mensagens para Plataformas Internas (IPMT – Internal Platform

Messages Transport). Este serviço deve ser confiável 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 comunicação com os outros

componentes-agentes do SCM.

O padrão FIPA, que é utilizado neste componente, é uma plataforma de

agentes que facilita o gerenciamento destes, fornecendo também uma linguagem

de comunicação de agentes (Agents Communication Language – ACL), o FIPA-

ACL. No entanto, anota-se que também poderia ser utilizado qualquer outro tipo

de plataforma, por exemplo CORBA, como um meio básico para a comunicação

de agentes intra ou inter domínios e, para a comunicação com sistemas legados ou

para a comunicação entre componentes.


5.5.1.1 O Facilitador de Diretório (DF)

É um tipo de agente que fornece o serviço de “páginas amarelas” aos outros

agentes. O DF é o responsável pela manutenção e segurança do diretório de

agentes, para o qual mantêm uma lista exata, completa e oportuna dos agentes. Ao

mesmo tempo, o DF fornece informações atualizadas dos agentes, sobre uma base

não discriminatória, a todos os agentes autorizados. No entanto, o DF pode

também restringir o acesso a seu diretório, verificando todas as permissões de

acesso dos agentes que tentem se informar das mudanças de estado dos outros

agentes. O DF não controla o ciclo de vida interno de qualquer agente.

Os agentes registram seus serviços com o DF e também o consultam para

averiguar que serviços são oferecidos e por quais agentes. Tanto o AMS como o

ACC podem se registrar com o DF. Os membros de um diretório DF definem o

domínio do agente, onde um domínio é um espaço lógico fornecendo um contexto

dentro do qual os agentes podem se organizar e localizar entre eles. As operações

suportadas pelo DF são: deRegister (de-registro), modify (modificação), register

(registro) e search (busca).

5.5.1.2 O Sistema de Gerenciamento de Agentes (AMS)

O AMS exerce o controle e a supervisão sobre o acesso e uso do ACC,

previamente deve se registrar com o DF. Também é responsável pelo

gerenciamento das atividades do componente de controle, incluindo as

responsabilidades de criação e eliminação de agentes, bem como decidir se um

agente pode se registrar dinamicamente no DF e inspecionar a migração de

agentes para e desde outras plataformas. O AMS mantém um índice de todos os

agentes que são atualmente residentes na plataforma. As operações suportadas

pelo AMS são as seguintes: autentify (autentificar), registerAgent (registro de

agentes), deRegisterAgent (de-registro de agentes), modifyAgent (modificar

agentes), todas em tempo de configuração.


5.5.1.3 O Canal de Comunicação de Agentes (ACC)

Fornece uma rota para o contato e intercâmbio básico entre um agente e os

outros agentes, podendo incluir também 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 opção não é tratada neste trabalho.

Ressalta-se que somente mensagens endereçados a um agente podem ser enviados

por meio do ACC, para o qual utiliza-se a operação: forward (encaminhar).

5.5.1.4 A Comunicação de Agentes

A comunicação de agentes, seja intra agentes ou inter agentes, exige a

utilização de uma linguagem de comunicação 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 especificação

FIPA’97, 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> </reply-by>

<envelope>

<time-sent> </time-sent>

<time-received> </time-received>

<route> </route>

</envelope>

<language> </language>

<ontology> </ontology>

<protocol> </protocol>

<conversation-id> </conversation-id>

</message>


O primeiro elemento identifica o ato comunicativo que está sendo

comunicado, vide Tabela 5.7, definindo o significado principal da mensagem,

seguido por uma seqüência de parâmetros. Os parâmetros <sender> e <receiver>

definem os agentes de envio e recepção respectivamente. O parâmetro <content>

contem o conteúdo da mensagem, codificado em alguma linguagem previamente

definida a qual deve ter, por sua vez, um conjunto de parâmetros. Os parâmetros

<language> e <ontology> ajudam ao <receiver> a interpretar o significado da

mensagem. Os parâmetros <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 expressão a qual será utilizada pelo <receiver> para

identificar a mensagem original, quem responde utilizando o parâmetro <in-reply-

to>. Estes dois parâmetros podem ser utilizados para seguir o thread de uma

conversação, em situações onde vários diálogos ocorrem simultaneamente.

Communicative act

Information passing

Requesting information

Negotiation Action per forming

Error handling

accept-proposal �

agree

�

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 Especificação FIPA (Eurescom, 2001a)


O parâmetro <envelope> fornece informação útil da mensagem como por

exemplo hora de envio <time-sent>, hora de recepção <time-received>, rota

<route> e outros aspectos relevantes do serviço de mensagens. O parâmetro

<protocol> denota o protocolo que o remetente está utilizando, serve para dar um

contexto adicional para a interpretação da mensagem. O parâmetro <conversation-

id> é utilizado para identificar uma seqüência de atos comunicativos que juntos

formam uma conversação, fornece também um contexto adicional para a

interpretação do significado da mensagem. Os parâmetros podem colocar-se em

qualquer ordem. O único parâmetro que é mandatário 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 Negociação de Agentes

O objetivo de todo agente é maximizar seus interesses, enquanto tenta

alcançar acordos com outros agentes. Isto requer necessariamente a existência de

um processo de negociação, o qual exige uma seqüência de ofertas e contra-

ofertas que minimize o custo ou maximize o beneficio, dependendo do papel que

o agente esta desempenhando. O processo de negociação faz uso do ACL que

fornece os atos comunicativos que a operacionalizam, sendo estes os seguintes:

• cfp –(calling for proposals) ação de chamada de propostas para executar

uma ação dada,

• propose – ação de submeter uma proposta para executar uma certa ação,

dadas certas pre-condições,

• accept-proposal – ação de aceitar uma proposta previamente submetida

para executar uma ação,

• reject-proposal – ação de rejeitar uma proposta para executar alguma

ação durante uma negociação.

5.5.1.6 Protocolos de Negociação

A troca contínua de mensagens de negociação freqüentemente cai em padrões

típicos. Nesses casos, são esperadas certas seqüências de mensagens e em algum


ponto da conversação outras mensagens são esperadas que sigam. Estes padrões,

chamados de protocolos de negociação, facilitam a simplificação da conversação

para o alcance de acordos e a efetiva interoperação de agentes.

O padrão FIPA provê dois protocolos que podem ser utilizados na negociação,

o FIPA-contract-net e o FIPA-iterated-contract-net, sendo o último uma extensão

do primeiro, vide Figura 5.27 (Eurescom, 2001a) .

not-understoodFIPA-ContractNet

refusereason

Deadline

reject-offerreason

preconditions3

failurereason

informDone(action)

performaction

accept-offerpreconditions3

counter-offerpreconditions4

bidpreconditions2

cfpactionpreconditions1

Figura 5.27 O Protocolo FIPA-iterated-contract-net

5.5.2 O Componente Agente Interface

Este componente-agente é responsável pela entrada de informação que não

pode ser capturada de forma automática a partir da camada de fontes de dados.

Para esta tarefa utiliza-se um conjunto de formulários (forms), os quais refletem as

características dos conceitos e atributos que foram elicitados durante a análise do

domínio, etapa de criação da ontologia do negócio. A definição de cada

formulário do agente interface, deve evidenciar a sua estrutura declarando os seus


correspondentes atributos. Isto é necessário porque cada especialização deste é

uma entidade do Organizational Baseline e portanto diferente de qualquer outra.

Segundo o modelo de negócio estabelecido anteriormente na seção 5.2, as

suas diferentes entidades estão relacionadas entre si, o que significa que tem que

se considerar as possíveis implicâncias quando alguma delas muda no baseline.

Em outras palavras, a especialização do agente interface tem que levar em conta o

impacto que uma mudança, em alguma entidade, pode ter nas outras entidades

vinculadas a esta. Nesse sentido, a complexidade e dificuldade de uma

especialização do agente interface irá depender fundamentalmente de seus

relacionamentos existentes com as outras entidades (instancias do agente

interface).

Agent beliefList goalList planList

setBelief() addBelief() setGoal() addGoal() setPlan() addPlan()

Company

Business

Client

Domain Manager

• dataChecking() • getEntity() • getEntityList() • setEntity() • addEntity() • elimineEntity()

Resource Manager • addLog() • sendMessage() • showMessage() • receiveMessage() • retrieveFormGUI() • deleteEntity() • readEntity() • writeEntity() • updateEntity() • openDB() • closeDB()

UserProfile Manager DML Manager Perception & Communication

Manager

Domain Layer Resource

Layer Decision&

Management Layer Perception&

Communication Layer

Storing& Dissemination Agent

User Agent

InterfaceAgent

• analysingEvent() • analysingMessage() • inform() • reject() • propose() • finish() • accept() • forward()

• makingDecision() • creation() • destruction() • monitoring() • captureEvent()

• retrieveUser() • storeUser()

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 características gerais do

agente como são o cadastramento dos pensamentos (Beliefs), metas (Goal) e

planos (Plans). Mostra-se também na figura algumas das possíveis

especializações do agente interface como são Companhia (Company) , Negócio

(Business) e Cliente (Client), porém de fato existem outras especializações como

as definidas no modelo do negócio. De acordo à seção 4.8.6 um agente Message

tem os seguintes componentes: Recursos (RL - Resource Layer), Domínio (DL -

DomainLayer), Percepção e Comunicação (PCL - Percepção & Comunication


Layer) e, Decisão e Gerenciamento (DML – Decision & Management Layer), nos

parágrafos seguintes detalha-se cada um deles no âmbito do agente interface.

O componente DL (Domain Layer) tem a operação dataChecking, a qual é

responsável pela checagem dos dados ingressados no formulário. A checagem

pode ser de dois tipos: de unidade (sub-operação dataCheckingUnitary), quando

se checa cada atributo em forma independente, e de integridade (sub-operação

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 Liderança � Colaborativa, e

Forma de Governo � Autocrático

para que não aconteça esse tipo de situação é que existe a operação dataChecking.

Outras operações fornecidas pelo DL são: agregar entidade (addEntity), eliminar

entidade (elimineEntity), obter entidade (getEntity), atualizar entidade (setEntity) e

obter lista de entidades (getEntityList).

O componente RL (Resource Layer) não só é responsável pela execução de

ações sobre o mundo externo, como também pela recepção de mensagens. Inclui

entre as suas funções a recuperação de recursos internos como é o caso dos

formulários GUI. As operações definidas para este componente são: recuperação

de formulários 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 existência 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 existência de uma implementação do proxy no servidor

(informServer) - os servers oferecem uma implementação para uma interface que

é acedida pelos proxies. Outras operações são: mostrar formulário GUI

(showFormGUI), mandar mensagem a outro agente ou usuário (sendMessage) e

receber mensagem de outro agente ou usuário (receiveMessage).

O componente DML (Decision & Management Layer) é responsável pelo

controle das ações do agente através de decisões deliberativas; para isso faz o


monitoramento do ambiente externo, capturando os eventos que refletem as

mudanças no baseline. Outra de suas funções é o gerenciamento do mesmo

agente, realizando tarefas de criação, destruição e monitoramento. As operações

definidas para o DML são: executar uma determinada tomada de decisão baseada

nas condições de estado dos atributos e das variáveis do ambiente externo

(makingDecision), criar uma instãncia do agente (creation), eliminar uma

instância do agente (destruction), fazer o monitoramento do agente (monitoring) -

exceto as mudanças no baseline - e capturar os eventos do ambiente externo

(captureEvent).

O componente PCL (Perception & Communication Layer) recebe tanto

informações de baixo nível do mundo externo via o RL, como informações de alto

nível via o DML. No primeiro caso, recebe o conteúdo das mensagens e no

segundo, o tipo de evento. Este componente têm como operações: analisar o

evento recebido (analysingEvent), analisar o conteúdo da mensagem

recebida(analysingMessage), solicitar o estabelecimento de comunicação

(request), informar o estado da comunicação (inform), rejeitar a mensagem

(reject), propor alguma alternativa (propose), finalizar a comunicação (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 formulário GUI especifico por meio da operação

retrieveFormGUI do RL, o mesmo que é preenchido pelo usuário, em seguida o

DML através da operação captureEvent captura a ação a ser realizada analisando

o tipo de evento através da operação analysingEvent, logo o transmite ao DL, via

a operação forward do PCL, que executa a operação dataChecking, a mesma que

analisa o conteúdo do formulário e determina que conceitos e atributos devem ser

checados. Finalmente, o RL recebe do DL o conteúdo checado e atualiza o

Organizational Baseline, utilizando as operações addEntity ou setEntity. Como

aconteceu uma mudança 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 disseminação que grava o registro no

arquivo LOG.


O agente interface deveria interagir diretamente com o agente usuário, pois

após a atualização de alguma entidade sabe-se que essa mudança na entidade ou

nos seus atributos, eventualmente, poderia afetar ou ser de suma importância para

determinados usuários. Então, o ideal seria que o agente interface tenha dentro do

PCL um log-Manager, encarregado de fazer a comunicação com o agente usuário.

Mas é bom lembrar que o Organizational Baseline não é só atualizado pelo agente

interface, como também 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, responsável exclusivo pelo

armazenamento e disseminação do conteúdo do arquivo LOG, o qual deve

comunicar-se com o agente usuário para atingir o objetivo do SCM, de disseminar

os novos conhecimentos que foram colocados no baseline. Esses agentes serão

analisados nas próximas seções.

5.5.3 O Componente Agente Usuário

O componente agente usuário é responsável pelo gerenciamento dos dados

do perfil do usuário. Desde o ponto de vista estrutural os atributos básicos deste

agente são nome, cargo, unidade organizacional, entidades com as quais está

relacionado e atributos aos quais têm acesso. Instâncias de agentes usuários são

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 situação que pode acontecer em não

poucos casos: que um determinado usuário tenha acesso a determinada entidade,

mas não a todos os atributos da mesma. Alguns atributos podem ter restrições de

acesso por conter informação confidencial. O ponto referente a segurança não é

tratado na presente tese, fica para futuros trabalhos do SCM.

A seguir declara-se as principais operações dos componentes do agente

usuário: o DL tem as operações: validar a informação ingressada no formulário

usuário (dataCheckingUser), agregar usuário (addUser), modificar usuário

(modifyUser), eliminar usuário (elimineUser), obter usuário (getUser) e obter lista

de usuários (getUserList). O RL têm as operações recuperar formulário do usuário


(retrieveFormUser), sendMessage, receiveMessage, showMessage, mostrar dados

do usuário (showUser), apagar dados do usuário (deleteUser), ler no banco de

dados (readUser), gravar no banco de dados (writeUser), atualizar no banco de

dados (updateUser), openDB e closeDB. O PCL têm como operações

analysingEvent, analysingMessage, inform, reject, propose, finish, accept e

forward. As operações do DML são: makingDecision, creation, destruction,

monitoring, e captureEvent. Tanto as operações do PCL e do DML são similares

às definidas no componente agente interface. Na Figura 5.29 mostra-se as

operações antes citadas.

Agent beliefList goalList planList setBelief() addBelief() setGoal() addGoal() setPlan() addPlan()

Financial Manager Marketing Manager

Requirement Engineer

Domain Manager

• dataCheckingUser() • getUser() • getUserList() • modifyUser() • addUser() • elimineUser()

Resource Manager • retrieveFormGUI() • sendMessage() • showMessage() • receiveMessage() • showUser() • deleteUser() • readUser() • writeUser() • updateUser() • openDB() • closeDB()

DML Manager Perception & Communication Manager


Layer Decision&


Communication Layer


InterfaceAgent

UserAgent



Figura 5.29 O Componente Agente Usuário

O agente usuário interage diretamente com o agente de armazenamento e

disseminação, o qual tem entre as suas funções a de espalhar informação /

conhecimento por toda a organização. O agente de armazenamento e

disseminação por sua vez interage com os agentes de descobrimento e de

interface, que são os encarregados de capturar conhecimento relevante, o primeiro

de forma automática a partir dos repositórios que se possuem na organização ou

de fontes disponibilizadas na web, o segundo, como resultado do preenchimento

de informações via os formulários GUI.

O processo de espalhamento de conhecimento a partir do agente

armazenamento e disseminação é realizada como segue: primeiro, o agente

usuário recebe a mensagem através da operação receiveMessage, a qual é passada


à operação analysingMessage, que analisa o seu conteúdo para tomar alguma

ação, automática ou para simples conhecimento do usuário humano.

5.5.4 O Componente Agente Descobrimento

Este componente é o responsável pela extração de informações da camada

dos arquivos fontes, tanto no inicio para começar a povoar o Organizational

Baseline, como após sua criação, na sua manutenção, para manter atualizado o

conhecimento mantido nele. A característica ou funcionalidade principal deste

componente agente é, simplesmente, “ouvir” mudanças nos arquivos fontes e

atualizar o baseline. Para cada tipo de fonte é necessário criar uma instância deste

agente, um wrapper que capture a informação requerida contida nela com o

propósito de atualizar os conceitos e atributos do baseline. Um wrapper é um tipo

de software denominado também de “glueware” [(Eskelin, 1999; Scheneider,

1999) em (Barbosa, 2001)], que atua junto com outros componentes de software.

Embora não exista uma clara demarcação 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 informação do arquivo fonte e

atualiza o repositório de destino. Em particular, para o desenvolvimento de um

wrapper devem ser analisadas que fontes de dados serão tratadas pelo wrapper e

se estas estão bem documentadas, como também quais são as suas funções, como

foram construídas e qual é a sua estrutura interna.

Uma das fontes do SCM são os sistemas legados, bancos de dados e outros

arquivos próprios da organização, 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

são as páginas web da internet, as quais utilizam linguagens de marcação HTML

ou alguma de suas variantes. Usualmente é possível conhecer a estrutura destes

arquivos, quando seu conteúdo não está oculto, e obter sem maior dificuldade a

informação contida nela, pois basta ler os seus tags. O problema surge quando o

dono da página web muda a sua estrutura: nesse caso é necessário que esta se

análise novamente para detectar os tags de interesse. Pode também ocorrer que o


dono da página web de “moto próprio” oculte o seu conteúdo: nessa situação será

materialmente impossível lê-los, pois não existiria uma solução fatível viável.

Outro tipo de fontes de dados são os arquivos XML (eXtended Markup

Language). A linguagem XML é uma linguagem para a interoperabilidade de

dados, mas que também é utilizado como uma forma de armazenamento de dados

(sob a forma de documentos) e para a construção de web services. O web service é

qualquer serviço que está disponível sobre a internet, usa um sistema padrão de

mensagens XML e, não está limitado a algum sistema operacional ou linguagem

de programação. Outras propriedades do web service é que este deve ser auto-

descritivo (fornecer uma interface pública para o serviço em XML com sua

documentação textual) e fácil 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 opção, pois o

interesse está em capturar informação específica para preencher o repositório de

conhecimento.

Conhecendo a definição do documento XML se estaria em um caso similar

aos arquivos fonte proprietários da empresa, pois se conheceria a sua estrutura e

se poderia desenvolver programas wrapper que capturem a informação requerida.

No caso dos web services a descrição dos serviços é realizada por meio do uso da

Linguagem de Descrição de Serviços (Web Service Description Language –

WSDL) (Cerami, 2002). O WSDL faz uso da gramática XML para a

especificação da interface pública dos serviços web. Esta interface inclui

informações sobre todas as funções disponíveis, tipos de dados utilizados nas

mensagens XML, informações do protocolo de transporte a ser utilizado e

endereço do serviço especificado. Mas tudo isso implica obviamente uma cultura

que envolva e motive o compartilhamento de informações além da própria

organização. Em resumo, seja qual for o tipo dos arquivos fontes acima

explicados, é necessário conhecer a sua estrutura para que possa se extrair a

informação procurada.

O componente de Descobrimento tem duas funcionalidades especificas: o

serviço de descobrimento em si e o serviço “ouvinte” de descobrimento. O

descobrimento em si tem um conjunto de operações que são detalhadas a

continuação: executar a consulta na fonte de dados (executeQuery), receber os


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 extraídos do arquivo

fonte no Organizational Baseline (writeDataOB). O serviço “ouvinte” realizado

por meio da operação listenerDiscover, roda de forma permanente no servidor,

checando de tempo em tempo qualquer mudança que houver nos arquivos fonte,

devendo disparar o processo que ative as operações do serviço de recuperação de

informação, quando houver algum câmbio.

Agent beliefList goalList planList setBelief() addBelief() setGoal() addGoal() setPlan() addPlan()

Wrapper Source “A”

Wrapper Source “B”

Domain Manager

• dataChecking() • executeQuery() • resultQuery()

Resource Manager • retrieveStateQuery() • retrieveStateSource() • retrieveMetadadosSource() • sendMessage() • showMessage() • receiveMessage() • readSource() • openSource() • closeSource() • writeDataOB()



Layer Decision&


Communication Layer


Discovering Agent


• makingDecision() • creation() • destruction() • monitoring() • listenerDiscover()

Wrapper Source “C”

Figura 5.30 O Componente Agente de Descobrimento

O wrapper deve ser instanciado dependendo do tipo do arquivo fonte e a sua

forma de comunicação. Nesse sentido, para cada tipo de fonte de dados a ser

integrada no Organizational Baseline do SCM, deve haver um wrapper específico,

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).


5.5.5 O Componente Agente Busca

Os repositórios principais do SCM são o Organizational Baseline e o de

Lições Aprendidas (Base de Casos de Experiências). Com o intuito de delimitar o

processo de busca em ambos repositórios, decidiu-se que a busca no repositório de

casos seja tratado em forma separada, isto pela sua própria característica: buscar

uma solução para um determinado problema, vide detalhes na seção 5.5.7.

Delimitado o escopo deste componente, o mesmo estará centrado exclusivamente

na recuperação de informações do Organizational Baseline, definiu-se duas

alternativas de busca: uma primeira de navegação, utilizando para isso a árvore da

ontologia do negócio e uma segunda, de busca por termos no baseline, utilizando-

se como um meio de busca os conceitos da ontologia.

A opção de navegação envolve a realização 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 serão

utilizados tanto no processo de extração via a opção de navegação como de busca

por termos. A ontologia também contém a nível interno uma lista de sinônimos

apontando aos conceitos base, porém estes sinônimos não aparecem na árvore de

navegação. Nesse sentido, quando um usuário clicar sobre o link de um conceito,

o SCM deve mostrar uma tela com os itens mais relevantes, em ordem de

importância, sendo o primeiro deles o conceito solicitado e os subseqüentes os

termos relacionados, eventualmente o usuário pode desejar estender seu

conhecimento clicando sobre estes últimos.

A opção de busca por termos implica o uso de heurísticas de similaridade,

assim, por exemplo, se o usuário coloca a palavra empresarial e esta não existe

como uma entidade no Organizational Baseline, o sistema deve ser capaz de

mostrar ao usuário que o conceito mais perto deste é empresa. Maior

complexidade pode se apresentar quando o usuário coloca duas ou mais palavras

ou conceitos a procurar, aí deverá de estabelecer-se heurísticas apropriadas, como,

por exemplo, o tratamento de conetivos lógicos, sinônimos, termos relacionados,

similaridade, entre outros. de maneira tal que a operação de busca possa ter um

maior leque de possibilidades de sucesso.


As operações que este componente deve ter são basicamente as seguintes:

createTreeOntology, cria o formulário onde se mostra as opções de navegação 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 estratégia de negócios, sob uma abordagem

top-down. Quando o usuário clicar sobre o link de algum termo da ontologia o

SCM deve mostrar o conteúdo desse termo (operação showConcept), assim como

os links dos termos relacionados (operação showLinks), quando clicar encima de

algum termo relacionado se utiliza novamente a operação showConcept. Para o

caso de busca utiliza-se a operação searchConcept, a qual fornece um conjunto de

links com os termos que melhor satisfazem a consulta. Logo o usuário pode

selecionar aqueles que ele achar melhor atingem a sua busca. O searchConcept

utiliza para o processo de busca uma ou mais heurísticas, como podem ser a

estratégia de sinônimos, termos relacionados ou de sintaxe junto à estratégia de

similaridade dos termos. Existem inúmeras formas para encontrar a similaridade,

sendo um tópico de amplo estudo nos últimos tempos pelo surgimento da internet.

Na Figura 5.31 mostra-se as principais operações deste componente.



Navigation Search

Domain Manager

• searchConcept() • getConcept() • createTreeOntology()

Resource Manager • retrieveFormSearch() • retrieveTreeOntology() • retrieveMetadadosSource() • sendMessage() • receiveMessage() • showConcept() • showLinks() • readConcept() • openOB(), openOntology() • closeOB(), closeOntology() • writeDataOB()



Layer Decision&


Communication Layer

UserAgent

Search Agent



Concept Search

Services

Figura 5.31 O Componente Agente de Busca


5.5.6 O Componente Agente Armazenamento e Disseminação do LOG

Este componente agente é o encarregado e responsável por armazenar,

gerenciar e viabilizar o acesso às metainformações dos dados que foram

agregados e/ou atualizados no Organizational Baseline, bem como pela

disseminação desse novo conhecimento aos usuários 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 seção 5.5.2 é um exemplo.

Quando o baseline é atualizado a partir de um formulário, o log registra as

entidades (conceitos) e atributos que tenham mudado. Notar que os atributos de

um conceito no baseline podem ser resultado da integração de várias fontes de

dados, portanto, quando alguma dessas fontes sofre alguma mudança, os agentes

de descobrimento (ouvintes) deverão atualizar os atributos correspondentes do

conceito no baseline. Outra situação que pode se apresentar é quando um atributo

é o resultado de duas ou mais outras fontes, aqui também se está em frente de um

problema de integração, geralmente de sumarização de dados numéricos. 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 seção 5.3.1, mostrou em um alto nível 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

seção 5.5.2. A estrutura do registro log, vide Tabela 5.8, é como segue:

Atributos Tipo de dados

Código do Log Numérico (seqüencial)

MetadadosConceito String (Mime)

Indicador de Leitura Numérico (0..1)

Tabela 5.8 Estrutura do Registro log

Sabe-se que cada fonte de dados possui seus próprios metadados, assim, o

atributo MetadadosConceito é estruturado como do tipo String, sendo o seu

conteúdo formado pelo nome do conceito (entidade ou nome da tabela) seguido

dos atributos que mudaram. Em geral, o atributo MetadadosConceito tem a

seguinte estrutura:


(*nome_conceito* + (?nome_atr ibuto?)1..n) 1..n

Para cada conceito existe um ou mais atributos que podem ter mudado, o

nome do conceito tem como delimitador o símbolo “ *” , antes e depois do

conceito, o nome do atributo que mudou tem como delimitador o símbolo “?” ,

também 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 formulário do conceito Companhia (agente

interface) o qual têm como atributos Nome da companhia, Empresa Matriz,

Missão, Visão, entre outros. Suponha-se que os atributos Missão e Visão tenham

mudado, então o registro log desta mudança havida no Organizational Baseline é

como segue:

25*Companhia*?Missão??Visão?0

onde o número 25 representa o código seqüencial do registro log e o zero no final

significa que este ainda não foi processado. O código seqüencial é incrementado

automaticamente em uma unidade cada vez que um novo registro é adicionado no

arquivo LOG. O indicador de leitura é zero (0) quando criado (ainda não

processado) e um (1) depois de ter sido processado pelo componente, o agente de

armazenamento e disseminação.

Agent

beliefList goalList planList setBelief() addBelief() setGoal() addGoal() setPlan() addPlan()

Domain Manager • processingMetadataLog() • getLog()

Resource Manager DML Manager

Perception & Communication Manager

Domain Layer Resource Layer Decision& Management Layer

Perception& Communication Layer

InterfaceAgent


• addLog() • deleteLog() • readLog() • updateConditionLog() • updateSequenceNumber()• sendMessage() • receiveMessage() • getUser()

• analysingChange() • listeningRegLog() • analysingEvent(0 • analysingMessage()

• makingDecision() • creation() • destruction() • monitoring() • listeningChange() • captureEvent()

Discovering Agent

Storing

Dissemination Services

Figura 5.32 O Componente Agente Armazenamento e Disseminação

Na Figura 5.32 observa-se as principais operações ou serviços do agente

armazenamento e disseminação. A seguir explica-se o funcionamento deste agente

para o caso do armazenamento no arquivo LOG, logo se faz o mesmo para o caso


de disseminação. Na primeira situação, suponha-se que se recebe a comunicação

(mensagem) do agente interface, podendo também ser do agente descobrimento,

por meio da operação receiveMessage do RL, o qual encaminha o conteúdo da

mesma ao PCL que o analisa por meio da operação analysingMessage,

retornando-o logo ao RL que atualiza o LOG utilizando a operação addLog

(agregar registro log).

Na segunda situação, o agente de armazenamento e disseminação através da

operação thread listeniungChange do DML “ouve” que novos registros log têm

sido adicionados ao arquivo LOG do SCM, é dizer que o baseline da memória

corporativa tem sido atualizado com novas informações, comunicando esse evento

ao PCL, o qual o analisa, via a operação analysingChange, para verificar se

verdadeiramente novos registros têm sido adicionados. Após isso, comunica-se

com o DL e lê os registros do LOG utilizando a operação getLog, o qual por sua

vez utiliza a operação readLog do RL. A atualização do indicador de leitura do

registro lido é realizado pela operação updateConditionLog. O processamento do

conteúdo dos metadados do Log faz-se via a operação processingMetadataLog do

DL, extraindo-se o conceito e os atributos que mudaram. A seguir, procura-se

através do getUser do RL, aqueles usuários para os quais essas mudanças têm um

efeito relevante, finalmente, envia-se uma mensagem aos usuários via a operação

sendMessage do RL.

5.5.7 O Componente Agente Armazenamento de Lições Aprendidas

Como resultado da turbulência na qual têm que atuar as organizações, como

dito na introdução do presente trabalho, tem-se salientado a importância do know

how como um ativo organizacional, o mesmo que necessita ser gerenciado com o

intuito de que a organização obtenha uma vantagem competitiva sustentável. Uma

forma de representar o know-how, também chamado de ativos do conhecimento, é

por meio das lições aprendidas (experiências passadas relevantes, aplicação de

determinados procedimentos ou técnicas), modelos específicos (de qualidade,

distribuição de carga de trabalho, custos, segmentação de mercado) ou

documentos corporativos (planos de marketing, produção, qualidade). Estes são


armazenados na base de casos do know-how, a qual na arquitetura do SCM é um

repositório independente do Organizational Baseline.

As lições aprendidas são, basicamente, experiências relevantes que

aconteceram no passado e que por sua relevância são armazenadas para o seu

posterior reuso. Assim, não são armazenadas todas as experiências, senão só

aquelas que após uma análise profunda, feitas pelo pessoal das áreas envolvidas,

considera-se que constituem uma experiência digna de se manter, daí também a

denominação de boas práticas. Exige-se que estas, sempre que possível, sejam

validadas. As lições aprendidas podem incluir também experiências mal sucedidas

que mostrem erros que aconteceram no passado sob determinadas situações e que

se espera não devam se repetir no futuro.

Definido aquilo que deve se armazenar com relação ao know how

corporativo, o passo seguinte é operacionalizar a recuperação e disseminação

dessas experiências, para o qual utiliza-se a abordagem do raciocínio baseado em

casos (Case-Based Reasoning – CBR), a qual em anos recentes tem sido

considerada como uma técnica adequada para suportar o desenvolvimento de

sistemas de aprendizado baseados em conhecimento (Althoff et al., 1998). No

entanto, prévio ao problema de recuperação e disseminação existe a questão da

identificação e modelagem das experiências a serem armazenadas no repositório

de casos do SCM. O que resta desta seção está baseado no trabalho de

Wangeheim & Rodriguez (2000) para o domínio de Engenharia de Software, o

mesmo que foi adaptado aqui para o domínio da estratégia de negócios. O

algoritmo de recuperação utilizado é apresentado em detalhe na seção 4.9.

5.5.7.1 Estruturando a Base de Experiências

Um dos pontos críticos quando se utiliza o raciocínio baseado em casos é a

estruturação das experiências, existindo dois problemas: primeiro a

contextualização do caso com o intuito de facilitar a sua recuperação e, segundo o

caso em si mesmo. A contextualização irá depender do domínio especifico que

está se tratando, devendo se definir um conjunto de atributos ou características

que coadjuvem à identificação mais exata da experiência. O caso poderia se

estruturar da seguinte forma:


Contexto: Conjunto de atributos que melhor caracterizem o problema

Problema: Definição do problema-caso

Causa: Explicação das possíveis causas do problema

Solução: Explicação das possíveis soluções ao problema definido

Resultados: Descrição dos resultados da solução proposta

Usualmente toda empresa de porte tem um manual de procedimentos para as

situações típicas que acontecem no dia-a-dia, onde se descreve os passos

necessários para tratá-as. No entanto, a empresa e o seu entorno não são estáticos

mas bem dinâmicos, o que implica que podem aparecer novas situações,

chamadas de atípicas, para as quais não existe um procedimento predeterminado.

Nessas situações, o pessoal envolvido necessita de algumas sugestões que o

ajudem a resolvê-las ou a tratá-las da melhor forma. Porém, 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 organização. Aí é onde surge a

importância de contar com um repositório de casos, que armazene experiências

relevantes, para não dedicar esforços em resolver novamente um problema que

pode ter sido antes tratado ou resolvido com sucesso.

Departamento Créditos e Cobranças Seção Avaliação Tipo de Cliente Pessoa Física Quantia do crédito 4000 reais Tipo de problema Inadimplencia Problema O cliente C001 não tem pago as suas contas

desde há 3 meses, ele não tem avalista pois estava catalogado como um cliente especial

Tabela 5.9 Exemplo de um problema e seu contexto

A seguir mostra-se um exemplo, seja o Departamento de Créditos e

Cobranças da empresa “ABC”: o problema detectado é que o cliente C001

recebeu um crédito da empresa, mas após um certo período 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 serviço e que está impossibilitado

de honrar seus pagamentos. Sabe-se também 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

(situação presente) e na Tabela 5.11 o caso solução para esse problema.


Base de Casos Atr ibutos Relevância Situação

Presente CASO CC03

CASO CC05

CASO C007

Contexto

• Departamento Alta Credito e Cobranças

Crédito e Cobranças



• Seção Muito importante

Avaliação Avaliação Aprovação Avaliação

• Tipo cliente Importante Pessoa física

Pessoa física

Pessoa física

Pessoa jurídica

• Quantia do credito

Pouco importante

4000 5000 1000 3000

• Local Irrelevante Rio de Janeiro

São Paulo Belo Horizonte

Porto Alegre

• Morosidade Muito importante

90 dias 90 60 120

Problema

Causa

Solução

Resultado

Tabela 5.10 A Base de Casos, seus atributos e relevância dado o problema

Departamento Créditos e Cobranças

Seção Avaliação

Tipo de Cliente Pessoa Física

Caso Recuperado CC03

Monto do crédito 5000 reais

Tipo de problema Morosidade

Problema O cliente não tem pago as suas contas desde há 4 meses, ele não tem avalista pois estava catalogado como um cliente especial

Causa O cliente foi demitido sem causa justa, o que lhe impossibilitou cumprir com as suas obrigações.

Solução Ampliou-se o prazo de pagamento ao cliente até 12 meses, com parcelas menores.

Resultado Ao termino dos 12 meses o cliente cumpriu com o pagamento que tinha com a empresa.

Tabela 5.11 Recuperação de um caso dado um problema

5.5.7.2

Operações do Componente Agente de Lições Aprendidas

As operações básicas que são necessárias para o adequado funcionamento

deste componente são: recuperação do formulário do caso (retrieveFormCase),

agregar um novo caso (addCase), modificar um caso existente (modifyCase),


eliminar um caso (elimineCase), mostrar um caso (showCase), e busca de casos

(searchCase).

Na Figura 5.33 mostra-se todas as operações deste componente. Percebe-se

que a operação mais importante é o searchCase porque este é o que permite a

recuperação dos casos mais relevantes que possam ajudar à resolução ou

tratamento do problema em agenda. Está operação utiliza o algoritmo apresentado

na seção 4.9.



Domain Manager

• dataCheckingCase() • addCase() • modifyCase() • elimineCase() • getCase() • searchCase()

Resource Manager • retrieveFormCase() • showCase() • sendMessage() • receiveMessage() • readCase() • writeCase() • updateCase() • openCase() • closeCase()



Layer Decision&


Communication Layer

CaseBase Agent



Figura 5.33 O Componente Agente da Base de Casos

6 Apresentação do Protótipo

Com o objetivo de mostrar, na prática, as características da proposta

arquitetural do SCM desenvolveu-se o protótipo apresentado neste capítulo. A

implementação, embora parcial pelo fato de ser um protótipo, abrange as

funcionalidades básicas do SCM, os seus serviços de busca e disseminação

automática. Nas seções 5.4.2 e 5.4.3 estão apresentados esses serviços básicos do

SCM. O desenvolvimento do protótipo envolveu a programação dos componentes

Busca, Interface e Armazenamento e Disseminação, cujos detalhes arquiteturais

foram apresentados nas seções 5.5.2, 5.5.3, e 5.5.6. Optou-se pelo

desenvolvimento destes componentes somente para tornar visível os principais

serviços do SCM.

O protótipo do SCM, como qualquer aplicação, 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 extraídos os dados para a validação da

proposta da memória corporativa. Ressalta-se que esses dados ajudaram de

sobremaneira na apresentação dos serviços e das características básicas do SCM.

Destaca-se, também, que o propósito do presente capítulo não é apresentar o

diagnostico organizacional nem mesmo desenvolver alguma estratégia para a

Multicom, como é o objetivo do estudo de caso na sua forma original. O propósito

é explicitar, através do uso do protótipo do SCM, como este poderia ser utilizada

no processo de Gestão do Conhecimento, tanto pelos consultores como pelos

funcionários e executivos da Multicom.

Na seção 6.1 descreve-se o estudo de caso de forma sucinta, com o

propósito de que o leitor possa compreender melhor o âmbito da empresa, bem

como os termos e descrições a serem utilizadas na demonstração do protótipo.


6.1 O Caso da Empresa Multicom

A Multicom é uma pequena empresa que desenvolve as suas atividades na

área de Relações Públicas, empregando 150 pessoas. Iniciou as suas operações há

7 anos com Jim Walsh, especialista em Marketing, e Wendy Bridges, com ampla

experiência na área de relações públicas, cada um deles com 40% das ações

(participações), ambos tinham na época 34 e 33 anos respectivamente. Juntos

haviam trabalhado por vários anos em uma empresa de comunicações de médio

porte. Antes de se demitirem convenceram dois outros colegas, Marie Beaumont,

produtora de filmes e vídeos, e Frank Rossi, redator e autor de excelente

reputação, para se unirem a eles como acionistas minoritários (ambos com 10%

das ações). Estes últimos tinham no inicio das operações da empresa 23 e 24 anos

respectivamente.

A Multicom tinha um modelo de organização orientado ao cliente (cada

cliente era um projeto). Entretanto, há quatro anos as coisas começaram a mudar,

Walsh e Bridges decidiram estruturar melhor a companhia. Inicialmente,

Beaumont and Rossi não aprovaram as mudanças, porém, decidiram continuar na

companhia, enquanto os funcionários comentavam que a Multicom estava

perdendo as suas características 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 funcionários.

Gradualmente a Multicom começou a perder a sua imagem de uma companhia

líder no mercado, enquanto a Media 2000 rapidamente se consolidava como uma

agência capaz e inovadora. Desde que Beaumont and Rossi saíram, os resultados

financeiros da Multicom diminuíram fortemente, sendo o clima organizacional

afetado seriamente. Perante esses fatos, Walsh and Bridges decidiram contratar

uma firma de consultoria para fazer um diagnóstico organizacional e propor uma

nova estratégia para a Multicom.

6.2 Os serviços do SCM

Usualmente quando se realiza um trabalho de consultoria de negócios como

o requerido pela Multicom, o primeiro passo é fazer um levantamento de


informações que facilite o conhecimento da organização como um todo, pois,

embora as firmas de consultoria tenham experiência nesse tipo de atividades e

muitas vezes no setor onde a empresa cliente atua, sabem que sempre existem

particularidades inerentes à empresa sob análise. Essas particularidades exigem

que os consultores façam esse levantamento antes de começarem as entrevistas

com os executivos e funcionários da organização, cuja disponibilidade de tempo é

exígua e valiosa no atendimento de suas atividades. É nesse ambiente de trabalho

que os consultores utilizarão o SCM, levando a um uso racional de seu próprio

tempo e de seus clientes.

A seguir lista-se algumas perguntas usuais que todo consultor realiza, bem

como as localizações das possíveis respostas para estas no repositório do

conhecimento:

a) Que tipo de estrutura a Multicom possui? Esta informação é 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 Liderança e Cultura Corporativa, das entidades

Companhia e Negócio.

c) A Multicom possui um nicho de mercado? A resposta a esta questão

pode ser encontrada na entidade Companhia (atributos Mercado e Setor

de Atuação). Também são relevantes as entidades Objetivos Estratégicos

e Fatores Críticos.

d) Qual a atual estratégia da Multicom? Esta questão pode ser atendida pela

entidade Companhia (atributos Missão, Visão). Também pelas entidade

Objetivos Estratégicos.

Com isso mostra-se, intuitivamente, que a modelagem do modelo do

negócio e a sua representação no Organizational Baseline, respondem às questões

propostas no estudo de caso. Todas essas questões, antes citadas, são satisfeitas

pelo protótipo.

O propósito em desenvolver o protótipo do SCM, como definido ao inicio

desde capítulo, foi mostrar os serviços de busca e disseminação automática,

funcionalidades chave em todo processo de gestão do conhecimento. O passo


seguinte foi escolher o ambiente de desenvolvimento e as tecnologias a serem

utilizadas. Visando sua execução em um ambiente de rede na internet, primeiro,

instalou-se um servidor de aplicações, o Tomcat, o qual é um software livre e

amplamente utilizado no meio acadêmico. Logo, das diversas alternativas que

existem para o desenvolvimento de aplicações na internet, tais como o JSP, ASP,

APPLET e SERVLET, selecionou-se a alternativa do SERVLET porque esta é

uma tecnologia relativamente madura, além de bastante difundida tanto no meio

acadêmico como na indústria. Para suportar os arquivos que armazenem as

informações e conhecimentos organizacionais utilizou-se o gerenciador de banco

de dados MS-Access.

Estabelecida a plataforma onde se desenvolverá o protótipo, a atividade

seguinte foi definir os repositórios necessários a serem utilizados, vide seção 5.3.3

da camada de repositórios. Nesta tarefa utilizou-se o conhecimento adquirido na

fase de análise do domínio, quando se estruturou a ontologia do negócio. Assim,

criou-se os repositórios do Organizational Baseline, Usuários (Users) e Ontologia

(Ontology), preenchendo-se o primeiro com dados da Multicom, o segundo com

dados dos consultores e dos funcionários da Multicom, e o terceiro com dados da

ontologia empresarial. Todos esses repositórios, implementados em tabelas do

MS-Access, são explicadas nas seções seguintes. Adicionalmente criou-se, em

tempo de execução, o repositório do arquivo LOG (Upgrading Organizational

Baseline), onde armazena-se as transações que motivaram atualizações no

Organizational Baseline.

6.2.1 Descrição do Protótipo: O Serviço de Busca

Na Figura 6.1, apresenta-se a estratégia do processo de busca para uma das

questões anteriormente citadas: Que tipo de estrutura a Multicom possui?

Percebe-se que o consultor (usuário) necessita dar como entrada a palavra chave

“estrutura” que está sublinhada. Logo, o SCM, por meio do componente Busca,

procura no repositório de dados da memória corporativa, o Organizational

Baseline, as informações mais relevantes, as quais são extraídas e em seguida

entregues ao usuário.


O processo todo se dá da seguinte forma: primeiro, o agente de busca acessa

o repositório da ontologia do negócio (não mostrado na Figura 6.1), o qual fornece

o ponteiro ou ponteiros (output vector), em seguida esse(s) ponteiro(s) é (são)

utilizado(s) para ler o baseline organizacional, de onde se extrai a informação

solicitada pelo consultor. No exemplo, o conceito Estrutura Organizacional da

entidade Companhia do Organizational Baseline satisfaz a questão colocada.

Ressalta-se que na etapa da modelagem do domínio existiu a preocupação 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 negócio. Este

possui os seguintes atributos:

• ConceitoNome: Nome do conceito.

• ConceitoDescrição: Descrição do conceito.

• ConceitoNivel: Os níveis do conceito podem ser “1” Entidade , “2”

Atributo, “3” Faceta e “4” Intermediário. O nível intermediário significa

que o conceito pertence à hierarquia mas não é uma entidade, atributo ou

faceta. O nível intermediário é um conceito que contém outro conceito

intermediário ou uma entidade.

• ConceitoSinonimo: Reúne os ponteiros a todos aqueles conceitos que são

sinônimos do conceito principal.

• ConceitoTipo: Pode ser “1” Principal, quando o conceito faz parte da

hierarquia de conceitos; “2” Sinônimo, quando é um termo com o

mesmo significado que algum conceito da hierarquia, em particular pode

ser um nome de tabela ou de atributo.


• ConceitoUsuarios: Contêm os ponteiros a todos aqueles usuários para os

quais o conceito é relevante para apoio na sua tomada de decisões.

Figura 6.2 Estrutura do repositório Ontologia do negócio

Figura 6.3 Instâncias da Ontologia do negócio

A Figura 6.3 mostra seis instâncias da ontologia, os conceitos Companhia, o

qual é do nível Entidade; Empresa, que é um sinônimo de Companhia e do nível

Intermediário; Missão e Visão, que são do nível Atributo e; os termos EmpMissao

e EmpVisao, que são tratados também como sinônimos. Observa-se que o

conceito Companhia tem todos os campos preenchidos, pois trata-se do tipo

Principal; o conceito Empresa, que é um sinônimo, tem somente os campos

ConceitoCodigo, ConceitoNome, ConceitoNivel, ConceitoTipo e

ConceitoPrincipal preenchidos. Os conceitos Missão e Visão são casos similares

ao conceito Companhia, exceto que são do nível Atributo. Nota-se que os

conceitos que são sinônimos por definição não têm 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


os seus campos de dados preenchidos. É do conceito principal de onde, quando

requerido, são extraídas as informações (conceitos relacionados, usuários, tipo, e-

mail) a serem utilizadas nos processos de busca e de disseminação.

Figura 6.4 O serviço de Busca

A Figura 6.4 mostra a tela principal do componente agente Busca do

protótipo, vide detalhes na seção 5.5.5. Na parte superior o usuário entra com o(s)

termo(s) a ser(em) procurado(s) no Organizational Baseline. Nota-se que o

usuário têm duas opções de busca: Pesquisar no Baseline Organizacional e

Pesquisar na Base de Casos, o protótipo implementa a primeira opção. Na parte

inferior apresenta-se os resultados decorrentes dessa extração. No exemplo

apresentado, o usuário entra com o termo “estru” e obtém-se como resultado o

Conceito Principal Estrutura Organizacional e o Conceito Relacionado Forma de


Governo. Abaixo de cada conceito mostra-se o conteúdo destes. Dessa forma foi

mostrado o serviço de busca. Este serviço também é denominado de disseminação

requerida, porque o mesmo é realizado por solicitação do usuário, no exemplo, um

consultor de negócios.

Internamente, o processo de procura no componente de busca é como segue

primeiro, vide Figura 5.31, o servlet do agente recupera o formulário de busca do

servidor, utilizando a operação retriveFormSearch(). O protótipo não implementa

na presente versão as operações retrieveTreeOntology(), showLinks(), sendo

assim, mostra de forma direta os conceitos encontrados no repositório principal

da base de conhecimento. O serviço de busca em si é realizada pela operação

searchConcept(), a qual primeiro acessa o repositório da ontologia do negócio,

operações 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, operação

retrieveMetadadosSource(). Esses metadados são, logo, utilizados na recuperação

do conhecimento do baseline organizacional.

Como dito na seção 5.5.5, existem inúmeras heurísticas para casamento de

termos, como por exemplo o uso de critérios de similaridade e de sinônimos. No

protótipo implementou-se uma versão da estratégia de similaridade, a qual tem

como entrada uma cadeia de caracteres. Após a sua entrada o sistema procura que

conceitos tem essa cadeia como parte do nome do conceito na ontologia. Também

utilizou-se a estratégia de sinônimos, onde cada conceito da ontologia possui um

conjunto de conceitos sinônimos os quais apontam a um conceito principal, e este

por sua vez, aponta a um conjunto de termos relacionados. Destaca-se que, dada a

difusão da internet, a área de recuperação de conhecimento é na atualidade uma

linha de ampla pesquisa. Futuras versões do protótipo devem implementar outras

heurísticas.

6.2.2 Descrição do Protótipo: O Serviço de Disseminação

Outra das funcionalidades do SCM é o serviço de Disseminação automática.

Ressalta-se que o processo de disseminação exige que previamente se realize o

processo de armazenamento e de atualização do Organizational Baseline. As


fontes de dados do Organizational Baseline, como dito na seção 5.3.1, podem ser

das mais diferentes classes e tipos, incluídas as informações provenientes de sites

da web e o conhecimento de posse pelos membros da organização. No entanto,

salienta-se que o propósito do protótipo não é mostrar as diversas formas de como

o baseline é preenchido ou atualizado, e sim o processo de disseminação em si.

Acredita-se que para atingir esse objetivo é adequado o uso de formulários que

capturem informações e conhecimentos. Os formulários são uma forma simples de

entrada de dados, assim, estes foram utilizados para atualizar o repositório do

baseline organizacional. No protótipo os formulários foram instanciados a partir

do componente Interface, vide na seção 5.5.2 a Figura 5.28. Deste componente

foram implementados as operações retrieveForGUI(), readEntity(), writeEntity(),

updateEntity() entre outras.

Figura 6.5 Formulário da Entidade Companhia (Interface)


A Figura 6.5 apresenta o formulário 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,

descrição, matriz, estrutura organizacional, estilo de liderança, entre outros.

Percebe-se que os conceitos (atributos) Estrutura Organizacional e Estilo de

Liderança, mostram, também, 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 Descrição,

onde se descreve a evolução do seu conteúdo no tempo. Outros conceitos que

fazem parte da conceito Companhia não são mostrados na figura por limitações de

espaço. Após preencher os dados do formulário, o usuário encaminha os mesmos

ao servidor de aplicações, através do servlet do componente agente Interface,

atualizando, assim, o repositório do Organizational Baseline. O servidor logo

retorna ao usuário uma tela com a mensagem “Dados Incluídos com Sucesso” ,

vide Figura 6.6.

Figura 6.6 Tela de Confirmação dos Dados Ingressados

Como decorrência da atualização do baseline do SCM criou-se, em forma

paralela, um registro no repositório LOG do sistema, o qual armazena as

mudanças que ocorreram no Organizational Baseline. A criação destes registros é

realizada pelo componente agente de Armazenamento e Disseminação atendendo

a solicitação do componente Interface. Vide detalhes nas seções 5.5.2 e 5.5.6. A

Figura 6.7 apresenta os diferentes atributos do arquivo LOG, os quais são:

LogCodigo (Código do Log), LogMudanca (cadeia de caracteres que contêm as


mudanças 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 Missão e Visão do conceito Companhia. Essa modificação reflete-se

como uma transação 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 disseminação exige a existência do repositório Usuário, onde

se armazena os diferentes usuários do SCM. O gerenciamento deste repositório é

realizado pelo componente agente Usuário, vide na seção 5.5.3 detalhes do

mesmo. O arquivo Usuário inclui campos com dados referentes ao tipo de

informações e conhecimentos relevantes ao usuário e o seu endereço eletrônico. A

Figura 6.9 apresenta a tabela deste repositório e todos os seus atributos:

UsuarioCodigo (código do usuário), UsuarioNome (nome do usuário),

UsuarioConceitos (cadeia de caracteres que contêm as entidades e atributos

relevantes a cada usuário), UsuarioCargo (cargo do usuário) e UsuarioEmail

(correio electrônico do usuário). O atributo UsuarioConceitos possui uma


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 instâncias de usuário, vide Figura 6.10, o

primeiro, “Sergio Cortes” com o cargo de “Consultor” e correio eletrônico

“[email protected]” ; o segundo, “Fausto Maranhao” com o cargo de

“Gerente de TI” (Gerente de Tecnologias da Informação) e correio eletrônico

“ [email protected]” .

Figura 6.9 Estrutura da Tabela Usuário

Figura 6.10 Instâncias de Usuário

Definidos os registros dos repositórios LOG e Usuário, restaria apenas a

definição do arquivo Ontologia para realizar o processo de disseminação, mas este

já foi definido na seção 6.2.2 quando descrito o serviço de Busca no protótipo.

O passo seguinte é explicar o processo de disseminação em si. O

componente agente de Armazenamento e Disseminação, vide Figura 5.32, por

meio da operação listeningChange(), a qual está executando em background, irá

ler do arquivo LOG o(s) registro(s) log que reflete(m) as mudanças que

aconteceram no Organizational Baseline, operação processingMetadataLog(),

extraindo os conceitos que mudaram. Em seguida, busca-se se o conceito (termo)

existe na ontologia. Caso exista, extraí-se os usuários, operação getUser(), para os

quais a informação modificada é relevante. Após obter toda essa informação o


agente de Armazenamento e Disseminação prepara um e-mail e o envia a todos os

usuários antes selecionados, operação sendMessage(), comunicando-lhes a(s)

mudança(s) havida(s). Na Figura 6.11 mostra-se o e-mail recebido pelo usuário

consultor Sergio Cortes e na figura 6.12 o e-mail recebido pelo Gerente de TI

Fausto Maranhão. Dessa forma, tem-se mostrado todo o processo de disseminação

de informação e conhecimento, passo a passo.

Destaca-se, mais uma vez, que a apresentação do protótipo teve como

propósito mostrar que a proposta arquitetural do SCM é factível de ser

implementada. Ao mesmo tempo enfatiza-se que embora os dados utilizados

tenham sido extraídos de um estudo de caso acadêmico, os mesmos ajudaram a

mostrar a bondade da proposta do SCM.

Figura 6.11 e-Mail recebido pelo Consultor Sérgio Cortes

Figura 6.12 e-Mail recebido pelo Gerente de TI Fausto Maranhão

7 Conclusões, Contribuições e Trabalhos Futuros

Este capitulo apresenta as considerações finais sobre o trabalho, suas

principais contribuições e trabalhos que podem dar continuidade a esta pesquisa.

7.1 Conclusões

O fato de vivermos em uma sociedade denominada da informação e do

conhecimento, como resultado da revolução tecnológica e das comunicações,

exige uma cultura que motive o compartilhamento e a disseminação do

conhecimento. Ao mesmo tempo, o rápido fluxo das informações faz com que o

ambiente atual esteja caracterizado pela mudança contínua. Essa mudança

contínua é fator motivador para que as organizações evoluam rapidamente para

acompanhar essa evolução.

Essa problemática 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 funcionários para aprimorar a sua

tomada de decisões. Esse conhecimento é armazenado em repositórios de boas

práticas ou de lições aprendidas. No entanto, tais esforços têm estado orientados,

basicamente, ao conhecimento operacional e de processos.

No campo acadêmico, diversos autores, entre eles: Tsang (1997), Walsh &

Ungson (1999), Xu et al. (2003), ressaltam a importância de uma memória

organizacional como fonte de conhecimento e aprendizado (Simon, 1991).

Portanto, é crítico estabelecer repositórios de conhecimento que ajudem às

organizações a suportar sua tomada de decisões. Estes repositórios devem conter

tanto informações de natureza estratégica como conhecimentos organizacionais.

Reconhecido o fato do ambiente de turbulência na qual atuam as

organizações, tem-se alavancado a importância de capturar o know how como um

ativo organizacional para a obtenção de vantagem competitiva. O know-how,

também chamado de ativos do conhecimento, pode ser representado pelas lições


aprendidas (experiências passadas relevantes, aplicação de determinado

procedimento ou técnica), modelos (de qualidade, distribuição de carga de

trabalho, custos, segmentação de mercado) ou documentos corporativos (planos

de marketing, produção e qualidade).

Na área de Engenharia de Software tem-se salientado a relevância das

questões organizacionais no projeto de sistemas de informação (Dobson & Strens,

1994). Nos últimos anos tem crescido a importância das abordagens sócio-

técnicas para a elicitação de requisitos de sistemas. Nesse sentido, as diversas

definições da Engenharia de Requisitos enfatizam a relevância do contexto

organizacional para a elicitação de requisitos (Sommerville, 1989; Davis, 1990,

Goguen, 1992; Leite, 1994), sendo em conseqüência de natureza crítica a criação

de um baseline organizacional.

Nota-se que tanto pela perspectiva de negócios como da Engenharia de

Requisitos, ressalta-se a importância da organização dispor de informações

estratégicas e de conhecimentos (know how) com o propósito de suportar uma

adequada tomada de decisões, disseminação de conhecimento e elicitação de

requisitos organizacionais. Assim, ter informação oportuna e de qualidade

constitui um problema atual nas organizações, que pode ser resolvido com

modelos e ferramentas que facilitem tanto sua aquisição e armazenamento bem

como na sua extração e disseminação.

A informação estratégica e o conhecimento é denominado na literatura

como ativos intangíveis e a sua gestão chamada de Gestão do Conhecimento. Uma

conceituação bastante aceita é que a gestão do conhecimento é o processo por

meio do qual as organizações geram valor a partir de seus ativos intelectuais e de

conhecimento. Assim, o conceito de gestão do conhecimento tem um sentido mais

amplo, pois envolve tanto aspectos gerenciais, os quais não foram tratados nesta

tese, e aspectos tecnologicos, como as ferramentas que ajudam a gestão do

conhecimento, como por exemplo, uma ferramenta de memória corporativa.

O trabalho de uma proposta de arquitetura de Memória Corporativa

Estratégica (SCM) baseada em um modelo de negócio é, portanto, um tema que se

encaixa dentro da área de Gestão do Conhecimento, sendo o seu objetivo não só o

armazenamento de informação, como também o auxilio à disseminação de

conhecimento na organização e uma fonte para a elicitação de requisitos

organizacionais. A proposta está ancorada em trabalhos passados (Fiorini, 1995;


Fiorini et al., 1996; Mamani-Macedo, 1999) e postula tanto um modelo conceitual

do negócio, bem como uma proposta de arquitetura do SCM, independente do

setor industrial.

O primeiro objetivo, antes de criar a arquitetura do SCM, foi ter

representações e modelos que encapsulem conceitos do domínio da estratégia de

negócios. Ressalta-se que uma memória organizacional corporativa inclui não

somente “construtos“ estratégicos, como também outros que vêm do nível tático e

operacional, porém, relevantes pela sua importância no domínio.

De acordo com a literatura estudada na área de memórias corporativas,

percebe-se, em geral, que tem-se prestado pouca atenção à utilização de modelos

de negócio, pois a ênfase está dada, principalmente, aos repositórios de

documentos e aos dados orientados aos processos. Na atualidade existem

propostas no meio acadêmico (Chiu, 2003; Fiorini et al., 1996), as quais embora

tenham utilizado conceitos de TQM e Reengenharia de Negócios têm “ ignorado”

a existência de abordagens mais específicas sobre como as organizações se

comportam e interagem. Outras propostas e ferramentas como KnowMore

(Abecker et al., 1998), Fábrica de Experiências (Basili & McGarry, 1997), AskMe

Enterprise (AskMe, 2001), Xpert Rule Knowledge Builder (Attar, 2003) e Quest

Map (Gdss, 2003) são bastante úteis, mas todas elas estão orientadas à leitura de

documentos ou à recuperação de dados operacionais, não possuindo um modelo

de negócio explícito como o proposto e projetado no presente trabalho do SCM, o

qual facilita as funções de aquisição, armazenamento, busca e disseminação

automática. Certamente a operacionalização de uma memória corporativa não é

uma tarefa trivial, pois conhecimento relevante tem que ser identificado,

modelado e armazenado.

Na presente pesquisa definiu-se como “ frame” de referência do domínio a

área de estratégia de negócios em ambiente com mudança contínua. Para a

representação do domínio, criação do modelo do negócio, utilizou-se a abordagem

ontológica, para o qual foi necessário selecionar um dos diversos métodos que

existem para a criação de ontologias (TOVE, Enterprise Methodology, Sensus,

Bernaras et al., Methontology). O método selecionado foi Methodology for

Building Ontologies de Uschold & King (1995), pela sua simplicidade e clareza.

No entanto, salienta-se que ainda não existe um método que possa se dizer que é

melhor que os outros, sendo um tema de pesquisa atual. Para representar a


ontologia de negócio se utilizaram tanto o RDF Schema como o modelo de

Entidade Relacionamento, porém, notou-se que ambos têm limitações para a

formulação de regras e a descrição de axiomas. Entretanto, como o presente

trabalho não trata com inferências, essas limitações não o afetaram seriamente.

Como entrada para a criação do modelo de negócio utilizou-se diversas

abordagens teóricas da ciência administrativa, as quais têm sido validadas através

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 à análise

de funções e processos, sob uma abordagem de qualidade total. De forma

ortogonal, com vista ao enriquecimento do modelo, aplicou-se as metáforas de

Morgan. Desta forma, o modelo de negócio reflete uma série de conceitos,

atributos e relacionamentos elicitados das mais diversas fontes.

Embora o modelo de negócio apresentado esteja orientado principalmente

aos dados, este leva em conta aspectos de qualidade e da melhoria de processos.

Atualmente o modelo de negócio está em um nível genérico. Apesar que este

enfatiza a integração de conceitos via uma abordagem ontológica, acredita-se que

um maior detalhamento é necessário, como por exemplo, na descrição dos

indicadores de “benchmarking” , os quais deverão ser baseados em um programa

de medição da qualidade. A integração de um programa de medição com o

aprendizado continuo poderia, por exemplo, ser executado usando a abordagem

proposta por Cantone et al. (2000). Outra importante característica do modelo é a

descrição das relações sociais. Isto é conseqüência da preocupação com os atores

organizacionais e as suas responsabilidades, destacando assim a importância dos

aspectos sociais no processo de tomada de decisões. Ressalta-se que o modelo

conceitual do negócio engloba uma complexa rede de aspectos organizacionais

modelados de maneira sistêmica e objetivando futuras mudanças na própria

organização. Portanto, o seu objetivo primário é representar o contexto

organizacional com o propósito de explicitar informações úteis e relevantes.

A criação de uma memória corporativa implicou, por definição, na

integração de dados das mais diferentes fontes (legados, web, bancos de dados

relacionais e de objetos, entre outros) e tipos de dados (textuais e multimídia). Isto


levou a busca de uma solução baseada em uma abordagem de integração

materializada, a qual reflete-se na criação do repositório de conhecimento, o

Organizational Baseline. O Organizational Baseline foi baseado no modelo de

negócio, e portanto inclui “construtos” relevantes ao nível estratégico. No entanto,

o mesmo também incorpora construtos táticos e operacionais que por sua

relevância foram incluídos, enfatizando-se, assim, a dimensão estratégica do

SCM.

Um outro repositório importante do SCM é a base de casos do know how,

onde se armazena experiências passadas de sucesso, bem como também aquelas

experiências de insucesso, porém relevantes. Estes tipos de experiências pelas

suas próprias características não foram armazenados no Organizational Baseline,

daí o motivo da criação de um repositório independente deste dentro da

arquitetura do SCM.

A proposta arquitetural apresentada define em detalhe os diferentes

componentes - agentes que são necessários para implementar o SCM, os quais

são: Controle e Comunicação, Interface, Usuário, Busca, Armazenamento e

Disseminação e, Armazenamento de Lições Aprendidas (Base de Casos). O SCM

facilita o acesso, compartilhamento, reuso e disseminação do conhecimento em

toda a organização, permitindo acrescentar tanto a sua competitividade como o

seu aprendizado. No entanto, como descrito anteriormente, todo o processo de

gestão do conhecimento necessita não só de facilitadores tecnológicos como

também facilitadores gerênciais, sendo estes últimos tão importantes quanto os

primeiros. O SCM é um facilitador tecnológico que visa operacionalizar esse

processo. Nesse sentido, é importante perceber que a execução de um processo de

gestão de conhecimento exige a implementação simultânea de ambos

facilitadores, a utilização de ferramentas e métodos de cunho tecnológico, como é

o caso do SCM. A execução de um programa de desenvolvimento organizacional

para motivar o enraizamento de uma filosofia orientada ao compartilhamento do

conhecimento entre os membros da organização, também se faz necessário.

As duas funcionalidades básicas do SCM são: o serviço de consulta

requerida (busca) e o serviço de disseminação automática. O SCM para fazer a

busca no repositório de conhecimento do Organizational Baseline utiliza

mapeamentos pré-estabelecidos, os quais permitem a recuperação de entidades

mais pertinentes dada uma consulta em particular. As palavras chave fornecidas


são comparadas com a estrutura ontológica como base para encontrar a entidade /

atributo mais adequado. No caso do repositório do Case Base, a busca se realiza

utilizando heurísticas de similaridade.

O processo de consulta no SCM se dá através de palavras chave que são

submetidas ao SCM pelos usuários (gerentes, consultores, engenheiros de

requisitos). O agente de Busca, utilizando a semântica contida na ontologia, faz a

busca no repositório (Organizational Baseline) e extrai as informações relevantes

contida nas entidades e nos seus atributos, para finalmente entregar esses

resultados aos usuários do SCM.

Os dados utilizados para validar o protótipo do SCM, foram extraídos 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

serviços de consultoria de marketing e relações públicas. Esta empresa estava

sofrendo uma crise organizacional e em vista disso os principais sócios decidiram

convocar a participação de uma empresa de consultoria de negócios, com o

objetivo de receber um diagnostico organizacional sobre seu estado atual e as

possíveis alternativas de solução. Este estudo de caso serviu para a exemplificação

das idéias apresentadas no presente trabalho e mostrou as vantagens e o

funcionamento do repositório principal do SCM, o Organizational Baseline, nos

casos dos serviços de busca e disseminação. Dessa forma validou-se tanto o

modelo do negócio e o Organizational Baseline quanto a arquitetura proposta do

SCM.

7.2 Contribuições

As principais contribuições deste trabalho são:

• Propor a criação de uma ontologia voltada para o negócio, baseada em

teorias, abordagens e visões da administração de negócios. A ontologia

permitiu, logo, a criação do modelo conceitual do negócio no qual

explicitou-se os conceitos e os seus relacionamentos. O modelo do

negócio por sua vez foi utilizado na estruturação do repositório principal

da memória corporativa, o Organizational Baseline;


• Propor o uso de ontologias para a extração de conhecimentos do

Organizational Baseline. Isto é factível porque a ontologia foi elicitada a

partir do marco teórico fornecido pela ciência administrativa. Esse marco

teórico constituído pelas diversas teorias, abordagens e visões já foi

validado na área de estratégia de negócios por inúmeras empresas de

consultoria;

• Propor uma arquitetura genérica para a implementação da memória

corporativa estratégica. Esta arquitetura, baseada nos estilos arquiteturais

de camadas e repositórios, define três camadas: fontes, serviços e

repositórios;

• Propor uma arquitetura de software para implementar a camada de

serviços. A camada de serviços foi desenvolvida sob uma abordagem de

agentes, dado que esta satisfaz melhor as características do SCM, as

quais são autonomia, interatividade e adaptatividade;

• Ter definido como funcionalidades básicas de uma memória corporativa

os serviços de busca e disseminação. Para a determinação destes serviços

utilizou-se tanto a Metodologia MESSAGE como a análise dos

requisitos não funcionais;

• Apoiar a operacionalização de um sistema de gestão de conhecimento

fornecendo uma arquitetura de ferramenta de memória corporativa que

implemente as funcionalidades requeridas por esta, tais como aquisição,

armazenamento, compartilhamento e disseminação;

• Ter desenvolvido um protótipo do SCM com o intuito de monstrar o uso

dos conceitos da ontologia do negócio. Os dados para preencher os

repositórios do Organizational Baseline foram extraídos de um estudo de

caso relatado em Morgan (1996).

7.3 Trabalhos Futuros

A partir da arquitetura proposta e do protótipo implementado neste trabalho

podem ser especificados e desenvolvidos novas instâncias do SCM. É importante

ressaltar que o protótipo apresentado, embora desenvolvido parcialmente, serviu

para demonstrar conceitos da memória corporativa, no entanto, é necessário o

desenvolvimento dos outros componentes. Espera-se no futuro poder realizar


novos estudos de casos, com dados reais provenientes de organizações 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 propõe-se alguns trabalhos específicos que podem ser pesquisados

e desenvolvidos:

• Desenvolvimento dos componentes Controle e Comunicação,

Armazenamento no baseline, Armazenamento de Lições Aprendidas na

base de casos. O desenvolvimento e detalhe desses componentes deve

permitir realizar ajustes à arquitetura, a luz desses novos resultados;

• Especificação e Desenvolvimento do componente Regras de

Inferência, o qual não foi tratado no presente trabalho e é um tema em

aberto para a realização de pesquisas;

• Desenvolvimento e (re) uso do componente agente de

Descobrimento, o qual é um wrapper (mediador) que permite a extração

de informação de uma determinada fonte de dados. Pode se desenvolver

um conjunto de wrappers para diferentes tipos de fontes, bem como

pesquisar a existência de outros já existentes e disponíveis na internet

para seu re-uso;

A proposta do SCM propõe, também, a utilização de uma base de casos, a

semelhança de outras propostas de memórias corporativas, utilizando-se para a

recuperação de experiências a abordagem do raciocínio baseado em casos, como

por exemplo buscas por similaridade. Trabalhos futuros nesta direção da

recuperação de experiências é estudar e propor novas heurísticas de similaridade

bem como o uso dos conceitos da ontologia do negócio. Vale ressaltar que a

gestão do conhecimento até agora estava orientada a uma ênfase na gestão de

documentos. Acredita-se que o uso de ontologias para a recuperação de

experiências é uma forma adequada para a extração de conhecimento.

8 Referências Bibliográficas

ABECKER, A.; BERNARDI, A.; HINKELMANN, K.; KÜHN, 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. Disponível em URL: <http://www.askmecorp.com>. Acesso em: 03 maio 2003.

ATTAR Disponível 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 Estratégico e Implementación de una empresa del ramo Electro-técnico. Dissertação de Mestrado em Administração. Escuela de Administración de Negócios para Graduados, ESAN. Lima, Perú. Abril 1989. (Em Castelhano).

BARBOSA, A. C. P. Middleware para Integração de Dados Heterogêneos Baseado em Composição de Frameworks. PhD. Tese. Departamento de Informática, PUC-Rio, 2001.

BASILI, V.; MCGARRY, F. The Experience Factory: How to Build and Run One, Proceedings 19th Int’l 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 ECAI’96. 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 ICSE’98 – 20th Int’l Conference on Software Engineering. IEEE-ACM. Kyoto, April 1998.


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. O’Reilly & 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 165-175. 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 Goal-Driven 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 organizações 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 – PloP’99, USA, August 1999.

EURESCOM. A Specification of a Framework for Agent Oriented Workflow Management Systems. February 2001. Disponível em URL: <http://www.eurescom.de/public/projectresults/P800-series/815d1.htm> Acesso em: 10 março 2003. 2001a.

EURESCOM. MESSAGE: Methodology for Engineering Systems of Software Agents – Deliverable 1. September 2001. Project P907-GI. Disponível em URL: http://www.eurescom.de/~pub-deliverables/P900-series/P907/TI2/p907ti2.pdf Acceso em: 10 março 2003. 2001b.

FERNANDEZ-BREIS, J.T., CASTELLANOS, D., VALENCIA-GARCIA, R., VIVANCOS-VICENTE, P.J., MARTINEZ-BEJAR, R., DE LAS HERAS-GONZALEZ, M. Towards Scott domains-based topological ontology models. An


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-BÉJAR, 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. Disponível em URL: <http://www-sop.inria.fr/acacia/WORKSHOPS/ECAI2002-OM/Actes/Fernandez.pdf>. Acesso em: 10 de julho 2003.

FERNÁNDEZ-LÓPEZ, M. Overview of methodologies for building ontologies. Proceedings IJCAI 99. Proceedings Workshop on Ontologies and Problem-Solving Methods: Lessons Learned and Future Trends. CEUR Publications, 1999 Disponível em <http://www.ontology.org/main/presentations/madrid/analysis.pdf> Acesso em: 10 março 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. Disponível em URL: <http://www.ksl.stanford.edu/software/ontolingua/project-papers.html>. Acesso em: 12 março 2003. FIORINI, S.T. Processos de Negócio e Hipertextos: Uma Proposta para Elicitação de Requisitos. Departamento de Informática, PUC-Rio, 1995. Dissertação 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 INTELLIGENT PHYSICAL AGENTS. http://www.fipa.org/ 08, julho, 2003.

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 Informação, Administração do Conhecimento e Tecnologia: chave do sucesso. Encarte especial da Revista Exame, no 669, Agosto – 1998.

GDSS. Disponível 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.

GÓMEZ-PÉREZ, A. Knowledge Sharing and Reuse. In the Handbook of AppliedExpert Systems. CRC Press. 1998.

GÓMEZ-PÉREZ, A. Tutorial on Ontological Engineering. Proceedings IJCAI’99. Sixteenth International Joint Conference on Artificial Intelligence 1999. Disponível em URL: <http://www.dsv.su.se/ijcai-99/>. Acesso em: 15 março 2003.

GRUBER, T. A translation Approach to portable ontology specifications. Knowledge Acquisition. Vol 5. 1993. 199-220.


GRÜNINGER, 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, Springer-Verlag, 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).


LIEBOWITZ, J. Building Organizational Intelligence: A Knowledge Management Primer. New York: CRC Press. 1999.

MAGALHÃES, F.C. Qualidade & Mudança: O Caso da IBM Brasil. Departamento de Engenharia Industrial, PUC-Rio, 1993. Dissertação de Mestrado.

MALHOTRA, Y. What is Knowledge Management? Online. Disponível 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 Não Funcionais aos Requisitos Baseados nas Ações Concretas. Dissertação de Mestrado. Departamento de Informática, PUC-Rio. 1999.

MAMANI-MACEDO, N.A.; LEITE, J.C.S. DO P. Criação de uma Memória Organizacional sob uma Abordagem de Ontologias. Ideas’2001, 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 Evaluación y Seleccion de un Sistema de Computo (Caso de una empresa de Productos Lacteos). Dissertação para optar o Título Profissional de Licenciado em Computação. Em castelhano.1992.

MARTINEZ-BEJAR, R. Knowledge modeling technologies: ontologies and ripple-down rules. Palestra dada em ICMC-USP São Carlos 14, 17 Novembro 2000. Professor da Universidad de Murcia, Espanha.

MERRIAN WEBSTER Dictionary. Online. Documento capturado em 12/10/2003. Disponível 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 Organização. Ed. Atlas, 1996.

MURRAY, Philip C. New language for new leverage: the terminology of knowledge management (KM). Documento capturado em 12/09/2003. Disponível 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.


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.

PROTÉGÉ. 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. Disponível 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):1–4, 1992.

SHOHAM, Y. Agent-Oriented Programming. Artificial Intelligence, 60: pp. 24-29, 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 relação entre Tecnologia da Informação & Gestão do Conhecimento e seu uso na gestão de empresas. Dissertação de Mestrado. Universidade Metodista de Piracicaba. Programa de pós-graduação em Engenharia de Produção. Acesso em: 10 de outubro de 2003. Disponível em URL: <http://www.sbgc.org.br/cgi/cgilua.exe/sys/start.htm?infoid=343&sid=30>

STONER, J.A.F. Administración. Mexico, Ed. Prentice-Hall, 1986.

STUDER, R.; BENJAMINS, V.R.; FENSEL, D. “Knowledge Engineering: Principles and Methods”. Data and Knowledge Engineering. 25 (1998) 161-197.

SVEIBY, K.E. A nova riqueza das organizações. 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.


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. Disponível em URL: <http://www.mccombs.utexas.edu/kman/answers.htm>

USCHOLD, M.; GRÜNINGER, 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 Workshop’96, 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). 183-292. 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 Agent-Oriented 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 Berlín 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.

Documents

Néstor Adolfo Mamani Macedo CRIANDO UMA ARQUITETURA DE …julio/teseNestor.pdf · CRIANDO UMA ARQUITETURA DE MEMÓRIA CORPORATIVA BASEADA EM UM MODELO DE NEGÓCIO Tese de Doutorado