Post on 08-Nov-2018
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
Néstor Adolfo Mamani Macedo
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.
Néstor Adolfo Mamani Macedo
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,
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 17
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 18
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 19
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 20
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,
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 21
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 22
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 23
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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 24
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)
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 25
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;
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 26
• 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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 27
“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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 29
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 30
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 32
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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 33
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:
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 34
(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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 35
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 36
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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 37
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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 38
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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 39
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 41
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 42
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 43
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 44
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 45
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 46
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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 47
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 48
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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 49
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;
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 50
• 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,
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 51
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 52
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 53
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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 54
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,
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 55
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 56
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),
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 57
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 58
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”
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 59
“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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 60
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 61
ú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;
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 62
• 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 ontolingua@hpp.stanford.edu 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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 63
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 64
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 65
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;
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 66
• 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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 67
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)
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 68
• 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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 69
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 70
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:
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 71
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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 72
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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 73
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 74
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 75
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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 76
4.7.5.1 O processo de Matchmaking
O processo de Matchmaking permite um agente, que possui um certo
objetivo, identificar outro agente que possa realizar este objetivo. Este processo
envolve 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?
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 77
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 78
4.8 Metodologia MESSAGE
MESSAGE (Methodology for Engineering Systems of Software Agents)
(Eurescom, 2001b) é uma metodologia de Engenharia de Software orientada a
agentes. Esta combina as melhores 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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 79
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:
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 80
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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 81
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 82
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}
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 83
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;
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 85
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 86
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 87
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 88
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 89
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
Ambiente Organizacional
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 90
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-
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 91
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 92
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
Forças Competitivas
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 93
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 94
��������� � � �� ����� ����� ����� � ��� � !�!�"�!��#���$��%&�'�(���)���$�*�+��� ,&�$ !�-�!� .$�/)�$%�,�"� #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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 95
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 96
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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 97
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 98
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: subCl assOf r df : r esour ce=" &SCM; Pr ocessos" / >
</ 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: subCl assOf r df : r esour ce=" &SCM; Pr ocessos" / >
</ 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)
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 99
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
Forças Competitivas
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
Ambiente Organizacional
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 100
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;
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 101
• 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
Organizational Baseline
Case Base
LOG
Interface
Busca &
Descobrimento Descobrimento
Descobrimento
CAMADA MIDDLEWARE
HR DB
Logistic DB
Interface
MK DB
Temporal Metadata DataBase
Repositorios: Ontology,
HyperlinksHistory, Users
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 102
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 103
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 104
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 105
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 106
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
Organizational Baseline
CaseBase (Repository) Users Hyperlinks
History
Organizational Baseline Business
Ontology
SCM
Affected-by Affected-by
Affected-by Own Own Own
Temporal Metadata DB
Provide
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 107
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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 108
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)
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 109
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)
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 110
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 111
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 112
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 113
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 114
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 115
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 116
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..*
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 117
(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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 118
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 119
• 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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 120
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;
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 121
• 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;
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 122
• 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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 123
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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 124
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>
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 125
O primeiro elemento identifica o ato comunicativo que está sendo
comunicado, vide Tabela 5.7, definindo o significado principal da mensagem,
seguido por uma 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)
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 126
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 127
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 128
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 129
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 130
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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 131
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 132
(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
Domain Layer Resource
Layer Decision&
Management Layer Perception&
Communication Layer
Storing& Dissemination Agent
InterfaceAgent
UserAgent
• analysingEvent() • analysingMessage() • inform() • reject() • propose() • finish() • accept() • forward()
• makingDecision() • creation() • destruction() • monitoring() • captureEvent()
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 133
à 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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 134
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 135
dados como resultado da consulta (resultQuery), recuperar o estado atual do
arquivo fonte (retrieveStateSource), recuperar o estado da consulta
(retrieveStateQuery) - se foi um sucesso ou se houve alguma dificuldade -,
recuperar os metadados do arquivo fonte (retrieveMetadadosSource), abrir o
arquivo fonte (openSource), fechar o arquivo fonte (closeSource), ler os dados do
registro do arquivo fonte (readDataSFile) e, gravar os dados 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()
DML Manager Perception & Communication Manager
Domain Layer Resource
Layer Decision&
Management Layer Perception&
Communication Layer
Storing& Dissemination Agent
Discovering Agent
• analysingEvent() • analysingMessage() • inform() • reject() • propose() • finish() • accept() • forward()
• 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).
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 136
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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 137
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.
Agent beliefList goalList planList
setBelief() addBelief() setGoal() addGoal() setPlan() addPlan()
Navigation Search
Domain Manager
• searchConcept() • getConcept() • createTreeOntology()
Resource Manager • retrieveFormSearch() • retrieveTreeOntology() • retrieveMetadadosSource() • sendMessage() • receiveMessage() • showConcept() • showLinks() • readConcept() • openOB(), openOntology() • closeOB(), closeOntology() • writeDataOB()
DML Manager Perception & Communication Manager
Domain Layer Resource
Layer Decision&
Management Layer Perception&
Communication Layer
UserAgent
Search Agent
• analysingEvent() • analysingMessage() • inform() • reject() • propose() • finish() • accept() • forward()
• makingDecision() • creation() • destruction() • monitoring() • captureEvent()
Concept Search
Services
Figura 5.31 O Componente Agente de Busca
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 138
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:
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 139
(*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
Storing& Dissemination Agent
• 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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 140
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 141
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:
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 142
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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 143
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
Crédito 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),
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 144
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.
Agent beliefList goalList planList
setBelief() addBelief() setGoal() addGoal() setPlan() addPlan()
Domain Manager
• dataCheckingCase() • addCase() • modifyCase() • elimineCase() • getCase() • searchCase()
Resource Manager • retrieveFormCase() • showCase() • sendMessage() • receiveMessage() • readCase() • writeCase() • updateCase() • openCase() • closeCase()
DML Manager Perception & Communication Manager
Domain Layer Resource
Layer Decision&
Management Layer Perception&
Communication Layer
CaseBase Agent
• analysingEvent() • analysingMessage() • inform() • reject() • propose() • finish() • accept() • forward()
• makingDecision() • creation() • destruction() • monitoring() • captureEvent()
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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 146
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 147
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 148
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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 149
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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 150
• 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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 151
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 152
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 153
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)
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 154
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 155
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 156
estrutura similar ao atributo LogMudanca do arquivo LOG, pois usa os mesmos
delimitadores, “* ” para entidades e “?” para atributos.
No estudo de caso utilizou-se duas instâncias de usuário, vide Figura 6.10, o
primeiro, “Sergio Cortes” com o cargo de “Consultor” e correio eletrônico
“scortes@inf.puc-rio.br” ; o segundo, “Fausto Maranhao” com o cargo de
“Gerente de TI” (Gerente de Tecnologias da Informação) e correio eletrônico
“ fausto@inf.puc-rio.br” .
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 157
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 159
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;
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 160
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 161
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 162
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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 163
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;
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 164
• 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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 165
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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 167
CANTONE, G.; CANTONE, L.; DONZELLI, P. Organizing Software Technology Models, Measures and experiences for Conceptual Learning. Proceedings of the 2nd Workshop on Learning Organizations. Edited for Klaus-Dieter Althoff. Frauhofer, IESE, KL Germany. 2000.
CARROLL, D. Requirements Engineering Needs Total Systems Engineering. Requirements Engineering Volume 2, Number 4, 1997. Springer-Verlag.
CERAMI, E. Web Services Essentials. 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
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 168
application to a cancer domain. Proceedings of the International Conference on Formal Ontology in Information Systems - Volume 2001. ACM Press New York, NY, USA.
FERNANDEZ-BREIS, J. T.; MARTINEZ-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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 169
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).
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 170
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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 171
PORTER, M. E. Competitive Strategy. 1980. Free Press, A Division of Macmillan Publishing Co., NY, USA.
PORTER, M. E. Competitive Advantage.1985. Free Press, A Division of Macmillan Publishing Co., NY USA.
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.
Criando uma Arquitetura de Memória Corporativa baseada em um Modelo de Negócio 172
TEECE, D.J., PISANO, G., SHUEN, A. “Dynamic Capabilities and Strategic Management,” Strategic Management Journal 18: 509-534. 1997.
TSANG, E. Organizational Learning and the Learning Organization: A Dichotomy between Descriptive and Prescriptive Research. Human Relations, January 1997, v 50, n 1, p 73 (17).
TVERSKY, A. Features of similarity. Psychological Review 84, 1977: 327-352.
UNIVERSITY OF TEXAS AT AUSTIN, UT-Austin, Graduate School of Business. Knowledge Management Server. Knowledge Management Home Page. 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.