Download PDF
ads:
UNIVERSIDADE FEDERAL DE SANTA CATARINA
PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA
COMPUTAÇÃO
Lumar Valmor Bértoli Júnior
GUIA PARA AQUISIÇÃO DE SOFTWARE DE
GERENCIAMENTO ELETRÔNICO DE
DOCUMENTOS TÉCNICOS
Dissertação submetida à Universidade Federal de Santa Catarina como parte dos
requisitos para a obtenção do grau de Mestre em Ciência da Computação
Prof. Dr. Rogério Cid Bastos
Florianópolis, Dezembro de 2005
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
ii
GUIA PARA AQUISIÇÃO DE SOFTWARE DE
GERENCIAMENTO ELETRÔNICO DE DOCUMENTOS
TÉCNICOS
Lumar Valmor Bértoli Júnior
Esta Dissertação foi julgada adequada para a obtenção do título de Mestre em Ciência
da Computação Área de Concentração Sistemas de Conhecimento e aprovada em sua
forma final pelo Programa de Pós-Graduação em Ciência da Computação.
________________________________
Prof. Dr. Raul Sidnei Wazlawick
Banca Examinadora
________________________________
Prof. Dr. Rogério Cid Bastos
________________________________
Prof. Dr. Jovelino Falqueto
________________________________
Prof. Dra. Anita Maria da Rocha Fernandes
ads:
iii
Dedico este trabalho a minha esposa Andreza e a meus pais Lumar e Eunice.
iv
Agradecimentos
A minha esposa Andreza pelo apoio dado durante estes longos meses em que me
dediquei a esta dissertação. Seu carinho e compreensão foram fundamentais para o
sucesso do trabalho.
A meus pais, Lumar e Eunice, que sempre me incentivaram e me apoiaram em
todas as empreitadas de que participei. A educação que me deram e o exemplo de vida
foram a base para a construção de meu caráter.
A Deus, por ter escolhido para mim esta família maravilhosa e por ter me dado o
dom da vida até aqui.
Ao orientador, professor Rogério Cid Bastos, que acreditou em meu potencial e
aceitou continuar me orientando mesmo quando precisei ir morar em outro estado.
Ao meu gerente, Eloy Zeni Júnior, que foi parceiro nesta empreitada, permitindo
que em me ausentasse alguns dias para fazer este trabalho.
A Universidade Federal de Santa Catarina, pelo excelente ensino de qualidade.
A todos aqueles que de alguma forma contribuíram para este trabalho, seja
mandando artigos, seja me ensinando alguma coisa, seja mandando uma referência. A
todos estes segue minha gratidão.
As bibliotecárias da Petrobras Andréa e Maria Rosa pela ajuda em colocar esta
dissertação em formato apropriado.
v
SUMÁRIO
1. INTRODUÇÃO ........................................................................................................ 12
1.1 Considerações Iniciais........................................................................................... 12
1.2 Objetivos do Trabalho........................................................................................... 14
1.3 Escopo da Dissertação........................................................................................... 14
1.4 Justificativa Sobre a Escolha do Objetivo de Pesquisa......................................... 15
1.5 Beneficiários da Dissertação ................................................................................. 16
1.6 Estrutura do Trabalho............................................................................................ 17
2. GESTÃO DO CONHECIMENTO ......................................................................... 18
2.1 Gestão do Conhecimento ...................................................................................... 18
2.1.1 Conhecimento Tácito e Explícito ................................................................... 19
2.2 Dados Versus Informação Versus Conhecimento................................................. 20
2.3 A Relação Entre a Tecnologia da Informação e a GC .......................................... 22
2.4 Dificuldades a Serem Vencidas............................................................................. 24
2.5 Implantação da GC................................................................................................ 25
2.6 Ferramentas de Gestão do Conhecimento............................................................. 27
2.7 Benefícios da Gestão do Conhecimento................................................................ 30
3 GERÊNCIAMENTO ELETRÔNICO DE DOCUMENTOS - GED.................... 33
3.1 GED....................................................................................................................... 33
3.2 Implantação do GED............................................................................................. 35
3.3 Principais Tipos de Solução GED......................................................................... 37
3.3.1 Gerenciamento da Imagem dos Documentos ................................................. 38
3.3.2 Gerenciamento de Documentos Digitais ........................................................ 38
3.3.3 Disponibilização de Imagem .......................................................................... 38
3.3.4 Gerenciamento Corporativo de Relatórios ..................................................... 39
3.3.5 Processamento de Formulários ....................................................................... 39
3.3.6 Fluxo de Trabalho........................................................................................... 40
3.4 Dados que Justificam o Uso de Gerenciamento Eletrônico de Documentos ........ 40
3.5 Benefícios do GED................................................................................................ 42
4 GERENCIAMENTO ELETRÔNICO DE DOCUMENTOS TÉCNICOS (EDMS)
........................................................................................................................................ 44
4.1 EDMS.................................................................................................................... 44
4.2 Características que Tornam o EDMS Especial ..................................................... 45
4.2.1 Período de Existência do Documento............................................................. 46
4.2.2 Dimensões dos Documentos........................................................................... 47
4.2.3 Possibilidade de Alteração do Documento Enquanto Existir ......................... 47
4.2.4 Visualização Complexa de Documentos ........................................................ 47
4.2.5 Integração com Outros Sistemas de Engenharia............................................. 47
4.2.6 Alto Custo dos Documentos Armazenados no EDMS ................................... 48
5 AQUISIÇÃO DE SOFTWARE................................................................................ 49
5.1 Dificuldades Existentes Para Aquisição de Software ........................................... 49
5.2 Abordagens Consultadas....................................................................................... 51
5.2.1 CMMI – AM................................................................................................... 51
5.2.2 IEEE Práticas Recomendadas para Aquisição de Software............................ 54
vi
6 GUIA DE AQUISIÇÃO DE EDMS........................................................................ 56
6.1 Área de Processo de Gerenciamento de Projeto.................................................... 57
6.1.1 Planejamento de Projeto ................................................................................. 57
6.1.2 Monitoramento e Controle de Projeto ............................................................ 58
6.1.3 Monitoramento de Solicitação e Contrato ...................................................... 58
6.1.4 Gerenciamento de Projeto Integrado .............................................................. 59
6.1.5 Gerenciamento de Riscos................................................................................ 60
6.2 Área de Processo de Engenharia ........................................................................... 60
6.2.1 Desenvolvimento de Requisitos...................................................................... 61
6.2.2 Gerenciamento de Requisitos ......................................................................... 79
6.2.3 Verificação e Validação.................................................................................. 80
6.3 Área de Processo de Suporte................................................................................. 81
6.3.1 Análise de Decisão.......................................................................................... 81
6.3.2 Análise e Medição .......................................................................................... 82
6.3.3 Transição para Operação e Suporte ................................................................ 82
6.4 Práticas Genéricas ................................................................................................. 83
6.4.1 Prover recursos adequados para executar o processo, desenvolver os produtos
e prover os serviços do processo.............................................................................. 83
6.4.2 Atribuir responsabilidade e autoridade para executar o processo, desenvolver
o produto, e fornecer os serviços do processo. ........................................................ 83
6.4.3 Treinar as pessoas a executar ou suportar o processo quando necessário. ..... 83
6.4.4 Identificar e envolver os stakeholders relevantes como planejado................. 84
6.4.5 Guardar toda a documentação e os resultados................................................ 84
7. APLICAÇÃO E DISCUSSÃO ................................................................................ 85
7.1 Estudo de Caso...................................................................................................... 86
8. CONCLUSÕES E RECOMENDAÇÕES .............................................................. 89
8.1 Trabalhos Futuros.................................................................................................. 89
9. REFERÊNCIAS ....................................................................................................... 91
ANEXOS ....................................................................................................................... 96
vii
RESUMO
Softwares de Gerenciamento Eletrônico de Documentos Técnicos (EDMS) ajudam
organizações que trabalham com documentação técnica em suas atividades diárias.
Dado a complexidade deste tipo de software, adquiri-lo é uma tarefa não trivial que
exige certos cuidados. Este trabalho contextualiza o Gerenciamento Eletrônico de
Documentos em relação à gestão do conhecimento, faz um estudo sobre as
características de um software de EDMS e propõe um guia a ser usado por organizações
que queiram adquirir um software desta natureza.
A utilização deste guia pode trazer inúmeros benefícios com relação ao gerenciamento
desta aquisição, aos requisitos do software e ao suporte.
É apresentada uma discussão sobre uma aquisição de EDMS, feita em uma grande
organização, sem a utilização de nenhuma metodologia. São apresentados pontos que
deram errado nesta aquisição, mas que poderiam ter sido evitados caso este guia tivesse
sido utilizado.
Além disto, neste trabalho são levantados os principais softwares de EDMS no mercado
brasileiro e informações de seus fornecedores.
Palavras-chave: EDMS, aquisição de software, GED
viii
ABSTRACT
Engineering Document Management System (EDMS) softwares help organizations that
deal with technical documentation in their daily activities. Due its complexity, acquiring
it is a task that requires caution. This work relates Enterprise Content Management to
Knowledge Management, studies the features of a EDMS software and provides a guide
to be used by organizations that wish to acquire this sort of software.
The utilization of this guide can bring benefits about this acquisition management, the
software requirements and the support.
It’s showed a discussion about an EDMS acquisition, by in a major organization, with
no methodology. It shows some aspects that went wrong in this acquisition, but could
be avoid in case of this guide would be used.
Also, this work presents the main EDMS softwares in Brazilian market, as well as
information about their suppliers.
Key-words: Engineering Document Management System, Acquisition software,
Enterprise Content Management
ix
LISTA DE SIGLAS E ABREVIATURAS
CAD Computer Aided Design
EDMS Engineering Document Management System
CENADEM Centro Nacional de Desenvolvimento de Gerenciamento da Informação
GED Gerenciamento Eletrônico de Documentos
KM Knowledge Management
CRM Customer Relationship Management
ERP Enterprise Resource Planning
TI Tecnologia da Informação
GC Gestão do Conhecimento
CMMI-AM Capability Maturity Model Integration Acquisition Module
SA-CMM Software Acquisition Capability Maturity Model
FAA-ICMM Federal Aviation Administration’s Integrated Capability Maturity
Model
IEEE Institute of Electrical and Electronics Engineers
ISO International Standards Organization
x
LISTA DE FIGURAS
Figura 1. Conhecimento tácito e explícito. Fonte: SILVA (2002)................................. 20
Figura 2. Transformação de dado em informação e informação em conhecimento....... 21
Figura 3. Ferramentas mais utilizadas na disseminação do conhecimento. ................... 29
Figura 4. Módulos de Controle e Difusão das Informações e Conhecimentos pela
Empresa .......................................................................................................................... 29
Figura 5. Estrutura do CMMI-AM ................................................................................. 53
Figura 6. Controle de versões......................................................................................... 64
Figura 7. Comparação entre documentos. ...................................................................... 68
Figura 8. Permitir comentários e marcações .................................................................. 69
Figura 9. Pesquisa por diferentes critérios...................................................................... 69
Figura 10. Histórico de alterações.................................................................................. 70
Figura 11. Interface WEB de um EDMS........................................................................ 74
xi
LISTA DE TABELAS
Tabela 1. As 5 fases do modelo IEEE ............................................................................ 54
Tabela 2. Resumo do guia .............................................................................................. 56
Tabela 3. Resumo do que foi feito no desenvolvimento de requisitos........................... 61
Tabela 4. Características de um bom software de EDMS.............................................. 75
Tabela 5. Tabela de Requisitos Não-Funcionais de um software EDMS ...................... 79
Tabela 6. Erros que poderiam ter sido evitados se o guia tivesse sido usado ................ 88
Tabela 7. Lista de softwares de EDMS que estão no mercado brasileiro ...................... 98
Tabela 8. Contato dos fornecedores de EDMS............................................................. 101
1. INTRODUÇÃO
1.1 Considerações Iniciais
“A velocidade das mudanças que ocorrem no mundo desafia o homem a buscar
novos meios de conduzir uma organização, de modo a garantir seu crescimento e obter
vantagem competitiva no mercado” (PORTER, 1989, PORTER, 1990 apud
ROSSATTO, 2002 b).
A gestão do conhecimento (GC) nasceu com o objetivo inicial de minimizar os
danos causados pela saída de funcionários das organizações. Atualmente tem o objetivo
de criar, utilizar e disseminar o conhecimento dentro de uma organização (SILVA &
NEVES, 2003).
“Cada indivíduo que sair da empresa levará consigo conhecimentos que vale a
pena reter e cada novo funcionário trará conhecimentos que merecem ser
compartilhados” (STEWART, 1998 apud REZENDE, 2002).
A gestão do conhecimento ganha força a cada dia, pois o valor de mercado das
empresas está cada vez mais relacionado com os ativos intangíveis das empresas, ao
contrário de anos atrás em que a empresa era avaliada apenas por seu patrimônio físico.
Outro fator que leva a GC a ganhar força é que as atividades em marketing hoje são
baseadas essencialmente em conhecimento: sobre os clientes, sobre os produtos, sobre a
concorrência, etc. (TEIXEIRA FILHO, 2000)
Cada vez mais empresas buscam transformar seus dados em informações, suas
informações em conhecimento e utilizar este conhecimento para auxiliar em suas
tomadas de decisão.
A GC (gestão do conhecimento) é multidisciplinar. Há profissionais de
diferentes áreas pesquisando sobre o assunto, mas dando enfoques diferentes. Como
exemplo podem ser citados os profissionais de Recursos Humanos, de administração de
empresas, de Tecnologia da Informação e os de biblioteconomia.
13
Inicialmente foi dado foco apenas para as tecnologias que compunham a GC,
esquecendo-se das pessoas. Com o passar do tempo, foi dada mais importância para as
pessoas, pois percebeu-se que eram elas - as pessoas - que geravam o conhecimento e
que as tecnologias serviam apenas de meio para se chegar ao objetivo. Apesar disto, as
ferramentas de TI (Tecnologia da Informação) são agentes muito ativos no processo de
facilitação ao conhecimento.
“Itens de conhecimento que uma organização precisa gerenciar possuem
diferentes formas e conteúdo. Eles incluem manuais, correspondência com vendedores e
clientes, notícias, informações sobre os concorrentes e conhecimento derivado de
processos de trabalho (documentação, propostas, planos de projeto e análises finais) em
diferentes formatos (texto, figuras, áudio ou vídeo). A quantidade de informação e
conhecimento numa organização moderna que precisa ser capturada, armazenada e
compartilhada, e a distribuição geográfica de fornecedores e consumidores, e a evolução
dinâmica de informação torna o uso da tecnologia não uma opção, mas uma
necessidade.” (LINDVALL et al., 2003)
Cada vez mais as organizações dependem de softwares e computadores para
organizar suas informações. As informações que precisam ser gerenciadas crescem a
cada dia. Conforme dados disponíveis em (CENADEM, 2005): “A humanidade gerou a
mesma quantidade de informação nos últimos 50 anos que nos 5 mil anteriores. Esse
número duplicará nos próximos 26 meses. Em 2010, a informação duplicará a cada 11
horas.”
Com base nestes dados, observa-se que será cada vez mais difícil gerenciar as
informações sem o uso de ferramentas de apoio.
Há várias ferramentas de TI que ajudam na gestão do conhecimento e uma delas
é o GED (Gestão Eletrônica de Documentos) que corresponde a repositórios de
documentos que armazenam conhecimento explícito
1
. O GED agrega valor a estas
outras ferramentas de TI oferecendo o suporte documental que elas precisam. Há
diferentes tipos de sistemas de GED, e um destes tipos é o Gerenciamento Eletrônico de
Documentos Técnicos, também conhecido como EDMS (Engineering Document
Management System).
1
Há dois tipos de conhecimento, o tácito e o explícito. De maneira simplificada o conhecimento tácito é o
que está na mente das pessoas, enquanto o explícito é o que está escrito.
14
Muitas organizações governamentais possuem regras para aquisição de novos
bens patrimoniais e a partir de determinado valor é necessário abrir processo licitatório
para aquisição destes novos bens. Como o preço de softwares de EDMS é elevado,
quase sempre é necessário o uso da licitação. Mas, este processo exige que o software
seja bem especificado e que suas características estejam bem claras. Como é necessário
bastante conhecimento sobre EDMS e como é comum ocorrerem problemas no
processo de aquisição, a aquisição deste tipo de software é complexa.
1.2 Objetivos do Trabalho
O objetivo geral deste trabalho é elaborar um guia que oriente organizações que
desejem adquirir um software de EDMS. Dada a inexistência de um guia com este
propósito, o resultado deste trabalho servirá de auxílio para as organizações que
precisarem adquirir um software deste tipo.
São objetivos específicos:
a) Descrever as características de um EDMS;
b) Discutir sobre como erros cometidos num processo real de aquisição de um EDMS
poderiam ter sido evitados.
1.3 Escopo da Dissertação
O guia resultante desta dissertação não apontará para o melhor software de
EDMS. Ele será um guia que auxiliará as organizações na escolha do software que irão
adquirir. A melhor escolha para a organização A pode ser diferente da melhor escolha
para a organização B.
O levantamento dos softwares de EDMS será feito apenas com softwares que
possuam versão em português e tenham fornecedor no Brasil. O guia servirá para
aquisição de qualquer software de EDMS, mas o levantamento terá estas limitações para
que seja viável a obtenção das informações.
Para se elaborar o guia serão levantados os requisitos do EDMS. Mas, só serão
levantados os requisitos que descrevam de maneira geral as funções que o sistema deve
15
executar e suas restrições. Não serão listados requisitos específicos. Como o objetivo é
criar um guia para aquisição de software, requisitos que descrevam o software de
maneira geral são mais apropriados. Se o objetivo fosse desenvolver um software de
EDMS, então seria necessário que todos os requisitos, até os mais específicos, fossem
levantados.
1.4 Justificativa Sobre a Escolha do Objetivo de Pesquisa
Este objetivo de pesquisa foi escolhido porque a aquisição de software é um
processo que resulta muitas vezes em problemas para as organizações, tanto privadas
quanto públicas. As empresas brasileiras geralmente não utilizam ferramentas, métodos
ou qualquer outra prática para auxílio nos processos de aquisição de software. (ALVES,
2002)
A aquisição de software não é uma tarefa fácil (GALLAGHER & SHRUM,
2004). Além disto, o EDMS possui várias particularidades e complexidades que tornam
sua aquisição uma tarefa bastante complicada. Por isso, realizar uma aquisição deste
tipo requer a observação de uma série de recomendações.
Segundo a empresa Gama
2
, que trabalha com implantação de softwares do tipo
EDMS desde 1995, 96% de seus clientes não utilizaram nenhuma metodologia para
aquisição dos softwares. Os outros 4% utilizaram partes de alguma metodologia para
gerenciar o processo de aquisição do software.
O resultado disso é que ocorrem muitos problemas que poderiam ser evitados
caso se utilizasse uma metodologia como as que serão citadas neste trabalho.
2 A empresa Gama (http://www.gama.inf.br) conta atualmente com 48 clientes e sua sede fica em São
Leopoldo, no Rio Grande do Sul.
16
Para muitas organizações é necessário que se faça licitação
3
para aquisição de
produtos e como um software EDMS de maneira geral é caro, é comum as organizações
precisarem abrir processo de licitação para aquisição deste tipo de software. Para se
escrever um documento de licitação de um software desta natureza é necessário detalhar
todas as características que o cliente precisa que sejam atendidas e para isto são
necessários conhecimentos diversificados como conhecimentos de informática, de
documentação técnica, e de Engenharia de Software. “Para obter um processo de
aquisição de software bem sucedido, é necessário conhecer o objeto a ser adquirido e a
forma de aquisição, ou seja, o QUE e COMO será adquirido.” (ALVES, 2002)
Dadas estas características, é necessário criar uma equipe multidisciplinar para
gerenciar esta aquisição.
Como as metodologias existentes para aquisição de software são genéricas, ou
seja, escritas para qualquer tipo de software; como elas não são muito utilizadas aqui no
Brasil; como não existe um guia que seja específico para aquisição de software do tipo
EDMS; e como para se adquirir softwares EDMS através de licitação é necessário
descrever detalhadamente suas características; então este guia irá ajudar estas
organizações que desejam adquirir um EDMS.
1.5 Beneficiários da Dissertação
As organizações privadas ou públicas que pretendem adquirir um software de
EDMS, seja através de compra direta ou processo de licitação, serão as maiores
beneficiadas. Esta dissertação também auxiliará os fabricantes e fornecedores de EDMS
que terão em mãos uma lista com os requisitos que um EDMS deve atender.
3
Licitação é o processo de contratação de uma empresa para a prestação de um serviço ou aquisição de
um produto. Esta contratação é feita por parte de um órgão público.
É realizada uma comparação das propostas das diferentes empresas participantes da licitação e a proposta
que atende aos requisitos exigidos e tem o melhor preço, ganha a licitação.
Para que haja uma licitação, é necessário que o órgão do governo escreva e publique um edital de
licitação. Neste documento o órgão vai especificar todos os requisitos necessários do produto ou serviço.
Um edital de licitação de um software de grande porte requer da equipe que o escreve conhecimento
aprofundado sobre o assunto, senão o produto vencedor pode não ser a melhor opção para o órgão, ou
pode não atender a todas as suas necessidades.
17
1.6 Estrutura do Trabalho
Nos capítulos dois e três há uma revisão da literatura sobre gestão do
conhecimento (GC) e Gerenciamento Eletrônico de Documentos (GED), relacionando
estes temas.
No capítulo quatro é feita uma revisão da literatura sobre EDMS, relacionando o
EDMS ao GED e apresentando as principais características dos softwares desta
natureza.
No capítulo cinco são descritos os principais modelos de aquisição de software,
entre eles o CMMI-AM, SA-CMM, FAA-iCMM e o IEEE.
No capítulo seis é apresentado um guia para aquisição de software EDMS,
enfatizando os requisitos de alto nível deste tipo de software.
No capítulo sete é discutida a aplicação desta dissertação e o que foi estudado.
Para finalizar, no capítulo oito são escritas as conclusões sobre a dissertação
relacionando com os objetivos propostos no início do trabalho.
18
2. GESTÃO DO CONHECIMENTO
2.1 Gestão do Conhecimento
TEIXEIRA FILHO, (2000) define a GC como “uma coleção de processos que
governa a criação, a disseminação e utilização do conhecimento para atingir plenamente
os objetivos da organização”.
Outra definição de GC pode ser encontrada em CENADEM: “Knowledge
Management, KM, ou Gerenciamento do Conhecimento, como vem sendo utilizado no
Brasil, é o processo de obter, gerenciar e compartilhar a experiência e especialização
dos funcionários. O objetivo é ter acesso a melhor informação no tempo certo,
utilizando-se tecnologias de forma corporativa.”
Para SILVA & NEVES (2003), gestão do conhecimento significa rever e
organizar as principais políticas, processos e ferramentas de gestão e tecnológicas à luz
de uma melhor compreensão dos processos de geração, identificação, validação,
disseminação, partilha e uso dos conhecimentos estratégicos para gerar resultados para a
empresa e benefícios para os colaboradores.
Ainda que de forma não explícita, as pessoas têm usado o conhecimento nas
organizações há muito tempo. O conhecimento da empresa, da competição, dos
processos, do ramo de negócio, enfim, tem estado por trás de milhões de decisões
estratégicas e operacionais, ao longo dos anos. No entanto, o consenso de que o
conhecimento é um recurso que precisa ser gerenciado é relativamente recente.
(TEIXEIRA FILHO, 2000)
Somente de uns anos para cá é que as consultorias começaram a tentar vender esta
idéia para as grandes organizações. Mas, conforme veremos neste estudo, a GC está
sendo bastante estudada, difundida e implantada nas organizações e tem tudo para
crescer muito nos próximos anos.
Para KINGSTON (2004), muitos anos de experiência têm demonstrado que
sistemas baseados em conhecimento são um dos mais eficazes métodos de gerenciar
conhecimento nas organizações – se aplicados nas áreas e tarefas apropriadas. A
19
identificação de tarefas e áreas apropriadas é conseqüentemente crítica – e ainda pouco
tem sido publicado sobre este assunto, a despeito de renovado interesse na área por
profissionais de gestão do conhecimento. Como há muito interesse por profissionais
qualificados nesta área, supõe-se que brevemente teremos mais cursos sendo oferecidos
e o conhecimento a respeito desta área se multiplicará.
Para BECK (2003) apud CÂNDIDO & ARAÚJO (2003), atualmente, toda
empresa está envolta com amplos e diversos tipos de informações, e, para competir
neste ambiente altamente dinâmico, o segredo do sucesso é a agregação de valor a partir
do acesso, do tratamento, da utilização e da disseminação da informação.
As pessoas convivem com uma quantidade enorme de informação nas
organizações e a tendência é esta quantidade aumentar cada vez mais. São informações
sobre parceiros, concorrentes, processos, produtos, entre outras e que se forem
gerenciadas, trarão ganhos reais à organização.
O conhecimento é transmitido por pessoas e para pessoas, através de meios
estruturados como vídeos, livros, documentos, páginas da WEB, etc. Além disso, as
pessoas obtêm conhecimento daqueles que já o têm, pelo aprendizado interpessoal e o
compartilhamento de experiências e idéias. (TEIXEIRA FILHO, 2000)
2.1.1 Conhecimento Tácito e Explícito
Há dois formatos de conhecimento, o tácito e o explícito. O conhecimento tácito
é aquele que as pessoas possuem, mas não está descrito em nenhum lugar, residindo
apenas em suas cabeças. O conhecimento explícito é aquele que está registrado de
alguma forma, e assim disponível para as demais pessoas, conforme ilustrado na Figura
1. Muito do que é feito então em gestão do conhecimento tem por base essas sucessivas
passagens de conhecimento tácito para explícito, e vice-versa. (TEIXEIRA FILHO,
2000)
20
Figura 1. Conhecimento tácito e explícito.
Fonte: SILVA (2002)
Para SILVA (2004) há quatro tipos de conversões do conhecimento:
socialização (tácito de um indivíduo para outro), externalização (explicitando partes do
conhecimento tácito), combinação (conhecimento explícito de um indivíduo para o
grupo) e internalização (captando no formato tácito o conhecimento explícito do grupo).
Uma efetiva criação e trabalho com o conhecimento apenas ocorre em um ambiente em
que existe uma contínua conversão entre estes dois tipos de conhecimento.
Em termos de gestão do conhecimento, os documentos produzidos pelas
organizações representam seu conhecimento explícito. (LINDVALL et al., 2003)
2.2 Dados Versus Informação Versus Conhecimento
Há muita confusão relacionada a dados, informação e conhecimento.
ROSINI & PALMISANO (2003) de maneira clara definem bem dado e
informação:
“É conveniente que façamos a distinção entre informação e dados. Dados são as
representações originais e detalhadas de eventos do mundo físico. Para que os dados se
tornem úteis na tomada de decisão eles precisam ser tratados, isto é, transformados em
informações. Informações são, portanto, dados trabalhados de modo que sejam úteis. O
administrador, o gerente, o empresário usam informações, e não dados.”
21
Já SILVA & NEVES (2003), esclarecem a relação entre os três termos: “O
conhecimento deriva da informação da mesma forma que a informação deriva dos
dados, para que a informação se transforme em conhecimento é necessário trabalho
humano.”
DAVENPORT & PRUSAK (1998) apud SILVA & NEVES (2003) acrescentam
que “Conhecimento não são dados nem informação, embora esteja relacionado com
ambos, e as diferenças entre estes termos seja muitas vezes uma questão de grau.”
Para transformar dados em informações é necessária a utilização de ferramentas.
Mas para transformar informação em conhecimento é necessário tempo. Conhecimento
não é nem dado nem informação, mas está relacionado a ambos. (TEIXEIRA FILHO,
2000)
Para PAIVA JUNIOR (2003), conhecimento surge com a aplicação da
informação. Informação esta que foi gerada pelo processamento de uma massa de
dados. A Figura 2 ilustra seu pensamento.
Figura 2. Transformação de dado em informação e informação em conhecimento
Fonte: PAIVA JUNIOR (2003)
Gerenciar os dados e as informações é um processo menos trabalhoso que
gerenciar o conhecimento, já que é possível gerenciá-los apenas com o uso de
ferramentas tecnológicas. Já o conhecimento é mais complicado, pois envolve também
pessoas. O parágrafo a seguir embasa este pensamento.
Enquanto dados são encontrados em registros ou transações e informação em
mensagens, o conhecimento é obtido de indivíduos ou grupos detentores de
conhecimento, ou, por vezes, em rotinas das organizações. (DAVENPORT &
PRUSAK, 1998 apud SILVA & NEVES, 2003)
22
2.3 A Relação Entre a Tecnologia da Informação e a GC
Para entender o porquê do estudo de GC nesta dissertação sobre EDMS, é
necessário entender a relação entre a TI e a GC. A tecnologia é a base para a GC e
oferece as ferramentas necessárias para viabilizar a GC. Uma destas ferramentas é o
Gerenciamento Eletrônico de documentos.
O GED apóia a Gestão de Conhecimento das organizações através da
organização e disponibilização do conhecimento armazenado em documentos.
(SANTIAGO, 2004)
Gestão do conhecimento é muito mais do que tecnologia. Entretanto, não se
pode negar que as ferramentas digitais têm impulsionado o desenvolvimento da gestão
do conhecimento à medida que otimizam ou habilitam processos ligados à conversão do
conhecimento.
Segundo DAVENPORT & PRUSAK (1998) apud CICCONE (2002), a mais
valiosa função da tecnologia na gestão do conhecimento é estender o alcance e
aumentar a velocidade de transferência do conhecimento.
Assim como vem ocorrendo nos demais âmbitos gestores das empresas, a
Tecnologia da Informação também tem papel relevante na preservação e administração
do capital intelectual da empresa, principalmente visando a alavancar os processos de
inovação. (RESENDE, 2002) A Tecnologia da Informação está fortemente ligada às
iniciativas de gestão nas organizações.
Uma bem-sucedida sistematização da gestão do conhecimento deve considerar
que o conhecimento pode existir em dois formatos, tanto na mente das pessoas, quanto
em registros diversos; e a Tecnologia da Informação tem grande importância no acesso
e na renovação dos conhecimentos. Seguindo essas preocupações, a essência da idéia de
“criação do conhecimento” utilizada na área de gestão organizacional reside em pessoas
poderem se encontrar e trocar experiências com outras pessoas que têm ou trabalham
com certos tipos de conhecimentos, e a importância da Tecnologia da Informação é
construir um suporte para que isso ocorra. (SILVA, 2004)
23
Como se pode perceber, as pessoas são sempre o fator principal para a GC e
cabe a Tecnologia da Informação apenas a tarefa de disponibilizar facilidades para que
elas multipliquem o conhecimento e transformem-no em vantagem competitiva para a
organização onde trabalham. Será visto mais à frente quais são estas ferramentas de
Tecnologia da Informação que auxiliam à gestão do conhecimento.
Deve-se enfatizar que, embora a tecnologia conecte e integre todas as áreas de
negócio de uma empresa e a auxilie em seus processos de negócios, inclusive no de
gestão do conhecimento, ela não consegue substituir o cérebro humano em inteligência
e não consegue simular a capacidade humana no aprendizado com todos os sentidos.
Sendo assim, é um meio fundamental para auxiliar a força de trabalho, não substituindo
os colaboradores nem conseguindo resolver questões que envolvam conhecimentos
tácitos. A tecnologia sozinha não agrega valor aos negócios, pois as pessoas continuam
a fazer a diferença pelas competências que detêm e que não são passíveis de cópia pela
concorrência. (ROSSATTO, 2002a)
Para reforçar o que está sendo afirmado, seguem citações que estão alinhadas com
estas idéias:
a) “A tecnologia, sozinha, não garante o sucesso de nenhum projeto. Muito menos
em GC.”(TEIXEIRA FILHO, 2000)
b) “A tecnologia, por si só, gera pouco resultado estratégico – no máximo, torna
mais rápidos os processos tradicionais. Mas o que faz diferença realmente são as
pessoas.”(SILVA & NEVES, 2003)
c) “A tecnologia sozinha nunca será a solução para a gestão do conhecimento.”
(LINDVALL et al., 2003)
Para completar, o conhecimento deve fluir rápido e facilmente entre as diversas
funções da organização (RESENDE, 2002). E cabe à Tecnologia da Informação prover
meios para que isto se realize.
24
2.4 Dificuldades a Serem Vencidas
Há ainda algumas dificuldades a serem superadas pelos envolvidos com a GC,
conforme será visto a seguir.
Estudos indicam o fato de que nem todo o conhecimento pode ser tornado
explícito e gravado (LINDVALL et al., 2003). Isto dificulta as pretensões da GC já que
se o conhecimento não pode ser tornado explícito, haverá dificuldade para gerenciá-lo.
Outra dificuldade encontrada é que não há uma ferramenta de gestão do
conhecimento que englobe todos os requisitos da gestão do conhecimento. O que
existem são várias ferramentas especializadas em atender um ou mais requisitos. A
causa disto é que a gestão do conhecimento possui muitas necessidades diferentes e é
difícil concentrá-las toda numa única ferramenta de gestão do conhecimento.
(LINDVALL et al., 2003)
Levando-se em consideração a grande variedade de organizações entre os vários
setores da indústria, do comércio, da economia, do governo, da educação, entre outras, é
de se imaginar a complexidade de uma ferramenta que atenda a todas elas haja vista as
particularidades que cada uma tem. É de se esperar que esta ferramenta única demore
muito tempo para ser construída, isto se um dia for possível construí-la.
Nem todas as ferramentas que recebem o rótulo de ferramentas de gestão do
conhecimento são de fato ferramentas de gestão do conhecimento. Muitas vezes seus
vendedores as rotulam desta forma para tornar o produto mais atrativo e moderno.
(LINDVALL et al., 2003)
Por isso faz-se necessário conhecimento em GC antes de se escolher a
ferramenta que irá ser adquirida.
Outra questão é de que forma as empresas podem conciliar o conhecimento que
se encontra na cabeça dos seus funcionários com as informações existentes em suas
bases de dados, nos papéis, planilhas e relatórios por ela gerados, transformando-os em
ferramenta geradora de vantagem estratégica para o negócio. E também, como reter esse
conhecimento para que ele se torne propriedade da empresa, isto é, capital estrutural.
(RESENDE, 2002)
25
Este é o grande desafio da GC, encontrar meios de passar o conhecimento tácito
dos empregados para a organização, de forma que ela se torne a proprietária daquele
conhecimento.
A despeito do interesse e do esforço em implantar gestão do conhecimento por
parte de muitas companhias líderes em suas áreas de atuação, a gestão do conhecimento
ainda está em sua infância (REZGUI, 2001). Esta é uma limitação que tende a
desaparecer em breve devido o grande interesse nesta disciplina.
Uma das limitações das tentativas atuais de gerenciar a informação e
conhecimento relacionadas e levantadas em um projeto é que a intenção por trás das
decisões não é guardada ou documentada. Isto requer processamento complexo para
seguir o rastro e registro de milhares de mensagens, ligações telefônicas, memorandos, e
conversações que englobam muitas informações relacionadas ao projeto. (REZGUI,
2001)
Mas, estas dificuldades apresentadas aqui não inviabilizam a GC e
provavelmente serão resolvidas em breve, já que a quantidade de pesquisa na área vem
crescendo bastante.
2.5 Implantação da GC
Para implementar um sistema de gestão de conhecimento eficiente, as
organizações devem identificar seus principais problemas, atribuir prioridades, definir
uma estratégia, e então selecionar as ferramentas apropriadas. (LINDVALL et al., 2003)
É comum as organizações fazerem o oposto, ou seja, começar procurando pela
ferramenta. Isto ocorre também com o Gerenciamento Eletrônico de Documentos.
Equipes sem o conhecimento necessário para implantar a gestão do conhecimento são
formadas e ao invés de fazer um planejamento, já vão procurar representantes e
consultores. O problema é que estes representantes e consultores tentarão vender sua
solução, mesmo que ela não seja a mais adequada para aquela organização.
RESENDE (2002) afirma que para que seja efetiva, qualquer tecnologia de
administração do conhecimento escolhida deve servir a um objetivo estratégico claro.
Ainda sobre a escolha da tecnologia, CÂNDIDO & ARAÚJO (2003) acrescentam que é
26
preciso definir qual o tipo de tecnologias da informação e de gestão mais adequado para
a viabilização da gestão do conhecimento, sendo esta uma etapa preponderante e
imprescindível para o sucesso no processo de acesso, busca tratamento, utilização e
disseminação de informações nas organizações.
Outro fator importante a ser levado em conta é que por ser o conhecimento uma
criação humana, uma organização não consegue implantar o modelo de gestão do
conhecimento, se não considerar os indivíduos como os atores que encenam o papel
principal no cenário dos negócios dentro da nova realidade. (NONAKA & TAKEUCHI,
1997, SVEIBY, 1998 apud ROSSATTO, 2002 a )
As primeiras tentativas de implantação de modelos de gestão do conhecimento
não consideravam os indivíduos importantes e sim as tecnologias que compunham a
GC. Mas, aí se viu que eram elas que geravam o conhecimento e que as tecnologias
eram apenas meios de se chegar ao objetivo e então se começou a valorizar as pessoas.
O aprendizado e o compartilhamento de conhecimento podem ocorrer
espontaneamente. (Compartilhamento de conhecimento no café ou discussão de
problemas no intervalo de palestras). Compartilhamento é, entretanto, mais eficiente
quando é organizado; além disto, conhecimento deve ser capturado, armazenado e
organizado de acordo com o contexto de cada companhia de forma que seja tanto útil
quanto eficientemente disseminado. (LINDVALL et al., 2003)
Tudo isto deve ser levando em consideração numa implantação. De acordo com
o contexto da organização é que a equipe deverá criar estratégias para capturar,
armazenar e organizar o conhecimento.
Outro fator importante a ser levando em consideração na implantação é mapear
dinamicamente os processos de negócio da empresa, registrando o conhecimento sobre
a forma como esses processos são realizados, mantendo estas informações atualizadas e
tornando-as disponíveis para todos na organização. (TEIXEIRA FILHO, 2003)
TEIXEIRA FILHO (2003) ainda acrescenta que o conhecimento sobre os seus
processos é tão importante para uma empresa quanto as informações sobre a
concorrência, sobre os clientes ou sobre novas tecnologias.
Ao ser feito o mapeamento dos processos de negócio muitos questionamentos
surgem sobre a maneira como estes processos são executados atualmente. Devido a este
27
fato, os processos acabam sendo revisados, com grande chance de surgir uma nova
maneira mais eficiente de se realizar a mesma tarefa.
Em acordo com o parágrafo anterior, ROSSATTO (2002a) comenta que a
implantação de um modelo de gestão do conhecimento numa organização pode
identificar a necessidade de mudanças profundas no seu perfil, tornando-a mais atrativa
aos clientes e mais competitiva no mercado.
Implementar projetos de gestão do conhecimento é como implementar
importantes projetos de mudança organizacional. Necessita de esforço sistemático em
várias áreas: atuação da liderança, estratégias de comunicação, revisão de processos,
implantação de novas tecnologias, novas políticas de RH, novas medidas de resultados,
etc. Fica o alerta quanto ao aspecto necessariamente multidisciplinar e de gerenciamento
de mudança normalmente associado a iniciativas importantes de GC. (SILVA &
NEVES, 2003)
É necessário que todos na organização entendam a magnitude e a importância de
uma implantação desta natureza. Subestimar o tamanho da mudança pode ser um grave
fator negativo na implantação. Para que as pessoas entendam a importância e comprem
a idéia, uma campanha informativa pode ser realizada.
ROSSATTO (2002a) complementa e reforça o que foi escrito nestes dois
últimos parágrafos dizendo que a gestão do conhecimento é um processo estratégico
contínuo e dinâmico que visa gerir o capital intangível da empresa e todos os pontos
estratégicos a ele relacionados e estimular a conversão do conhecimento. Desse modo,
deve fazer parte da estratégia organizacional e ter sua implantação garantida e
patrocinada pela alta gerência, a quem deve estar subordinado todo o processo.
2.6 Ferramentas de Gestão do Conhecimento
Segundo ROSSATTO (2002a) e TEIXEIRA FILHO (2000), as seguintes
ferramentas auxiliam e contribuem para o processo de gestão do conhecimento:
a) Ferramentas de intranet, internet e extranet;
b) Correio eletrônico;
c) Suporte ao cliente, CRM;
28
d) Videoconferência;
e) Banco de dados;
f) Gestão empresarial, ERP;
g) Gerenciamento Eletrônico de Documentos (GED);
h) Controle de fluxo de trabalho (workflow);
i) Conversação entre pessoas (Groupware);
j) Construção de bases de dados inteligentes (Expert Systems);
k) Recuperação de dados inteligentes (Data WareHouse, Datamart e Business
Intelligence);
l) Análise de tendências (Balanced Scored Card);
m) Outras ferramentas que controlam e difundem informações e conhecimentos pela
empresa;
Além destas, CÂNDIDO & ARAÚJO (2003) ainda citam painéis eletrônicos,
CD-ROMs e Agentes de pesquisa inteligentes. SILVA & NEVES (2003) acrescentam
Mapas de Conhecimento à lista.
Essa família de ferramentas controla a vida das informações e dos
conhecimentos que circulam pela empresa e para fora dela, desde o chão de fábrica até a
alta administração (ROSSATTO, 2002).
Em HSM (2004) é apresentado um estudo comparativo que mostra as
ferramentas mais usadas na disseminação do conhecimento. O resultado do estudo pode
ser contemplado na Figura 3.
29
Figura 3. Ferramentas mais utilizadas na disseminação do conhecimento.
Fonte: HSM (2004)
Em ROSSATTO (2002c) a autora ilustra “os aplicativos que controlam as
informações e os conhecimentos que circulam pela empresa e para fora dela”, com a
Figura 4:
Figura 4. Módulos de Controle e Difusão das Informações e Conhecimentos pela Empresa
Fonte: ROSSATO, (2002c)
Business
Intelligence
CRM
GED
Banco de
Dados
ERP
Vídeo-
conferência
Portal
Workflow
30
2.7 Benefícios da Gestão do Conhecimento
“O interesse pelo conhecimento nas empresas começou com a constatação de
que o valor de mercado de diversas empresas (Lótus, Microsoft, Apple, Amazon.com,
Yahoo!, Nokia, Skandia, Nike, Benneton, América On Line, entre diversas outras) é
muito maior do que o valor do seu patrimônio físico. O valor total das ações dessas
empresas incorpora dados ‘intangíveis’ tais como: o valor das marcas, as patentes, a
capacidade de inovação, o talento dos funcionários, as suas relações com seus clientes,
entre outros fatores. As empresas se voltaram para a gestão do conhecimento no intuito
de entender, organizar, controlar e lucrar com esse valor intangível (o conhecimento).”
(TEIXEIRA FILHO, 2000)
RESENDE, (2002) cita que com o advento da civilização digital, o intangível
passa a compor a parte de maior valor de uma empresa.
Pode-se, portanto, dizer que a gestão do conhecimento é o processo de criar
valor pelo uso dos ativos intangíveis da empresa. É a transformação da informação em
conhecimento e do conhecimento em negócio. (RESENDE, 2002)
A gestão do conhecimento deve direcionar o uso do conhecimento para a criação
de inovações que gerem valor para os clientes e tragam vantagem competitiva para a
empresa. Enxergando sob esse ângulo, o conhecimento, apesar de ser um ativo
intangível, pode originar produtos e serviços tangíveis. (ROSSATTO, 2002)
Com a GC, a empresa começa a perceber a importância de transformar seu
conhecimento realmente em um ativo a serviço da organização, e não apenas em
propriedade de indivíduos ou grupos internos. (TEIXEIRA FILHO, 2000)
O conhecimento tem de pertencer à organização e não ao indivíduo, senão corre-
se o risco de perder o conhecimento com a saída do indivíduo.
Como exemplo disto há o caso real de Daniela B. que trabalhou durante seis
anos na Tecnologia da Informação (TI) da regional São Paulo Sul da Petrobras e quando
saiu da TI, o conhecimento que ela tinha se perdeu. Ela trabalhou na implantação do
conceito de Postos de Serviço em todas as localidades do Sul do Brasil e na implantação
de Normas ISO. Alguns conhecimentos sobre a implantação dos Postos de Serviço só
ela tinha e este conhecimento se perdeu pois a empresa não documentou tudo que foi
feito. Ela foi para a área de Serviços Compartilhados dentro da mesma empresa, devido
31
à mudança de contrato. O conhecimento dela ainda pode ser recuperado caso haja
necessidade, mas se ela tivesse saído da empresa, o conhecimento poderia ser perdido
para sempre.
Muitas empresas já perceberam que o conhecimento é o seu maior patrimônio,
mas ainda não o utilizam como deveriam. Muitas vezes, o conhecimento fica restrito ao
funcionário que o adquiriu e não o compartilhou na empresa.
Ainda com relação a este assunto, em CENADEM há esta citação: “O
aprendizado do dia-a-dia, decorrente da experiência de cada funcionário, precisa ser
colocado de forma corporativa e não mais ficar restrito somente à pessoa que aprendeu.”
O interesse das organizações no conhecimento se deve, entre outros aspectos, ao
fato de o conhecimento estar muito associado à ação. O conhecimento é avaliado pelas
decisões e ações que desencadeia. Um melhor conhecimento pode levar a melhores
decisões em marketing, vendas, produção, distribuição, e assim por diante (TEIXEIRA
FILHO, 2000). Por esta razão é que o tema gestão do conhecimento está sendo estudado
com tanta intensidade, pois um conjunto de mudanças que pode melhorar a tomada de
decisão em vários setores de uma organização, merece atenção.
Na mesma linha de raciocínio, SILVA & NEVES (2003) escrevem que o
conhecimento só tem valor se, de qualquer forma, for transformado em ação, permitindo
sua medição através de resultados, decisões corretas, eficiência de processos, qualidade
e inovação de produtos.
Numa empresa de serviços, cujo principal ativo seja o conhecimento coletivo
sobre os clientes, os processos de negócio e a concorrência, as informações são a
matéria-prima do trabalho de cada indivíduo na organização (TEIXEIRA FILHO,
2000). Num caso como este, a GC pode trazer um ganho enorme ao gerenciar este
conhecimento coletivo. Provavelmente esta seja a situação em que há mais ganho com a
implantação da GC.
Muito freqüentemente as pessoas precisam colaborar e comunicar,
especialmente quando trabalham num ambiente distribuído em tempo e espaço
(LINDVALL et al., 2003). Neste campo a GC também atua, permitindo que pessoas em
diferentes pontos geográficos colaborem e comuniquem. Há diversas ferramentas de GC
que auxiliam nesta área como ferramentas de e-mail, groupware, listas de discussão,
intranets, portais corporativos, entre outros.
32
Numa economia global, o conhecimento torna-se a maior vantagem competitiva
de uma organização (TEIXEIRA FILHO, 2000). O mesmo autor ainda escreve que
“investir em GC só vale a pena para aquelas empresas que estejam pensando a longo
prazo, que pretendam ainda estar no negócio daqui a muitos anos.”
33
3 GERÊNCIAMENTO ELETRÔNICO DE DOCUMENTOS - GED
3.1 GED
Segundo a definição do GARTNER GROUP (2005), GED é ”um grupo de
tecnologia que provê um meio de facilmente se armazenar, localizar e recuperar
informações baseadas em documentos e dados eletrônicos, durante todo o seu Ciclo de
Vida.
Em CENADEM (2005) GED é definido como um grupo de tecnologias,
divididas em cinco funcionalidades básicas: captação, gerenciamento, armazenamento,
distribuição e preservação de informações não-estruturadas.
Baseado em (XEROX, 1999 apud DUTRA, 2001), o Gerenciamento Eletrônico
de Documentos é um conjunto de sistemas lógicos e inteligentes, criados para
automatizar o processo de gerenciamento de documentos, em todas as suas faces:
criação, distribuição, utilização, armazenamento e recuperação.
A definição de GINGRANDE (2003) é bastante semelhante: “refere-se a um
ambiente computadorizado que permite a criação, captura, organização,
armazenamento, restauração, manipulação, e circulação controlada de documentos em
formato eletrônico.” RAYNES (2002) define GED da mesma forma.
“No princípio, a tecnologia de GED enfatizava basicamente a digitalização de
um documento gerado em papel através de um escaner.” CENADEM. Atualmente
muitas funcionalidades foram adicionadas ao GED e esta tecnologia passou a gerenciar
a documentação das organizações.
Segundo o CENADEM (2005), os sistemas de GED não são simplesmente
sistemas de gerenciamento de arquivos. O GED é mais, pois ele implementa
categorização de documentos, tabela de temporalidade, ações de disposição e controla
níveis de segurança. Um sistema de gerenciamento de arquivos não implementa as
características de um sistema GED.
34
As informações podem ser classificadas em dois tipos: estruturadas e não-
estruturadas. Informações estruturadas são aquelas que podem ser inseridas e
futuramente tratadas por um conjunto de aplicações de banco de dados. Já as não-
estruturadas são aquelas informações que não possuem estrutura e por isso não podem
ser facilmente gerenciadas num repositório de dados. São exemplos de informação não
estruturada: relatórios, fax, vídeos, mensagens de correio eletrônico, entre outras.
De acordo com VALLE & BALDAM, (2002), das informações que as empresas
precisam para tomar decisões, 80% são do tipo não estruturadas, quase sempre recaindo
sobre os documentos. Logo, o GED torna-se uma ferramenta de utilidade por permitir
que os colaboradores da organização tenham informação não estruturada na velocidade
e precisão que os tempos atuais exigem. Ao armazenar os documentos e oferecer opções
de pesquisa, o GED auxilia as pessoas a lidar com esta grande quantidade de
documentos.
Uma das aplicabilidades do GED é apoiar o gerenciamento do conhecimento.
Por esta razão esta dissertação embasou-se nos conceitos de gestão do conhecimento e
Gerenciamento Eletrônico de Documento. O GED dá suporte à gestão do conhecimento
na medida que armazena e disponibiliza as informações não-estruturadas de maneira
rápida e segura e estas informações ajudam no processo de obtenção do conhecimento.
Mas, baseado em FANTINI (2001), o que mais tem sensibilizado as
organizações para investir em sistemas GED é a possibilidade de aumento da
produtividade e competitividade. Isto é natural, já que dificilmente uma organização vai
despender tempo e dinheiro numa tecnologia, se não for para obter algum retorno.
Além disto, um sistema GED atende às exigências de programas de certificação,
como ISO 9000, que cobra controle efetivo dos documentos e processos, conforme
citado em FANTINI (2001). Este tipo de certificação é importante, já que comprova um
certo grau de organização. Muitos clientes exigem esta certificação de seus fornecedores
e diversas vezes esta certificação é requisitada em processos de licitação.
35
3.2 Implantação do GED
A implantação do GED requer um planejamento detalhado e um estudo antes da
execução.
Para FANTINI (2001), uma implantação de um projeto de gerenciamento
eletrônico eficaz, e verdadeiramente produtivo, deve-se começar a partir de um estudo
criterioso das reais necessidades da empresa, dos usuários e das perspectivas em vista.
A exatidão desses dados permitirá o desenho de um projeto que definirá os produtos
certos, os processos adequados e fases de implantação pertinentes a cada caso.
Há muitos casos de organizações que implantam o GED por modismo, mas sem
o devido preparo e acabam apenas digitalizando todos os seus papéis. Nestes casos o
GED não auxilia tanto quanto poderia. A literatura recomenda que antes da implantação
sejam feitos estudos sobre os documentos da organização para saber quais são mais
utilizados, quais têm valor legal e precisam ser mantidos, quais podem ser descartados,
qual o fluxo dos documentos dentro da organização, qual a classificação de cada
documento e outras informações pertinentes. Desta forma, diminui-se o risco de
digitalizar todos os papéis e inseri-los no GED dando-lhes a mesma importância.
STARBIRD e VILHAUER, (1997) apud SANTIAGO, (2004) fazem a seguinte
observação sobre conversão de papel para mídia eletrônica: “O fator mais importante na
determinação de converter ou não documentos em papel para mídia eletrônica ou
micrográfica vem das necessidades dos usuários. A quantidade de usuários, freqüência
de pesquisa, duração do uso, necessidade de consultas simultâneas e custos do acesso,
afetam as decisões sobre a conversão.”
Como exemplo do que foi citado no parágrafo anterior, há o caso prático da
Petrobras. Na unidade de negócios da industrialização do xisto (UN-SIX), unidade que
faz parte do abastecimento do sistema Petrobras, antes de se implantar o projeto de
gerenciamento eletrônico de documentos uma equipe formada por bibliotecários e
pessoas ligadas a sistemas da informação, fez um levantamento detalhado de todos os
documentos na unidade, classificando-os e indicando quais deveriam ser digitalizados,
quais deveriam permanecer guardados e quais poderiam ser descartados.
36
O GED por si só não organiza de forma adequada a documentação. Mesmo que
a documentação tenha sido informatizada, é necessário organizá-la. (KOCH, 1999 apud
BALDAM, 2003).
RAYNES, (2002) sugere que as pessoas formam uma parte vital em qualquer
sistema de gerenciamento de documentação. Se não estiverem treinadas e não tiverem
entendido o sistema, podem comprometer seu sucesso.
VALLE & BALDAM (2002) enumeram algumas falhas mais comuns em
projetos de implantação de GED:
a) Não consultar adequadamente o pessoal da área;
b) Tentar instalações em infra-estrutura inadequada;
c) Não exigir assinatura nos documentos de projeto;
d) Tentar usar um sistema de GED para resolver outro problema de gestão que a
empresa possui;
e) Subdimensionar recursos de digitalização e indexação;
f) Implantar o GED sem ter um planejamento adequado da análise documental,
temporalidade documental, etc., acreditando que se implantar o GED, os documentos
em papel se auto-organizarão.
As pessoas que mexem com a documentação precisam ser envolvidas no
processo, pois elas é que mais conhecem sobre o assunto. É comum deixarem a
implantação de projetos desta natureza nas mãos do pessoal da Tecnologia da
Informação (TI), que geralmente não entendem tanto sobre a documentação do resto da
organização. Além disto, quando as pessoas são envolvidas, sentem-se prestigiadas e
torcem pelo sucesso da implantação.
É comum as organizações reservarem poucos recursos para a digitalização e
indexação dos documentos (BALDAM et al., 2002). Como foi visto, esta é uma das
falhas mais comuns em projetos GED. Estes serviços são caros e há muitas empresas no
mercado que fazem apenas este tipo de serviço, haja vista a grande quantidade de
dinheiro envolvida nestas operações.
37
Um outro item citado como falha comum na implantação do GED é a falta de
planejamento adequado da análise documental e temporalidade documental. Em
(LOPES, 2004) há informações sobre tabela de temporalidade e Gestão Documental.
Para concluir, FANTINI (2001) cita que toda mudança gera alguns transtornos,
prescinde de fases de adaptação, porém pode ser tranqüila quando se leva em conta a
particularidade de cada projeto, evitando, assim, surpresas desagradáveis tais como:
objetivos não atendidos, incompatibilidades com as plataformas existentes, faltas de
precisão no núcleo do projeto, etc.
3.3 Principais Tipos de Solução GED
Há diferentes tipos de sistemas de GED no mercado. De acordo com a
necessidade de uso e do tipo de documento a ser gerenciado, haverá um sistema que
será o mais adequado.
Segundo BALDAM, (2003); CENADEM (2005); VALLE & BALDAM (2002);
DUTRA, (2001) e FANTINI (2001), há atualmente os seguintes tipos de solução de
GED:
a) Processamento, arquivamento e recuperação de documentos (Document
Imaging);
b) Gerenciamento de documentos (Document Management);
c) Gerenciamento Eletrônico de Documentos Técnicos (Engineering Document
Management System - EDMS);
d) • Integração com outros sistemas de processamento de dados (Image Enable);
e) • ERM (Enterprise Report Management)/ COLD (Computer Output to Laser
Disc);
f) • Processamento de formulários (Forms Processing);
g) • Workflow.
A seguir é apresentado um resumo de cada uma destas soluções.
38
3.3.1 Gerenciamento da Imagem dos Documentos
Esta tecnologia é normalmente usada para gerenciar documentos prontos, que
não sofrerão mais alterações. É mais conhecida por seu nome em inglês, Document
Imaging.
Os objetivos básicos são: capturar documentos em formato eletrônico,
armazená-los e garantir sua segurança, oferecer ferramentas para recuperá-los e permitir
a manipulação destes documentos.
3.3.2 Gerenciamento de Documentos Digitais
Mais conhecida por seu nome em inglês, Document Management. Ao contrário
do Document Imaging, que é usado normalmente com documentos prontos, o document
management permite o controle do documento desde o momento da sua criação até o
seu respectivo descarte.
Possui várias informações sobre os documentos que estão sendo gerenciados.
Estes documentos podem ser oriundos de editores de texto, de planilhas, de
apresentações, entre outros. Podem ser inclusive imagens.
Sistemas de document management oferecem características que incluem
armazenamento de documentos e arquivos, controle de versão, organização de
documentos de diferentes formas, procura e recuperação em técnicas de indexação e
avançados mecanismos de busca; e acesso a partir de qualquer estação conectada a
Internet. (LINDVALL et al., 2003)
3.3.3 Disponibilização de Imagem
Mais conhecida por seu nome em inglês, Image Enable. Tecnologia que permite
a integração dos documentos que estão sendo gerenciados no GED com outros sistemas
através da disponibilização destes documentos no sistema. Um exemplo é poder anexar
documentos que estão no GED a programas diversos.
Usando a tecnologia de Image Enable é possível anexar notas fiscais a um
sistema de contabilidade, anexar especificações de produtos num módulo de compra do
39
SAP R/3, anexar uma carta de reclamação de um cliente ao CRM da empresa, entre
outros tipos de uso.
3.3.4 Gerenciamento Corporativo de Relatórios
Mais conhecido por suas siglas em inglês, ERM ou COLD. Embora o termo
COLD (Computer Output to Laser Disc) seja ainda bastante utilizado, pouco a pouco
vem sendo substituído por ERM (Enterprise Report Management), que condiz com o
moderno aspecto que esse sistema possui. (BALDAM, 2003)
Esta tecnologia tem como objetivo gerenciar relatórios vindos de sistemas
legados da companhia, como mainframes e aplicações antigas. Geralmente estes
relatórios são grandes, mas tratados como se fossem apenas um documento.
Como exemplo destes relatórios, podemos citar extratos bancários, faturas de
telefone, água e luz.
3.3.5 Processamento de Formulários
Mais conhecido por seu nome em inglês, Forms Processing. É o processamento
eletrônico de formulários. A digitalização converte imagens de documentos para o
mundo digital. A etapa seguinte transforma essa imagem em dados processáveis por um
sistema de computação. A tecnologia de processamento eletrônico de formulários
permite reconhecer as informações nos formulários e relacioná-las com campos nos
bancos de dados. O processamento eletrônico de formulários está automatizando o
processo de digitação em muitas empresas. Essa tecnologia já vem sendo utilizada por
alguns bancos para agilizar o processamento dos formulários de abertura de contas.
Outra grande aplicação dessa tecnologia é o reconhecimento de todos os formulários
manuscritos do censo 2000 no Brasil, feito pelo IBGE – Instituto Brasileiro de
Geografia e Estatística. (FANTINI, 2001)
40
3.3.6 Fluxo de Trabalho
Para DUTRA (2001), o termo fluxo de trabalho ou Workflow, refere-se ao modo
como os documentos são processados. São sistemas que permitem a automatização e o
controle de processos de trabalho, organizando trâmites e prazos, sincronizando
pessoas, tarefas e documentos. Um sistema de GED integra e encaminha
automaticamente o fluxo de documentos em formato eletrônico de estação de trabalho
para estação de trabalho, ao longo de uma organização. Os documentos e arquivos não
são simplesmente armazenados e recuperados, mas sim utilizados na condução de
transações de negócios.
3.4 Dados que Justificam o Uso de Gerenciamento Eletrônico de Documentos
Em KOCH, (1999) apud BALDAM (2003) é possível encontrar dados que
justificam o Gerenciamento Eletrônico de Documentos:
a) Pesquisa da Coopers & Lybrand (antes da associação com Price Waterhouse),
USA, mostra que executivos gastam em média 150 horas/ano procurando,
localizando, solicitando e esperando documentos;
b) Em cada 20 documentos, um se perde, segundo a mesma fonte;
c) Executivos gastam de 20% a 45% do tempo pensando, criando ou manipulando
documentos (Gartner /Datapro);
d) Um funcionário guarda, em média, 20.000 folhas de papel por ano em arquivos
dos mais diversos tipos (Gartner /Datapro);
e) Consome 12% a 15% de renda da empresa com manipulação de documentos
(Gartner /Datapro);
f) “Em média, 90% do tempo da vida útil de um documento é gasto em trânsito e
filas. Ou seja, necessita gerenciamento.” (Delphi Consulting);
g) “Gastam-se U$ 250,00 para recriar um documento de engenharia perdido”
(Coopers & Lybrand).
41
42
3.5 Benefícios do GED
Levando-se em consideração o que foi escrito por BALDAM, (2003);
GINGRANDE, (2003); DUTRA, (2001); FANTINI, (2001), é possível relacionar os
seguintes benefícios de se implantar o GED:
a) Aumento da satisfação do usuário;
b) Incremento à produtividade;
c) Acesso imediato e multi-usuário a qualquer informação;
d) Alta velocidade e precisão na localização de documentos;
e) Melhor controle dos documentos;
f) Redução do espaço físico de armazenagem;
g) Minimização de perdas e extravio de documentos;
h) Integração com outros sistemas e tecnologias;
i) Disponibilidade instantânea de documentos sem limites físicos;
j) Gerenciamento e otimização do workflow;
k) Maior agilidade nas transações entre empresas;
l) Proteção do patrimônio;
m) Proteção contra catástrofes que poderiam danificar o acervo;
Outras vantagens apontadas por GINGRANDE (2003) é poder procurar os
documentos num único lugar, apesar de eles estarem armazenados em diferentes
lugares; busca por palavra chave no conteúdo dos documentos; navegação por tópicos
(categorias); e categorização automática de documentos.
Um dos maiores benefícios do GED é facilitar o armazenamento de cópias de
segurança dos documentos. Pode-se fazer cópia física de todos os documentos em papel,
mas isto pode ser caro e pode exigir muito espaço físico. Já se os documentos estiverem
num GED, é bastante simples fazer backups e os mesmos podem ficar guardados em
locais diferentes, para proteção contra desastres naturais.
43
Apesar de o GED trazer todos estes benefícios, os usuários precisam investir um
mínimo de tempo necessário para aprender a usar as funcionalidades da ferramenta
(GINGRANDE, 2003) e poder aproveitar todos estes benefícios citados neste item.
44
4 GERENCIAMENTO ELETRÔNICO DE DOCUMENTOS TÉCNICOS (EDMS)
4.1 EDMS
“O propósito do EDMS é gerenciar durante todo o ciclo de vida documentos
técnicos da empresa, seja na fase da implantação, seja durante a vida útil do
empreendimento. Analisando com profundidade, um EDMS é essencialmente um
Document Management, porém deve possuir algumas características adicionais para que
possa manipular documentos técnicos, características estas que normalmente não estão
disponíveis em softwares de Document Management comuns de mercado.” (AVEDON,
1999)
VALLE & BALDAM (2002) definem EDMS de maneira semelhante:
“Essencialmente é um sistema de Document Management com maior ênfase em
controle de comparação de revisões, visualização de arquivos CAD, grandes formatos,
arquivos híbridos (CAD + raster), criação de referências entre documentos, integração
com softwares de manutenção e controle de operação de fábrica e/ou instalação.”
Para aumentar sua competitividade, organizações estão cada vez mais usando
Gerenciamento Eletrônico de Documentação Técnica (EDMS), visto que isto pode
reduzir atrasos e custos, e aumentar a receita destas organizações (HSU & HWANG,
2004). Uma organização que possua muita documentação técnica como uma refinaria de
petróleo, por exemplo, tem muitas dificuldades em gerenciar seus documentos sem uma
ferramenta como o EDMS.
PELTONEN et al. (1996); PENG & TRAPPEY, (1998) apud HSU & HWANG
(2004) comentam que no processo de desenvolvimento de produto, grande quantidade
de dados técnicos são produzidos e precisam ser processados. Para reduzir atrasos e
custos causados pela ineficiência no gerenciamento de dados técnicos, organizações
estão progressivamente migrando para EDMS.
Segundo GIARETTA, (2001), projetos de engenharia se caracterizam por serem
compostos por objetos com estruturas complexas, criados por grupos de projetistas
trabalhando em ambientes de cooperação. Devido a esta demanda diferenciada, os
45
fabricantes de sistemas GED tiveram de elaborar um novo produto para atender a estas
necessidades, surgindo então o EDMS.
Como muitas características dos sistemas de Document Imagem, Document
Management e EDMS são iguais, é comum ver fornecedores vendendo solução
inicialmente projetadas para serem sistemas de Document Imagem ou Document
Management como se fossem EDMS.
Acontece de fornecedores de soluções de Document Imaging, simplesmente por
possuírem um visualizador de arquivos CAD, considerarem sua solução como sendo
uma solução de EDMS. É um tipo perigoso de erro, pois pode induzir o usuário a
comprar uma solução que não ajudará de fato o pessoal da engenharia a criar, modificar
e gerenciar documentos técnicos. Não será mais que um repositório de imagens de
documentos. (VALLE & BALDAM, 2002)
VALLE & BALDAM (2002) ainda complementam este raciocínio afirmando
que a experiência acumulada em GED de uso geral não pode e não deve ser aplicada na
íntegra a projetos de engenharia, sob pena de não se ter um projeto adequado à situação
real que os setores de projetos necessitam.
Projetos de engenharia possuem algumas particularidades, por isto é que a
experiência em GED não é suficiente para se gerenciar documentação técnica.
4.2 Características que Tornam o EDMS Especial
As organizações e seus executivos têm hoje bem fundamentadas a urgência de
alterar seu modo de trabalho e aumentar a velocidade de acesso à informação,
principalmente motivada pela enorme mudança que ocorre diariamente no mercado de
trabalho e nos produtos/serviços (MILER, 2001 apud VALLE & BALDAM, 2002). O
grande problema começa a existir quando se quer dar tratamento similar para,
documentos que chegam via e-mail, documentos do setor financeiro, documentos do
setor de pessoal, plantas de engenharia, documentos de projetos em andamento, entre
outros. (BENEDON, 2001 apud VALLE & BALDAM, 2002). Especialmente no
quesito engenharia, já tivemos chance de ver sistemas de Document Imaging ou
Document Management gerenciando documentos típicos de Engenharia de Manutenção,
46
gerando obviamente um desconforto por parte dos usuários, pois não conseguem fazer
as funções típicas que uma engenharia executa no seu dia-a-dia (BALDAM et al.,
2002).
Por esta razão, escreveremos aqui quais as características que diferem o EDMS
das demais soluções GED.
VALLE & BALDAM (2002) listam os motivos pelos quais o EDMS exige
tratamento especial:
a) temporalidade;
b) tamanho físico dos documentos;
c) o documento está sempre sujeito a alterações;
d) visualização de documentos CAD e híbridos;
e) disponibilidade imediata de documentos em manutenção corretiva e operação;
f) integração com outros sistemas de engenharia;
g) custo do documento de engenharia;
Por apresentar estas particularidades é que o EDMS precisa ter algumas
características diferentes dos demais Gerenciadores Eletrônicos de Documento.
Essencialmente um EDMS é um sistema de Document Management, mas com algumas
características especiais para que possa atender a estas diferenças apresentadas aqui.
Serão detalhadas a seguir algumas destas características especiais.
4.2.1 Período de Existência do Documento
A existência de um documento técnico dependerá da vida útil do equipamento,
instalação ou processo ao qual ele estiver relacionado. Enquanto existir o tal
equipamento, instalação ou processo, deverá existir também a sua documentação. Isto
difere dos demais documentos que possuem um ciclo de vida que indica o tempo que o
documento deverá ser armazenado.
47
4.2.2 Dimensões dos Documentos
Há documentos técnicos com mais de dois metros de comprimento, ao contrário
dos demais tipos de documentos, que geralmente têm tamanho A4. Devido a esta
particularidade, é necessário que o gerenciador permita impressões compatíveis com
esta necessidade.
4.2.3 Possibilidade de Alteração do Documento Enquanto Existir
Um documento de engenharia está sempre sujeito a alterações. Enquanto existir
o documento, haverá sempre a possibilidade de criação de novas versões. Neste aspecto
difere da maioria dos demais documentos que depois de serem aprovados, não são mais
alterados.
4.2.4 Visualização Complexa de Documentos
Projetos de engenharia podem exigir visualização complexa de arquivos CAD.
Alguns sistemas de document imagem possuem visualizador CAD, mas estes não
atendem a todas as demandas de visualização exigidas por projetos de engenharia, como
por exemplo visualização de modelos em 3D, fontes true type, arquivos de referência e
arquivos híbridos (BALDAM, 2003).
4.2.5 Integração com Outros Sistemas de Engenharia
Haverá a necessidade de integrar o EDMS com outros sistemas de engenharia
como planejamento de obras, manutenção de equipamentos, planejamento de paradas de
equipamentos, entre outras. Estas integrações são muito específicas e exigem
conhecimento de um especialista em engenharia. Além disto, há a integração com
sistemas de gestão da organização, como por exemplo o ERP.
48
4.2.6 Alto Custo dos Documentos Armazenados no EDMS
O custo para refazer um desenho de engenharia perdido é em média US$ 250,00,
segundo BALDAM, (2003). Isto porque é necessário que se entenda uma série de outros
documentos para que se refaça o desenho que se perdeu e é necessário também que um
especialista vá na área para coletar as informações e que outro desenhe novamente.
Devido a estes altos custos, há a necessidade de uma política de backup bastante
exigente. É difícil se fazer cópias de segurança de documentos em papel, mas torna-se
relativamente simples fazê-los em formato digital, portanto levando-se em consideração
a importância dos documentos, é adequado possuir cópias em locais seguros, de
preferência em mais de um lugar diferente. Certamente há um preço para se armazenar
estas cópias, mas o valor destes documentos compensa estes gastos.
49
5 AQUISIÇÃO DE SOFTWARE
Projetos de aquisição de software podem ser bastante diferentes entre si.
Enquanto uns são pequenos, rápidos e simples, outros são grandes, demorados e
complexos. Por esta razão, COCKBURN (2000) escreveu que “cada organização deve
desenvolver sua própria maneira de trabalhar, e cada projeto deve ter sua própria
metodologia, considerando a cultura, posição, criticidade e a tecnologia.”
Para que estes projetos de aquisição tenham maior possibilidade de sucesso,
foram criados guias, padrões, modelos e metodologias. Estas abordagens auxiliam
principalmente no sentido de dar formalidade aos processos. Elas são baseadas no
aprendizado obtido em aquisições reais.
O estudo sobre aquisição de software tem recebido bastante atenção em virtude
dos vários problemas que as grandes organizações têm enfrentado, principalmente
porque estes problemas resultam em perdas financeiras. FARBEY & FINKELSTEIN
(2001) em seu artigo “Aquisição de Software, uma análise estratégica de negócio”
explicam que “...o processo de aquisição de software pode ser uma fonte de vantagem
competitiva”.
5.1 Dificuldades Existentes Para Aquisição de Software
A atividade de aquisição de software é complexa devido a necessidade de se
especificar corretamente o software desejado e ainda internamente manter um controle
que garanta que todos os requisitos desejados sejam atendidos rigorosamente.
SEI (2005) relata que os principais problemas dos projetos de aquisição são
conhecidos: cálculo errado dos custos, estimativa errada de prazos e desempenho aquém
do esperado. Com base nestas informações, é possível deduzir que estes problemas
surgem principalmente por incapacidade de gestão.
“Uma organização de aquisição imatura pode levar um projeto de aquisição de
software ao fracasso, da mesma forma que uma organização com processo de
desenvolvimento de software imaturo”. (SEI, 2005)
50
Os softwares são adquiridos de organizações que desenvolvem software.
ALVES (2002) relata que nas organizações imaturas que desenvolvem software, os
cronogramas e orçamentos são rotineiramente ultrapassados, porque não são baseados
em estimativas realistas. Em contrapartida, nas organizações maduras os gerentes
monitoram a qualidade dos produtos e a satisfação dos clientes. Este monitoramento
possibilita a melhoria de seus processos.
Com base em estudo de diferentes autores, ALVES (2002) lista os problemas
mais comuns nos projetos de aquisição de software:
a) Não-intervencionismo: o cliente não é uma parte ativa do projeto após a
assinatura do contrato;
b) Escopo volátil: o cliente adiciona e altera o escopo e a funcionalidade do
projeto com o trabalho em andamento e com prazos e recursos limitados;
c) Fragmentação: membros das equipes do cliente e do contratado são retirados
dos projetos aleatoriamente;
d) Preciosismo: requisitos com soluções complexas no lugar de soluções
tecnicamente simples;
e) Engenharia: o cliente diz a fornecedor como fazer seu trabalho, e não qual é o
trabalho;
f) Indicadores: as medidas de progresso e de performance são qualitativas, e não
quantitativas;
g) Não-envolvimento do usuário final: o ponto de vista do usuário final não é
incorporado na funcionalidade e usabilidade do produto;
h) Requisitos pobres: o cliente fornece um conjunto de requisitos incompletos e
sem validação ao contratado;
i) Falsas promessas: o pessoal de marketing do fornecedor faz promessas ao
cliente que a equipe técnica não pode cumprir;
j) Recurso inadequado quanto a provimento financeiro, equipe, ferramentas e
equipamentos;
k) Ausência de suporte da alta gerência da empresa;
l) Ausência de objetivos claros, conduzindo os membros do projeto para
direções não-uniformes (não-alinhamento de objetivos);
51
m) Comunicação ineficiente: ausência de um canal de comunicação efetivo, de
forma que as informações não chegam até as pessoas em tempo hábil.
A criação de um guia definitivo sobre o assunto é difícil já que a complexidade
dos softwares está continuamente crescendo e que o guia teria de atender as diferentes
categorias existentes de software.
Apesar de todas estas dificuldades, quando ambos, fornecedor e cliente, possuem
nível de maturidade alto em seus processos, a probabilidade de sucesso é mais alta
(GALLAGHER & SHRUM, 2004).
5.2 Abordagens Consultadas
Com o aumento da complexidade dos softwares e com a necessidade cada vez
maior de se obter softwares com alta performance, baixo custo e em tempo reduzido,
criou-se a necessidade de se desenvolver material que sirva de orientação para este
processo.
Para compensar as dificuldades listadas no item anterior, foram criados bons
materiais sobre o assunto. Para esta dissertação foram estudados os seguintes padrões e
modelos:
a) CMMI - Acquisition Module; BERNARD et. al. (2005)
b) Software Acquisition – CMM; SOFTWARE ENGINEERING INSTITUTE (2002)
c) FAA-iCMM; IBRAHIM (2001)
d) IEEE Recommended Practice for Software Acquisition. IEEE Std. 1062 (1998)
A seguir serão comentadas duas destas abordagens lidas.
5.2.1 CMMI – AM
O Capability Maturity Model Integration Acquisition Module é um guia que
descreve as melhores práticas para uso na aquisição de produtos. Já o CMMI é um
modelo consagrado no mercado que trata sobre qualidade aplicada no desenvolvimento
52
de software. Ambos foram desenvolvidos pelo SEI, The Software Engineering Institute,
que é uma fundação federal americana de pesquisa e centro de desenvolvimento
patrocinado pelo departamento de defesa americano.
Embora o CMMI contenha muitas boas práticas que podem ajudar uma
organização de aquisição, CMMI-AM provê informações adicionais que foram escritas
com o intuito de ajudar estas organizações de aquisição a mais facilmente aplicar as
melhores práticas do CMMI aos seus processos. (GALLAGHER & SHRUM, 2004)
O CMMI-AM define práticas eficientes e eficazes para organizações de
aquisição do governo. Melhores práticas de aquisição são enfocadas dentro das
organizações de aquisição para assegurar que a aquisição seja conduzida eficazmente, e
são enfocadas fora da organização de aquisição para realizar monitoramento do projeto
e monitoramento do fornecedor. Estas melhores práticas fornecem um fundamento para
disciplina em aquisição de software e rigor que possibilita que o desenvolvimento de
produtos e serviços possa ser repetidamente executado com altos níveis de sucesso.
(GALLAGHER & SHRUM, 2004)
As práticas de aquisição contidas no CMMI-AM são um resumo das seguintes
fontes de melhores práticas:
a) Modelos CMMI;
b) SA-CMM;
c) FAA-iCMM;
d) Seção 804 do National Defense Authorization Act.
O CMMI-AM está dividido em três áreas de processo que são: Área de Processo
de Gerenciamento de Projeto, Área de Processo de Engenharia e Área de Processo de
Suporte.
A Área de Processo de Gerenciamento de Projeto cobre as atividades de
gerenciamento de projeto, relacionadas a planejamento, monitoramento e controle de
projetos.
53
Já a Área de Processo de Engenharia estabelece um conjunto de requisitos
consistentes que são derivados das necessidades dos stakeholders
4
e das especificações
de capacidade operacional. Este conjunto de requisitos é necessário para que se tenha
como garantir que todas as necessidades do usuário final serão satisfeitas, bem como
que o software funcione com todas as potencialidades possíveis.
Finalmente, a Área de Processo de Suporte inclui os processos e ferramentas
requeridos para que medições e técnicas de decisão possam ser efetivamente aplicadas
para gerenciar o projeto.
Na figura pode ser vista a estrutura do CMMI-AM.
Figura 5. Estrutura do CMMI-AM
Fonte: GALLAGHER & SHRUM (2004)
Por muitas de suas práticas terem sido extraídas de SA-CMM e FAA-iCMM;
por ser um guia mais enxuto; e por ser este mais recente
5
que os demais, foi escolhido
para servir de base para a elaboração do guia desta dissertação. Além disto, os modelos
como o IEEE Recommended Practice for Software Acquisition não indicam como o
processo de aquisição de software pode ser melhorado incrementalmente. Isto é provido
4
Termo utilizado para se referir a qualquer pessoa que terá alguma influência direta ou indireta sobre os
requisitos do sistema. Dentre os stakeholders destacam-se os usuários finais que interagirão com o
sistema e o pessoal que vier a ser afetado por ele. (SOMMERVILLE, 2003)
5
Publicado em Maio de 2005
54
por modelos de maturidade de aquisição de software como o CMMI-AM.
(ULKUNIEMI & SEPPÄNEN, 2002).
5.2.2 IEEE Práticas Recomendadas para Aquisição de Software
É um padrão da IEEE que define um conjunto de práticas de qualidade que
podem ser selecionadas e aplicadas durante um ou mais passos num processo de
aquisição de software. Funciona melhor quando aplicado à aquisição de softwares do
tipo MOTS
6
, que é o caso do EDMS.
A Tabela 1 resume bem as cinco fases deste padrão:
Fase Marco de
início da fase
Marco de fim
da fase
Passos no processo de aquisição
de software
Planejamento Idéia é
desenvolvida
Elaboração do
RFP
1) Planejar estratégia Organizacional
2) Implementar processos
organizacionais
3) Determinar os requisitos de
Software
Contratação RFP elaborado Assinatura do
contrato
4) Identificar potenciais fornecedores
5) Preparar requisitos do contrato
6)Avaliar propostas e selecionar o
fornecedor
Implementação
do Produto
Contrato assinado
Recebimento do
software
7) Gerenciar o desempenho do
fornecedor
Aceite do
produto
Software
recebido
Aceitação do
produto
Aceitar o software
Uso Software aceito Produto não é
mais usado
Usar o software
Tabela 1. As 5 fases do modelo IEEE
Fonte: SOFTWARE ENGINEERING STANDARDS COMMITTEE OF THE IEEE COMPUTER
SOCIETY, 1998a.
Este material estudado sobre aquisição de software serviu de base para que o
guia do capítulo 6 pudesse ser escrito. O guia foi baseado nas melhores práticas e
técnicas apresentadas nestes materiais, mas vale ressaltar que o foco principal desta
6 Modified off the shelf software. É um software de prateleira modificável.
55
dissertação é o EDMS e que o conhecimento sobre aquisição de software serviu como
instrumento para possibilitar a elaboração do guia.
56
6 GUIA DE AQUISIÇÃO DE EDMS
O guia apresentado neste capítulo foi elaborado com base nos estudos feitos
sobre EDMS e sobre aquisição de software. Foi baseado no módulo de aquisição da
CMMI (BERNARD et. Al., 2005). Como este módulo é genérico, ou seja, aplica-se a
aquisição de qualquer software ou serviço, alguns itens não serão considerados por não
se aplicar na aquisição de software de EDMS.
A Tabela 2 resume o guia:
Área de Processo Atividades
Gerenciamento de Projeto a) Planejamento de projeto;
b) Monitoramento e controle de projeto;
c) Monitoramento de solicitação e
contrato;
d) Gerenciamento de projeto integrado;
e) Gerenciamento de riscos.
Engenharia f) Desenvolvimento de Requisitos;
g) Gerenciamento de Requisitos;
h) Verificação;
i) Validação;
Suporte j) Análises de Decisão;
k) Análise e Medição;
l) Transição para Operação e Suporte.
Tabela 2. Resumo do guia
57
6.1 Área de Processo de Gerenciamento de Projeto
6.1.1 Planejamento de Projeto
O propósito do planejamento de projeto é estabelecer e manter planos que
definem as atividades do projeto de aquisição.
Como primeiro passo, é necessário estimar os parâmetros do planejamento do
projeto, como por exemplo o escopo do projeto de aquisição; os atributos gerais do
software EDMS a ser adquirido; as fases de ciclo de vida do projeto; e o esforço do
projeto de aquisição e custo do software EDMS. Estas estimativas são necessárias para
que se possa ter uma visão inicial do projeto como um todo.
O segundo passo é elaborar um plano de projeto, para gerenciar o projeto. Neste
plano de projeto deve ser estabelecido o orçamento e a programação de datas do projeto;
os riscos do projeto devem ser identificados e analisados; deve ser elaborado um plano
para o gerenciamento dos dados do projeto; um levantamento deve ser feito para
verificar os recursos necessários para executar o projeto; um levantamento deve ser feito
para verificar quais conhecimentos e habilidades são necessários para se executar o
projeto; e finalmente o envolvimento dos stakeholders identificados deve ser planejado.
Este plano norteará o projeto.
O terceiro e último passo é estabelecer os compromissos relacionados ao plano
de projeto. Primeiramente é necessário rever os planos e entender quais são os
compromissos que precisam ser estabelecidos para que o projeto seja um sucesso e logo
em seguida deve-se comparar os recursos disponíveis com os recursos necessários para
a execução do projeto, para verificar se são compatíveis. Caso haja necessidade, será
preciso fazer ajustes. Após isto, vem a obtenção do compromisso dos stakeholders
responsáveis pela execução e suporte da execução do plano. Em organizações de grande
porte é comum existirem documentos em que os responsáveis assinam se
comprometendo em relação ao que foi planejado.
58
6.1.2 Monitoramento e Controle de Projeto
O propósito do monitoramento e controle de projeto é prover um
acompanhamento do progresso do projeto. Assim, é possível tomar ações de correção
quando a execução do projeto desvia significativamente do planejado.
O desempenho e o progresso do projeto são monitorados junto ao plano de
projeto. Para isto ser possível, é necessário monitorar os parâmetros do que foi
planejado com o que está sendo realizado; monitorar o que as pessoas se
comprometeram a realizar e o que elas estão realizando; monitorar os riscos que foram
identificados no plano do projeto; monitorar o gerenciamento dos dados do projeto;
monitorar o envolvimento dos stakeholders no projeto para ver se está compatível com
o envolvimento previsto no plano de projeto; periodicamente revisar o progresso, o
desempenho e os resultados do projeto; e revisar as realizações e resultados do projeto
através dos milestones
7
selecionados.
Ações corretivas são executadas quando o desempenho ou os resultados do
projeto apresentam um desvio significativo do planejado. Isto é feito coletando e
analisando os resultados obtidos e determinando as ações de correção necessárias para o
realinhamento.
6.1.3 Monitoramento de Solicitação e Contrato
O propósito do monitoramento de solicitação e contrato é preparar um pacote de
solicitação que identifique as necessidades da aquisição, selecionar um fornecedor que
seja capaz de atender da melhor forma a todas estas necessidades, e estabelecer o
processo para monitorar o fornecedor enquanto durar o contrato.
Para isto, é necessário primeiramente que o projeto seja preparado para conduzir
esta solicitação. Isto é feito designando-se um responsável pela decisão de seleção do
fornecedor; estabelecendo-se um pacote de solicitação que inclua as necessidades da
aquisição e seus critérios correspondentes para avaliação da proposta; estabelecendo-se
estimativas independentes de custo e prazo para aquisição do EDMS; validando-se o
7
Milestones são marcos de referência que permitem saber a situação do andamento de um projeto
59
pacote de solicitação com usuários finais e potenciais fornecedores para garantir que as
estimativas de aproximação, custos e prazo são realistas e podem razoavelmente
conduzir a um bom software de EDMS.
É necessário também selecionar os fornecedores baseando-se no pacote de
solicitação. Para isto, é preciso avaliar propostas que estejam de acordo com os critérios
de avaliação estabelecidos e usar os resultados de avaliação das propostas como base
para o processo de seleção do fornecedor. Para auxiliar nesta seleção de fornecedores,
foi criado uma lista com os principais fornecedores de EDMS do Brasil. Esta lista pode
ser consultada no Anexo I.
VARAJÃO & AMARAL (2001) recomendam comparar o currículo e
experiência dos fornecedores, manter com eles um relacionamento de longo prazo, fazer
visitas às suas instalações e participar de feiras com demonstração de produtos. Isto
serve para tomar conhecimento de sua capacidade.
É necessário ainda que os contratos sejam emitidos baseados nas necessidades
de aquisição e nas propostas dos fornecedores. Isto se consegue estabelecendo um
entendimento mútuo entre o fornecedor selecionado e usuários finais e estabelecendo
processos e procedimentos de comunicação com o fornecedor. Este deve enfatizar as
necessidades, expectativas, e medidas da eficácia a serem usadas através de toda a
aquisição.
Finalmente, é necessário que o trabalho de elaboração do contrato seja realizado
em conjunto com o fornecedor para se garantir que o contrato será executado
corretamente. Para que isto seja possível, é necessário monitorar e avaliar os processos
usados pelo fornecedor, baseado na sua documentação de processos; avaliar o software
de EDMS do fornecedor selecionado baseado no critério de avaliação; e revisar o
acordo do fornecedor, para refletir mudanças nas condições.
No caso de a aquisição ser para o setor público, VARAJÃO & MARAL (2001)
alertam ser fundamental que a seleção do fornecedor ocorra de forma justa.
6.1.4 Gerenciamento de Projeto Integrado
A finalidade do gerenciamento de projeto integrado é estabelecer e controlar o
projeto e o envolvimento dos stakeholders relevantes.
60
Para isto, é preciso gerenciar o envolvimento de stakeholders relevantes no
projeto e identificar, negociar e descobrir junto com eles as dependências críticas do
projeto.
6.1.5 Gerenciamento de Riscos
A finalidade do gerenciamento de riscos é identificar potenciais problemas antes
de eles ocorrerem, então algumas atividades podem ser planejadas e acionadas se
necessário, através da vida do produto ou projeto, para diminuir impactos adversos na
obtenção dos objetivos.
Segundo SOMMERVILLE (2003), os riscos que podem afetar a programação do
projeto ou a qualidade do software em desenvolvimento devem ser previstos e devem
ser tomadas as medidas necessárias para evitar estes riscos.
Primeiramente deve-se determinar as fontes e categorias de riscos; depois definir
os parâmetros usados para analisar e categorizar os riscos e os parâmetros usados para
controlar o esforço de gerenciar os riscos; e estabelecer a estratégia a ser usada para
gerenciamento de risco.
Os riscos devem então ser identificados e documentados e deve ser feita uma
avaliação e categorização de cada risco identificado usando-se as categorias e
parâmetros de risco definidas. Deve-se então determinar a sua prioridade relativa.
Finalmente, deve ser desenvolvido um plano de minimização dos principais
riscos do projeto e deve-se monitorar o status de cada risco periodicamente.
6.2 Área de Processo de Engenharia
A área de processo de engenharia estabelece um conjunto consistente de
requisitos que são derivados das necessidades dos stakeholders e das necessidades
operacionais. O objetivo é que o software adquirido satisfaça todas as necessidades do
usuário final bem como as necessidades operacionais.
61
6.2.1 Desenvolvimento de Requisitos
A Tabela 3 ilustra o que foi feito nesta seção de desenvolvimento de requisitos:
Passo O que foi feito
1
Descreveu-se o que são requisitos;
2
As características de um software EDMS foram listadas;
3
Com base nas características do passo 2, os requisitos não-funcionais foram
levantados.
Tabela 3. Resumo do que foi feito no desenvolvimento de requisitos
A finalidade do desenvolvimento de requisitos é produzir os requisitos do cliente
e do produto.
No artigo de VARAJÃO & AMARAL (2001) são citadas boas práticas com
relação ao levantamento de requisitos. Eles escrevem que os requisitos devem ser
detalhados e levantados por equipes multidisciplinares constituídas por usuários finais,
especialistas do negócio e especialistas em tecnologia.
As necessidades dos stakeholders, expectativas, restrições e interfaces são
coletadas e traduzidas em requisitos do cliente.
Após este levantamento inicial, os requisitos do cliente são refinados e
elaborados. Finalmente, os requisitos são analisados e validados, e uma definição de
funcionalidade requerida é desenvolvida. Nesta análise dos requisitos deve-se garantir
que eles são necessários e suficientes e deve-se balancear as necessidades dos
stakeholders e as restrições.
Segundo WAZLAWICK (2004), o levantamento de requisitos “corresponde a
buscar junto ao usuário, seus sistemas e documentos, todas as informações possíveis
sobre as funções que o sistema deve executar e as restrições sob as quais o sistema deve
operar.”
O estudo sobre os requisitos de um software EDMS é uma das partes mais
importantes desta dissertação. Antes de os requisitos serem levantados, um estudo sobre
as características de um EDMS foi feito.
62
Um EDMS é essencialmente um Document Management com algumas
características adicionais. Serão listadas e detalhadas a seguir todas as características de
um EDMS, baseado nos estudos de (BALDAM, 2003; GIARETTA, 2001; VALLE &
BALDAM, 2002; HSU & HWANG, 2004) e baseado em conversas com o pessoal da
Engenharia da UN-SIX que trabalha com desenhos técnicos. Estas informações serão
utilizadas depois na criação de uma tabela de requisitos de um software EDMS.
63
Características comuns a sistemas de Document Management e EDMS:
a) Controlar versões de documentos;
b) Usar modelos de documentos predefinidos;
c) Possuir integração com editores de documentos;
d) Gerenciar documentos em fase de elaboração;
e) Controlar fluxos documentais;
f) Suportar diversos tipos documentais.
Características de um EDMS:
a) Fazer referências entre documentos;
b) Visualizar e imprimir CAD com funcionalidades reais de projeto;
c) Controlar revisões do tipo as-buildt;
d) Comparar versões de CAD para verificar diferenças;
e) Suportar desenhos com tamanho grande;
f) Permitir comentários e marcações;
g) Possibilitar pesquisa FTR (Full Text Retrieval);
h) Anexar histórico ao documento;
i) Criar grupos de documentos em separado para execução de tarefas;
j) Gerar e receber guias de remessas de documentos;
k) Possuir sistema de segurança que garanta a integridade e confidencialidade dos
documentos;
l) Possuir controle de acesso baseado em perfis;
m) Contemplar requisitos de interface;
n) Disponibilizar acesso pela WEB;
o) Garantir continuidade e atualização do produto;
p) Trabalhar com diferentes bancos de dados do mercado;
q) Permitir programação com linguagens não proprietárias.
A Tabela 4 contém todas as características levantadas de um bom software de
EDMS e uma descrição de cada uma delas:
64
Característica Descrição
Controlar versões
de documentos
Versões são estados distintos do mesmo objeto alcançados em
tempos distintos. Segundo GIARETTA (2004), a importância do
gerenciamento das versões de objetos de projeto está na
possibilidade de retornos a pontos anteriores, na busca de novas
alternativas, a fim de alcançar o objetivo traçado.
Para BALDAM (2003), controlar versões implica em:
a) Publicar somente a versão mais recente do documento em uso e
não permitir que acidentalmente as versões antigas sejam usadas;
b) Permitir que somente pessoas autorizadas acessem versões
anteriores;
c) Permitir acessar as versões para efetuar comparações entre
versões diferentes;
d) Bloquear as versões anteriores de modo que ninguém possa
alterá-las;
e) Possibilitar a criação automática de novas versões, mediante
solicitação, com codificação própria em pelo menos dois níveis;
f) Criar histórico de referências para auditoria.
Figura 6. Controle de versões
65
Usar modelos de
documentos
predefinidos
Uma maneira de agilizar a criação de novos documentos é
disponibilizar modelos prontos, também conhecidos por templates.
Estes modelos trazem a estrutura básica necessária para criação de
documentos usados com freqüência. O uso destes modelos é
conveniente pois padronizam a documentação e ajudam para que a
mesma esteja dentro dos padrões da organização.
Possuir
integração com
editores de
documentos
Interagir dados entre o ambiente do EDMS e programas de edição
de documentos é bastante útil, pois é possível associar informações
cadastradas no projeto com os modelos predefinidos, criando
documentos que já contam com bastante informação. Além disto, o
ambiente automaticamente já associa o documento ao projeto em
questão.
Gerenciar
documentos em
fase de
elaboração
É importante que o EDMS gerencie documentos também em fase
de elaboração, para evitar que o usuário tenha de criar o
documento fora do EDMS para depois adicioná-lo ao projeto. Com
isto evita-se que o usuário insira o documento no lugar errado e
que haja um arquivo na rede e um no EDMS. Em sistemas deste
tipo o ideal é que sempre o repositório seja único e confiável.
Controlar fluxos
documentais
O objetivo aqui não é ter um workflow completo dentro do EDMS,
já que isto encareceria o produto. O objetivo é simplesmente
transferir documentos seguindo roteiros definidos, encaminhando-
os de acordo com o fluxo que deveriam ter se estivessem no
formato de papel.
Suportar diversos
tipos
documentais
Armazenar os documentos no EDMS em seu formato original é
uma grande vantagem. Documentos não estruturados como slides,
planilhas, apresentações, cronogramas de projetos, páginas HTML,
vídeos, sons, entre outros, precisam ser armazenados junto com o
projeto e nada melhor que colocá-los dentro do EDMS. Mas, para
66
que seu uso seja o mais proveitoso possível, o ideal é que o EDMS
disponibilize visualizadores para todos estes tipos de arquivo.
Fazer referências
entre documentos
É comum que documentos de engenharia estejam relacionados a
outros tipos de documento, que complementam a informação
necessária ao entendimento como um todo. Por isso é interessante
que o EDMS permita fazer referências entre os documentos.
Visualizar e
imprimir CAD
com
funcionalidades
reais de projeto
Segundo (BALDAM, 2003), as seguintes situações aparecerão
com freqüência em projetos de engenharia:
a) Precisar visualizar um desenho 3D em ângulo diferente do que
foi inicialmente salvo;
b) Aparecer fontes True Type no desenho em CAD;
c) Substituir fontes que sejam usadas no desenho, mas que não
estejam disponíveis no computador;
d) Ser compatível com a última versão do software de CAD em
uso;
e) Permitir que desenhos e documentos sejam impressos com
marcas d’água controladas por software;
f) Possuir o recurso de visualizar cada layout que o arquivo
possuir. Alguns programas CAD apresentam layouts com o modelo
do projeto e com o formato de impressão, parecido com o que
acontece com Excel, em que um arquivo pode conter diversas
planilhas. O visualizador deve permitir todos os diferentes layouts.
É necessário que o fabricante do software de EDMS garanta
atualização constante do seu visualizador de CAD, pois é comum
surgirem novas versões dos programas CAD do mercado.
Controlar
revisões do tipo
A revisão tratada aqui é o desenho as-built atualizado. Para se
construir um módulo de uma refinaria, ou de outra obra de grande
67
as-buildt porte, primeiramente é feito um projeto. Acontece que ao se
executar o projeto, devido a particularidades do terreno, falta de
material especificado, condições climáticas e outros fatores, a obra
acaba não ficando exatamente do jeito como havia sido planejada.
Desta forma, a documentação não fica de acordo com o realizado.
Para resolver este tipo de dificuldade, é necessário que se faça o
as-built, para que a documentação fique atualizada com o realizado
e não com o projetado.
Como exemplo, vamos supor que a fiação elétrica estivesse
projetada para passar por uma tubulação subterrânea no lado
esquerdo da obra, mas na hora de executar o projeto, percebeu-se
que para a fiação passar por ali, uma enorme pedra teria de ser
removida. Assim, decidiu-se na hora da execução que o ideal era
que a fiação passasse pelo lado direito. Então, é necessário que se
faça o as-built para atualizar a documentação.
O mais comum é ver documentação desatualizada, ficando as
empresas que têm sua documentação atualizada como exceção.
Isto se deve ao alto custo e demora de serviços desta natureza.
Comparar
versões de CAD
para verificar
diferenças
Visualmente é difícil identificar a diferença entre duas versões de
um mesmo desenho CAD. Mas, se for utilizado uma ferramenta
que auxilie nesta tarefa, fica mais fácil. Isto é muito útil quando o
usuário precisa identificar as mudanças feitas de uma versão para
outra.
A Figura 7 ilustra esta facilidade.
68
Figura 7. Comparação entre documentos.
Suportar
desenhos com
tamanho grande
Em projetos de engenharia o tamanho do documento pode variar
bastante e o EDMS precisa suportar as diferentes dimensões. Isto é
importante principalmente na impressão.
Permitir
comentários e
marcações
Recurso que permite que as diferentes áreas troquem informações
entre si e guardem notas eletrônicas sem precisar recorrer ao papel.
Normalmente estes comentários e anotações são feitos no próprio
desenho em papel ou são feitos em cadernos especiais próprios
para isto. Mas, com o uso do EDMS é possível levar estas
anotações e comentários para dentro do projeto, com a vantagem
de evitar que as anotações se percam.
A ferramenta de marcação possibilita que os comentários sejam
feitos diretamente sobre o desenho, sem que o colaborador precise
entender de CAD. Além disto, os desenhos originais não são
alterados de fato, o que ocorre é que o desenho e as anotações
ficam isolados, apesar de aparecerem sobrepostos, dando a
impressão de serem uma coisa só. A Figura 8 ilustra este recurso.
69
Figura 8. Permitir comentários e marcações
Possibilitar
pesquisa FTR
(Full Text
Retrieval)
Full Text Retrieval é o nome dado à pesquisa que permite busca
por qualquer palavra dentro de documentos, inclusive
digitalizados. Esta pesquisa não se limita portanto a pesquisar em
índices.
A Figura 9 ilustra esta funcionalidade num software EDMS.
Figura 9. Pesquisa por diferentes critérios
70
Anexar histórico
ao documento
É comum que ambientes EDMS ofereçam a opção de anexar
histórico a revisões. Isto é muito útil para que fique registrado
quem fez alterações, a data, os motivos e outras informações mais
que forem necessárias. É possível inclusive que este histórico seja
gerado automaticamente pelo sistema.
Na Figura 10 é possível ver um histórico de alterações feitas num
documento.
Figura 10. Histórico de alterações
Criar grupos de
documentos em
separado para
execução de
tarefas
Algumas vezes é necessária a separação de um grupo de
documentos para que seja feita alguma ação neles, como por
exemplo, deixá-los separados para aprovação. Desta forma, o
trabalho fica facilitado pois apenas os documentos que devem ser
aprovados são apresentados.
Uma ferramenta de workflow resolve isto, mas sai muito caro para
um fabricante de EDMS colocar uma ferramenta dessas dentro do
seu ambiente, já que são necessárias apenas algumas
funcionalidades resolvidas pelas ferramentas de workflow. Assim,
o que ocorre na prática é o próprio fornecedor implementar estas
71
características de workflow necessárias em seu ambiente.
Gerar e receber
guias de
remessas de
documentos
Em grandes organizações é comum o uso de sistemas de protocolo,
para registrar entrada e saída de documentos. O EDMS pode
fornecer esta facilidade, gerando recibos quando houver entrada de
documentos e gerando formulários de preenchimento para saída de
documentos.
Possuir sistema
de segurança que
garanta a
integridade e
confidencialidade
dos documentos
Os EDMS armazenam as informações em bancos de dados. Para
garantir que estas informações não sejam alteradas, copiadas ou
acessadas por pessoal não autorizado, o ideal é que se use
criptografia para que os dados sejam armazenados cifrados. Isto
evita que o administrador da rede ou o administrador do banco de
dados use seus privilégios para acessar informações que não eram
para serem acessadas por ele.
Em RICHARD et al. (1999) há uma análise sobre critérios de
avaliação de segurança computacional.
Existem vários critérios de avaliação de segurança computacional
do governo americano, como indicado em Security Criteria FAQ
(DEPARTMENT OF DEFENSE STANDARD, 1985). No artigo
(RICHARD et al., 1999) os autores escolheram o Trusted
Computer System Evaluation Criteria (TCSEC) que pode ser
acessado em (FAQ, 1999).
Estes critérios podem ser usados para avaliar diferentes softwares
de EDMS.
Possuir controle
de acesso
baseado em perfil
Segundo GIARETTA (2001), a segurança de dados é aspecto
importante em qualquer sistema que possua bases de dados
compartilhadas por vários usuários. Em ambientes de engenharia,
essa importância é evidenciada pelo fato de usuários trabalharem
cooperativamente em projetos.
Perfis de usuários são criados de acordo com os tipos de usuários
72
existentes. Podemos ter como exemplo de tipos de perfis:
administradores, gerentes de equipe, engenheiros e projetistas.
Pode-se permitir a criação de perfis de usuário. Desta forma, o
administrador do sistema EDMS poderá configurar os privilégios
associados àquele perfil.
Contemplar
requisitos de
interface
Uma boa interface pode tornar o sistema mais fácil de usar e pode
melhorar sua performance (HSU & HWANG, 2004). Para avaliar
o design de um sistema WEB há uma lista de verificação proposta
por (HSU & HWANG, 2004). Esta lista de verificação foi
elaborada com base em (CHANG, 1996 apud HSU & HWANG,
2004) e na norma ISO9241
8
.
É proposto que se verifique os seguintes itens:
a) Ícones desnecessários;
b) Muitas camadas;
c) Links fracos;
d) Informação insuficiente;
e) Verificação de erros;
f) Informação de onde o usuário se encontra na navegação;
g) Balanceamento da velocidade de transmissão (de acordo
com o número de requisições);
h) Combinação da apresentação do conteúdo de acordo com a
resolução de tela usada pelo usuário.
O autor desta dissertação sugere que seja formado um grupo para
analisar estes itens acima nos softwares de EDMS que serão
avaliados, e que sejam dadas notas para cada item.
O estudo apresentado em (CHEN & HWANG, 2001) mostra que
uma boa interface nos softwares de EDMS pode melhorar a
8
ISO9241 é uma série de padrões de requisitos de ergonomia para trabalho de escritório que têm sido
estabelecidos pela International Standardization Organization (ISO).
73
performance do usuário e reduzir erros. O estudo foi feito através
de questionário com usuários, avaliação das respostas e verificação
experimental. Os resultados do experimento revelaram que uma
interface com um mapa de menu e atalho para as principais
funções melhorou significativamente a performance do usuário e
preveniu a ocorrência de erros.
Disponibilizar
acesso pela WEB
No passado, muitos EDMSs eram construídos usando-se a
arquitetura cliente-servidor. O problema da arquitetura cliente-
servidor é que o sistema fica muito pesado no lado cliente, e pelo
fato de esta arquitetura não poder prover aplicações escaláveis e
colaborativas. Estas características são desejáveis na maioria dos
planejamentos de reengenharia. Agora, usando a WEB, estes
problemas podem ser solucionados. Adicionalmente, um usuário
pode acessar os dados rapidamente e trabalhar na maioria das
plataformas existentes através da World Wide Web (HSU &
HWANG, 2004).
LIU et al. (1999) concluíram que havia certas vantagens ao se
aplicar tecnologias WEB como design rápido, integração fácil e
potencial comercial. No entanto, as desvantagens de se aplicar
tecnologia WEB também existem, como problemas de segurança,
velocidade de transferência baixa, confusão causada pelas diversas
camadas presentes em sistemas WEB, e imaturidade das
linguagens de design de interface (HSU & HWANG, 2004).
Uma grande vantagem do EDMS poder ser acessado também pela
WEB é a mobilidade para os usuários. O usuário pode acessar o
sistema de casa ou durante uma viagem.
A Figura 11 apresenta um exemplo de interface WEB.
74
Figura 11. Interface WEB de um EDMS
Garantir
continuidade e
atualização do
produto
O fabricante deve garantir a continuidade e a atualização do
produto, para evitar que o cliente compre o produto e depois fique
sem suporte ou com uma versão desatualizada.
Trabalhar com
diferentes bancos
de dados do
mercado
Os dados dos EDMSs são armazenados em banco de dados. Os
fabricantes procuram trabalhar com os bancos mais populares no
mercado como o Oracle e o SQL Server, mas há também a opção
de o fabricante oferecer um banco de dados proprietário, como
forma de reduzir o valor final do produto, já que as licenças destes
bancos mais populares costumam ser caras.
Se o EDMS for ser utilizado por 20 pessoas ao mesmo tempo, é
necessário que a organização possua 20 licenças concorrentes do
banco de dados, para que as diferentes instâncias do EDMS
possam acessar os dados.
Permitir
programação
com linguagens
não proprietárias
O software EDMS deve poder ser programável, para atender a
necessidade de mudanças. Com o passar do tempo algumas
adaptações terão de ser realizadas no software, para que ele atenda
as mudanças na organização. Para que isto seja possível, é
75
necessário que o software disponibilize recursos de programação.
Muitos softwares de EDMS são programáveis com linguagens
comuns de mercado. Este é um fator positivo pois será mais fácil
encontrar programadores que dominem a linguagem. Em
contrapartida, se a linguagem de programação for proprietária, a
organização ficará dependendo dos poucos programadores que
conhecem a linguagem.
Tabela 4. Características de um bom software de EDMS
Além de todas estas características citadas na tabela acima, deve-se destacar
também que um bom software de EDMS deve possuir suporte técnico. Quando o
usuário possui alguma dúvida, o sistema pára de funcionar, é necessário avisar para o
fabricante que a versão do visualizador CAD está desatualizada, ou ainda o usuário quer
requisitar alguma nova melhoria no software, é necessário que haja um canal entre o
fabricante e o usuário.
Muitos fornecedores possuem uma estrutura para prestar este tipo de serviço,
algumas até 24 horas por dia. Uma organização que trabalha com documentação técnica
de grande valor tem de ter certeza que poderá ser atendida quando for preciso. Para isto,
é fundamental que o fabricante da solução ou seu fornecedor no Brasil tenha um serviço
de suporte ao usuário.
Outra característica que não é exclusiva de um software de EDMS, mas que é
necessário que o fabricante do EDMS garanta, é a continuidade e atualização do
produto. Para que a organização não compre o software e depois de um tempo o mesmo
seja descontinuado.
Neste ano, 2005, a fabricante Cimage NovaSoft descontinuou o software
Novation. Este software era usado em várias refinarias da Petrobras e de uma hora para
outra elas tiveram de escolher outro software para gerenciar seus documentos técnicos,
causando prejuízo para a estatal.
Uma empresa do porte da Petrobras não pode ficar refém de um fabricante desta
maneira. Por isto é necessário que o fabricante tenha um porte mínimo, esteja há algum
76
tempo no mercado e tenha como garantir que seu produto não será descontinuado a
médio prazo.
Baseado nestas características levantadas e em conversas com engenheiros
projetistas da UN-SIX
9
, foi criada uma tabela de requisitos de software EDMS. O
formato da tabela seguiu modelo proposto em WAZLAWICK 2004, sendo que a lista de
categorias dos requisitos foi extraída desta mesma referência. Foram usadas as seguintes
categorias: usabilidade, confiabilidade, performance, configurabilidade, segurança,
implementação, interface e legais. SOMMERVILLE 2003 também foi consultado para
se fazer este levantamento de requisitos.
A coluna desejável indica se o requisito é apenas desejável ou se é obrigatório. A
coluna permanente indica se o requisito é temporário ou permanente.
Requisitos Não-Funcionais
Nome Restrição Categoria Desejável Permanente
NF1 Controle de
versão
O software deve controlar as
versões dos documentos.
Usabilidade ( ) (X)
NF2 Publicação
apenas de
documento mais
recente
Somente a versão mais
recente do sistema deve ser
publicada.
Confiabilidade ( ) (X)
NF3 Acesso
controlado a
versões
anteriores
Somente pessoas autorizadas
têm acesso à versões
anteriores dos documentos.
Segurança ( ) ( )
NF4
Comparação
entre versões
Deve ser possível comparar
diferentes versões do mesmo
documento.
Usabilidade (X) (X)
NF5 Bloqueio
de versões
Versões anteriores do
documento não podem ser
alteradas.
Confiabilidade ( ) ( )
NF6 Histórico
de versões
O software deve registrar um
histórico das versões.
Segurança (X) (X)
NF7
Disponibilização
de templates
Deve estar a disposição do
usuário, na hora da criação de
um documento, modelos
prontos.
Usabilidade (X) (X)
NF8 Integração
com editores
O software deve possuir
integração com editores de
documento para permitir que
dados sejam trocados.
Usabilidade (X) (X)
9
UN-SIX – Unidade de Negócios da Industrialização do Xisto. A Petrobras é dividida em unidades de
negócio, e a UN-SIX é uma delas.
77
NF9 Criação de
documentos
internamente
Os documentos devem poder
ser criados dentro do EDMS.
Usabilidade (X) (X)
NF10 Controle
de fluxo
O fluxo dos documentos
(workflow) deve ser
controlado pelo software.
Usabilidade (X) ( )
NF11
Armazenamento
em formato
original
Os documentos devem ser
armazenados em seu formato
original. (.html, .ppt, .doc,
.xls, .cdw, .wav, entre outros)
Usabilidade (X) ( )
NF12
Visualização de
documentos
O usuário deve poder
visualizar diferentes tipos de
documento de dentro do
software.
Usabilidade (X) ( )
NF13 Referência
entre
documentos
O usuário deve poder fazer
referências entre os
documentos
Usabilidade (X) ( )
NF14
Visualização em
ângulos
diferentes
O usuário deve poder
visualizar desenhos 3D em
ângulos diferentes
Usabilidade (X) (X)
NF15 Fontes
true type
O software deve suportar
fontes true type em desenhos
CAD.
Usabilidade ( ) ( )
NF16
Substituição de
fonte
O software deve substituir a
fonte da letra caso a mesma
não esteja disponível no
computador.
Usabilidade ( ) ( )
NF17
Visualizador de
CAD atualizado
O visualizador de CAD deve
estar sempre atualizado.
Confiabilidade ( ) (X)
NF18 Marca
d’água nos
documentos
O usuário deve poder
imprimir documentos e
desenhos com marca d’água.
Usabilidade (X) ( )
NF19 Controle
de revisões do
tipo as-buildt
O software deve controlar
revisões de maior
complexidade (as-buildt).
Usabilidade ( ) ( )
NF20
Comparação
entre versões de
documentos
O software deve oferecer
comparação de versões de um
mesmo documento. As
diferenças entre os
documentos devem ser
evidenciadas.
Usabilidade (X) (X)
NF21
Documentos de
diferentes
tamanhos
Deve ser possível trabalhar
com documentos de
diferentes tamanhos,
inclusive desenhos técnicos
de engenharia que têm grande
dimensão.
Usabilidade ( ) (X)
78
NF22 Impressão
de documentos
de diferentes
tamanhos
O usuário deve poder
imprimir documentos de
diferentes dimensões,
inclusive desenhos técnicos
de engenharia.
Usabilidade ( ) (X)
NF23 Inserção
de comentários e
anotações
O usuário deve poder fazer
comentários e anotações
diretamente nos documentos
eletrônicos, para que outros
usuários possam vê-los.
Usabilidade (X) ( )
NF24 Pesquisa
FTR
O software deve permitir que
o usuário faça pesquisa nos
documentos. Esta pesquisa
não se limita aos títulos dos
documentos, e sim a todo o
texto.
Usabilidade (X) (X)
NF25 Registro
de alterações
O software deve registrar as
alterações feitas nos
documentos. Deve ser
registrado quem fez a
alteração, a data, a hora, a
justificativa, e outras
informações mais que o
usuário julgar útil.
Segurança (X) (X)
NF26 Criação de
grupos de
documentos
O usuário deve poder criar
grupos de documentos para
execução de tarefas.
Usabilidade (X) ( )
NF27 Geração
de guias de
remessa
Guias de remessa de
documentos devem ser
geradas pelo software, para
registrar a entrada e saída dos
documentos.
Usabilidade (X) ( )
NF28
Confidencialida
de dos dados
O software deve garantir a
confidencialidade dos dados
armazenados através do uso
de criptografia.
Segurança ( ) (X)
NF29
Integridade dos
dados
O software deve garantir a
integridade dos dados através
do uso de criptografia.
Segurança ( ) (X)
NF30 Controle
de acesso
baseado em
perfil
Deve haver controle de
acesso baseado em perfil de
forma que o usuário acesse
apenas os dados a que seu
perfil tem permissão.
Segurança ( ) (X)
NF31 Criação de
novos perfis
O usuário deve poder criar
novos perfis de controle de
acesso e deve poder
configurar as permissões
destes perfis.
Configurabili-
dade
(X) (X)
79
NF32 Integração
com diferentes
bancos de dados
Deve ser possível usar banco
de dados de diferentes
fabricantes para armazenar os
dados gerenciados pelo
EDMS.
Configurabi-
lidade
(X) (X)
NF33 Software
programável
Um programador deve poder
realizar alterações no código
do EDMS para customizá-lo.
Implementação (X) (X)
NF34
Linguagem de
programação
não proprietária
A programação do software
deve poder ser feita através
de linguagem não proprietária
e que possua um bom número
de programadores no
mercado.
Implementação (X) (X)
NF35 Idioma do
software
Todas as telas e mensagens
do software devem estar no
idioma português.
Interface ( ) (X)
NF36 Interface O software deve possuir uma
interface intuitiva, leve e de
fácil navegação
Interface () (X)
NF37 Backup O software deve possuir
ferramenta de backup.
Segurança () (X)
NF38
Plataforma
Deve ser possível acessar o
software pela WEB e através
de aplicação cliente.
Implementação (X) (X)
NF39 Suporte O fornecedor ou fabricante
deve possuir estrutura de
suporte para atendimento dos
clientes por telefone e pela
Internet.
Usabilidade (X) (X)
NF40
Continuidade
O fabricante deve garantir a
continuidade do software a
médio prazo.
Legais (X) ( )
NF41
Documentação
para o usuário
Todas as funcionalidades do
software devem estar
documentadas em papel ou
através de ajuda on-line.
Usabilidade ( ) (X)
Tabela 5. Tabela de Requisitos Não-Funcionais de um software EDMS
6.2.2 Gerenciamento de Requisitos
O propósito do gerenciamento de requisitos é controlar os requisitos do software
e identificar inconsistências entre os requisitos levantados, o plano do projeto e o
software.
Para isto é necessário desenvolver um entendimento com os usuários sobre o
significado dos requisitos, para que o requisito descreva exatamente a necessidade do
80
usuário final; obter o compromisso dos participantes do projeto sobre os requisitos;
controlar mudanças nos requisitos a medida que eles forem evoluindo durante o projeto;
e identificar inconsistências entre o plano de projeto, o software e os requisitos.
6.2.3 Verificação e Validação
“Verificação e validação (V & V) é o nome dado aos processos de verificação e
análise que asseguram que o software cumpra com suas especificações e atenda às
necessidades dos clientes que estão pagando por ele. A verificação e validação
constituem um processo de ciclo de vida completo, começando com as revisões dos
requisitos e continuando com as revisões de projeto e as inspeções de código até chegar
aos testes de produto. Deve haver atividades de V & V em cada estágio do processo de
software. Essas atividades verificam se os resultados das atividades de processo estão
conforme o especificado.“ SOMMERVILLE (2003)
A diferença entre validação e verificação é que a verificação é realizada dentro
da própria equipe, junto aos colegas, com o objetivo de descobrir se os requisitos são
atendidos pelo software. Já a validação é feita fora da equipe, junto com o cliente, com a
intenção de saber se o software irá atendê-lo.
Por ser feita internamente, a verificação é mais fácil. O fato de não necessitar do
cliente torna o processo mais rápido de ser executado, principalmente no que diz
respeito a agenda.
a) Verificação
O objetivo da verificação é garantir que o software atenda aos requisitos
especificados. É necessário fazer uma preparação do que será verificado; configurar o
ambiente para a verificação; estabelecer os procedimentos e critérios para a verificação;
executar a verificação no que foi selecionado; e analisar os resultados de todas as
atividades de verificação e as ações corretivas.
81
b) Validação
A finalidade da validação é demonstrar que um produto cumpre o que foi
pretendido quando colocado no ambiente em que será usado. Para se fazer a validação é
preciso selecionar o que será validado bem como o método de validação; estabelecer e
manter o ambiente necessário para suportar a validação; estabelecer critérios e
procedimentos para validação; executar a validação no que foi selecionado; e finalmente
analisar os resultados das atividades de validação e identificar os casos onde houver
problema.
6.3 Área de Processo de Suporte
A área de processo de suporte inclui os processos e ferramentas necessários para
permitir que sejam aplicadas técnicas de decisão e medição nos projetos de maneira que
os mesmos possam ser controlados. Além disto, a área de processo de suporte inclui
atividades para garantir que o software adquirido possa sofrer a transição para uso
operacional e para mantê-lo enquanto estiver em operação.
6.3.1 Análise de Decisão
A finalidade da análise de decisão é analisar possíveis decisões usando um
processo de avaliação formal que avalia alternativas identificadas comparando com
critérios estabelecidos.
Isto é feito estabelecendo-se diretrizes para determinar quais assuntos são
importantes para um processo de avaliação formal; estabelecendo-se o critério para
avaliar alternativas e o ranking relativo deste critério; identificando-se soluções
alternativas; selecionando-se os métodos de avaliação; avaliando-se soluções
alternativas usando o critério e métodos estabelecidos; e selecionando-se soluções
alternativas baseado nos critérios de avaliação.
82
6.3.2 Análise e Medição
O objetivo da análise e medição é desenvolver uma capacidade de medição que
seja usada para suportar as necessidades de gerenciamento de informação.
Para que isto seja possível, deve-se estabelecer e manter os objetivos da
medição; especificar como os dados da medição serão obtidos e armazenados;
especificar como os dados da medição serão analisados e como será o relatório destas
medições. Após isto, deve-se obter os dados de medição especificados; analisar e
interpretar este dados; gerenciar e armazenar os dados de medição, as especificações de
medição, e análise de resultados; e, para terminar, relatar os resultados de medição e
atividades de análise para todos os stakeholders relevantes.
Armazenar as informações de medição é importante para que se tenha um
histórico do andamento do projeto.
6.3.3 Transição para Operação e Suporte
A finalidade da transição para operação e suporte é prover a transição do
software para o usuário final.
A preparação para transição consiste em estabelecer uma estratégia de transição
para operação e suporte; estabelecer planos para colocar o software adquirido em
funcionamento; estabelecer requisitos de treinamento para o pessoal que usará o
software e para os que forem prestar suporte; estabelecer requisitos de recurso para
quando o software estiver em uso e para o suporte do software; identificar e atribuir
responsabilidade na organização pelo suporte do software; estabelecer critério para
atribuir responsabilidade pelo aumento de uso do software; e estabelecer um critério de
transição para o software adquirido.
As decisões e ações a respeito da transição são executadas de acordo com o
critério de transição. Primeiramente deve-se avaliar a prontidão do software adquirido
em ser posto em uso. Logo após deve-se avaliar a prontidão dos usuários e das pessoas
que darão suporte ao software em assumir responsabilidades. Para terminar, analisar os
resultados de todas as atividades de transição e identificar ações apropriadas para cada
caso.
83
6.4 Práticas Genéricas
Práticas genéricas são práticas que devem ser adicionadas às práticas vistas até
aqui para melhorar o processo. Estão separadas pois podem ser aplicadas a qualquer
uma das três áreas de processo que vimos aqui e não apenas a uma específica. Foram
selecionadas apenas práticas que se aplicam na aquisição de software EDMS.
6.4.1 Prover recursos adequados para executar o processo, desenvolver os produtos e
prover os serviços do processo.
Esta prática genérica garante que os recursos necessários para executar o
processo como definido no plano estarão disponíveis quando forem necessários.
Recursos envolvem a verba financeira, instalações físicas apropriadas, pessoas com o
conhecimento necessário e ferramentas apropriadas.
6.4.2 Atribuir responsabilidade e autoridade para executar o processo, desenvolver o
produto, e fornecer os serviços do processo.
As pessoas escolhidas devem ter a autoridade apropriada para executar as
responsabilidades assumidas. Responsabilidades podem ser atribuídas usando
descrições de trabalho detalhadas ou através de documentos, como o plano para
executar o processo.
Atribuição dinâmica de responsabilidade é outra maneira legítima de se executar
esta prática genérica. Aqui a responsabilidade é atribuída de acordo com a necessidade e
o andamento do projeto.
6.4.3 Treinar as pessoas a executar ou suportar o processo quando necessário.
84
Esta boa prática garante que as pessoas tenham as habilidades e conhecimentos
necessários para executar ou dar suporte ao processo. Além disto, auxilia a que os
envolvidos tenham um entendimento nivelado sobre o processo.
6.4.4 Identificar e envolver os stakeholders relevantes como planejado.
O objetivo de planejar o envolvimento dos stakeholders é garantir que as
interações necessárias ao processo sejam realizadas, e ao mesmo tempo não permitir
que um excessivo número de grupos e indivíduos seja afetado, impedindo assim a
execução do processo.
6.4.5 Guardar toda a documentação e os resultados.
Esta boa prática garante que a documentação da execução de cada processo e as
lições aprendidas serão armazenadas e que este conhecimento será usado em novos
projetos ou para melhorar a execução de um projeto existente.
85
7. APLICAÇÃO E DISCUSSÃO
O Gerenciamento Eletrônico de Documentos Técnicos auxilia muito o trabalho
dos projetistas, desenhistas e engenheiros e cada vez mais serão desenvolvidas
tecnologias que permitirão que esta ajuda seja cada vez maior. A tendência é que muitas
das funções de um projetista, desenhista ou engenheiro sejam realizadas pelo
computador, ficando este usuário com mais tempo para realizar as tarefas que exigem
um maior conhecimento.
Através de vários estudos, o processo de aquisição de software está se
desenvolvendo. Realizar uma aquisição de software sem o uso deste conhecimento pode
resultar na aquisição de um software que não atenda às necessidades do cliente, o
contrato entre a organização e o fornecedor pode não abranger tudo que é necessário
que seja coberto, os prazos podem se estender além do previsto, os riscos podem não ser
monitorados e muitos outros problemas podem ocorrer. Portanto, é necessário que se
pesquise cada vez mais sobre este assunto e que as organizações usem estas
informações para melhorar seus processos de aquisição de software.
A tendência cada vez maior de as grandes organizações começarem a usar este
tipo de software e a complexidade que é adquirir um software desta grandeza,
motivaram o autor a escrever este guia. A grande utilidade do guia está no levantamento
dos requisitos, que permitirá aos responsáveis pela aquisição ter uma lista de
características que o software deve possuir. Muitas vezes estas pessoas responsáveis
pela aquisição são pessoas dedicadas a este tipo de atividade e não conhecem a fundo o
funcionamento de softwares como este. Outras vezes estes responsáveis até são os
engenheiros que trabalharão com o software e têm todo o conhecimento sobre o
funcionamento do software, mas falta-lhes tempo para dedicar a esta tarefa. Nestes
casos, um guia como este desenvolvido neste trabalho tem grande valia.
Os requisitos levantados foram todos requisitos não funcionais que descrevem
de maneira geral como o software deve funcionar. Estes requisitos, apesar de estarem
em pequeno número, cobrem as principais características que um software deste tipo
deve possuir. Se o objetivo fosse levantar todos os requisitos funcionais de um software
complexo como este, seria necessário uma grande equipe e muito esforço. E vale
86
ressaltar que uma lista com os requisitos detalhados do software não teria tanta utilidade
para a equipe de aquisição quanto esta lista de requisitos de mais alto nível.
Para as organizações que desejarem adquirir outro software que não EDMS, há
alguns modelos de aquisição de software que podem orientá-las na hora da aquisição.
Mas, o ideal é que se escolha apenas um modelo e o siga do início ao fim, adaptando-o
às particularidades da organização e do software que está sendo adquirido. Neste
trabalho optou-se por basear-se em CMMI (BERNARD et. Al., 2005).
7.1 Estudo de Caso
O autor desta dissertação participou da aquisição de um software de EDMS para
uma Unidade de Negócios de uma empresa estatal brasileira e pôde comprovar a
dificuldade que é gerenciar todo o processo de aquisição de um software desta natureza.
Inclusive isto serviu de motivação para escrever o guia. Esta aquisição foi feita antes
deste guia e, portanto, o guia não pôde ser utilizado. Por isto, serão destacadas aqui
atividades que deram errado, mas que poderiam ter dado certo caso o guia já existisse e
tivesse sido utilizado.
Em outras Unidades de Negócio da mesma estatal este processo de aquisição foi
repetido e muitos dos problemas enfrentados pelo autor desta dissertação também foram
enfrentados por outras equipes.
87
O que deu errado na aquisição Por que poderia dar certo com o guia
Quando o software chegou, não havia
ainda hardware disponível para hospedá-
lo.
Ao se fazer o plano de projeto deve-se
estimar datas. Com esta estimativa ficaria
evidente a necessidade de se
disponibilizar hardware antes de o
software chegar.
Após a chegada do software houve um
impasse sobre os custos. Não havia ficado
claro quem deveria pagar o software, se
era a Engenharia, a TI, a Unidade como
um todo, ou se deveria ser feita uma
espécie de rateio entre as partes.
No plano de projeto são estabelecidos os
compromissos de cada stakeholder.
Está em estudo na companhia a
padronização dos softwares de GED e
talvez o software adquirido tenha de ser
substituído. Se isto vier a ocorrer,
resultará na perda do investimento.
No Guia há o gerenciamento de riscos. Se
na época houvesse o guia e ele fosse
seguido, haveria a chance de que esta
padronização tivesse sido imaginada e
classificada como um risco.
O processo de aquisição atrasou um
pouco.
Ao se fazer o Monitoramento e Controle
do Projeto fica mais fácil identificar os
atrasos e, se for o caso, ações podem ser
tomadas.
Como a TI é que fez a aquisição do
software, mesmo após o software ter sido
passado para a Engenharia sempre que há
algum problema com o software ou
alguma situação junto ao fornecedor
precisa ser resolvida, a TI é acionada.
No guia há a Transição para Operação e
Suporte que tem a finalidade de formalizar
a entrega do software adquirido para o
usuário final. Assim, é o usuário final que
terá de resolver questões ligadas ao
software e não a equipe que o adquiriu.
88
Ocorreram algumas vezes de o fornecedor
falar com duas pessoas da equipe de
aquisição sobre um mesmo problema e as
informações dadas por estas pessoas terem
sido diferentes.
O guia sugere como prática genérica que
sejam atribuídas responsabilidade e
autoridade para cada atividade. Assim,
sempre haverá um responsável por
determinada atividade e ele é que deverá
ser acionado.
Tabela 6. Erros que poderiam ter sido evitados se o guia tivesse sido usado
Apesar dos vários problemas relatados, de maneira geral pode-se dizer que a
aquisição deu certo. Isto deve-se principalmente ao fato de que foi montada um equipe
para esta aquisição, que o cliente final foi escutado, que as pessoas envolvidas
receberam o treinamento adequado, que bastante esforço foi destinado para esta
aquisição, que outras Unidades que usam o software adquirido foram ouvidas e que os
principais stakeholders foram envolvidos no projeto.
Apesar de a equipe de aquisição na época não saber da existência de modelos de
aquisição de software como os estudados nesta dissertação, conhecia um pouco da
teoria sobre gerenciamento de projetos e por isto conseguiu realizar bem a aquisição já
que a aquisição de um software pode ser vista como um projeto. Muitas das práticas
recomendadas pela teoria de Gerenciamento de Projetos, são recomendadas também na
teoria de Aquisição de Software.
89
8. CONCLUSÕES E RECOMENDAÇÕES
Neste trabalho foi elaborado um guia para aquisição de software de
Gerenciamento Eletrônico de Documentos Técnicos. A principal qualidade deste guia é
ter levantado os requisitos mais importantes de um software EDMS. Isto é útil para as
organizações que precisam adquirir um software deste tipo, seja por licitação ou compra
direta. É útil já que o processo de aquisição de softwares grandes é difícil de ser
executado sem problemas; softwares do tipo EDMS possuem uma série de
particularidades e especificidades que tornam o processo todo bastante complexo; e não
existe nenhum guia como este que foi desenvolvido neste trabalho.
Analisando os objetivos específicos pode-se dizer que estes foram alcançados:
a) Foram listadas as principais características de um EDMS. Este levantamento
foi feito através de estudo da literatura e conversas com consultores, usuários e
fornecedores deste tipo de software. Este trabalho teria de ser realizado por alguém que
precisasse adquirir este tipo de software através de licitação para uma organização
governamental.
b) Foi feita uma discussão sobre um estudo de caso de aquisição de um software
EDMS numa empresa estatal brasileira. O autor desta dissertação participou como
responsável por esta aquisição. Foram listadas as dificuldades e erros cometidos durante
o processo e como este guia que está sendo proposto neste trabalho poderia ter auxiliado
no sentido de ter evitado os erros cometidos. Para cada erro cometido foi associado o
item do guia que tratava do assunto.
8.1 Trabalhos Futuros
Para trabalhos futuros, são listadas a seguir algumas sugestões:
a) Fazer um estudo comparativo com os diferentes softwares de EDMS,
apontando quais são os melhores para os diferentes tipos de organização;
90
b) Levantar todos os requisitos de um software de EDMS. Este levantamento
será útil para as organizações que desejarem desenvolver softwares desta natureza.
91
9. REFERÊNCIAS
ALVES, Ângela Maria. Contratação de produtos e serviços de software. Campinas,
2002. Trabalho Final (Mestrado Profissional). Faculdade de Engenharia Mecânica,
Universidade Estadual de Campinas.
AVEDON, Don M. GED de A a Z. Tudo sobre GED – Gerenciamento Eletrônico
de Documentos. São Paulo: CENADEM, 1999
BALDAM, R.; VALLE R.; CAVALCANTI M. GED – Gerenciamento Eletrônico de
Documentos. São Paulo: Érica, 2002.
BALDAM, Roquemar de Lima. Gerenciamento eletrônico de documentos técnicos
em departamentos de engenharia de projeto e manutenção do setor siderúrgico.
Rio de Janeiro, 2003. Dissertação (Mestrado) Engenharia de Produção, Universidade
Federal do Rio de Janeiro.
BERNARD, Tom; GALLAGHER, Brian; BATE, Roger; WILSON, Hal. CMMI
Acquisition Module (CMMI-AM), Version 1.1. Pittsburgh, Pa: Software Engineering
Institute, Carnegie Mellon University, 2005.
CÂNDIDO, Gesinaldo Ataíde; ARAÚJO, Nadja Macedo de. As tecnologias de
informação como instrumento de viabilização da gestão do conhecimento através da
montagem de mapas cognitivos. Ci. Inf., Brasília, v.32, n. 3, p. 38-45, set/dez. 2003
CENADEM. Guia brasileiro de software para GED – Gerenciamento Eletrônico
de Documentos e Content Management. São Paulo: Cenadem, 2002.
CENADEM. O GED. Disponível em < http://www.cenadem.com.br/>. Acessado em
19 jun. 2005.
CHEN, Jessica ; HWANG, Sheue-Ling. Interface design guidelines for an engineering
data management system. Asian Journal of Ergonomics, v.2, n.2, p.117-138, 2001.
CICCONE, Roberto. Gerenciamento do conhecimento utilizando ferramentas
digitais. Rio de Janeiro, 2002. Monografia. Curso MBI em Sistemas de Negócios
Digitais Integrados, Universidade Federal do Rio de Janeiro.
COCKBURN, A. Balancing lightness with sufficiency. Cutter IT Journal 13(11)
2000: 26-33.
92
DEPARTMENT OF DEFENSE STANDARD. DOD 5200.28-STD: Department of
defense trusted computer system evaluation criteria. USA, 1985. Disponível em:
<http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.html> Acesso em: 13
out. 2005.
DUTRA, Ângelo Leão. Uma metodologia para a implantação de Sistemas de
gerenciamento eletrônico de documentos baseado na experiência de Rondônia
Santa Catarina, 2001 Dissertação (Mestrado) pós-graduação em Ciência da
Computação, Universidade Federal Santa Catarina.
FANTINI, Sérgio Rubens. Aplicação do Gerenciamento Eletrônico de Documentos:
Estudo de caso de escolha de soluções Santa Catarina, 2001. Dissertação (Mestrado)
PPGEP, Universidade Federal de Santa Catarina.
FAQ. The Computer Security Evaluation Frequently Asked Questions. 1999.
Disponível em: http://www.radium.ncsc.mil//tpep/process/faq.html. Acesso em: 19 out
2005.
FARBEY, B.; FINKELSTEIN, A. Software Acuisition: A Business Strategy Analysis.
In Proceedings of the Fifth IEEE international Symposium on Requirements
Engineering (RE ‘01) (August 27 – 31, 2001). RE. IEEE Computer Society,
Washington, DC, 76.
GALLAGHER, Brian P.; SHRUM, Sandy. Applying CMMI to Systems Acquisition.
CrossTalk 17, 8 (August, 2004): 8-12.
GARTNER GROUP. Disponível em <http://www.gartner.com>. Acessado em 12 out
2005.
GIARETTA, Joacir. GerDoc Ábacus – Um sistema de Gerenciamento Eletrônico de
Documentos Técnicos para Ambientes de Engenharia/ CAD In: SBC 2004
SEMISH, 2004, Salvador. Anais. Salvador , 2004.
GIARETTA, Joacir. Gerenciamento de Documentação Técnica para Ambientes de
Engenharia/CAD com Suporte a Versões. Porto Alegre, 2001. Dissertação
(Mestrado) Ciência da Computação PPGC, Universidade Federal do Rio Grande do
Sul.
GINGRANDE, Arthur. Introduction to document management. AIIM E – Doc
Magazine, p. 21, Mar./Apr. 2003.
HSM. A gestão do conhecimento na prática. HSM Management, n 42, jan-fev, 2004
HSU, Ching-Chih; HWANG, Sheue-Ling. A study of interface design improvement in
an engineering data management system on the world wide web. Computers &
Industrial Engineering, v.47, Issue 1, p. 31-43 Aug. 2004.
93
IBRAHIM, Linda, et al., “The Federal Aviation Administration Integrated Capability
Maturity Model, (FAA-Icmm), versão 2.0” Setembro, 2001.
KINGSTON, John. Conducting feasibility studies for knowledge based systems.
Knowledge-Based Systems, v. 17, p.157-164. May 2004.
LINDVALL, Mikael; RUS, Ioana; SINHA, Sachin Suman. Software systems support
for knowledge management. Journal of Knowledge Management, v. 7, n. 5, p. 137-
150, 2003.
LIU, T.-H., HWANG, S.-L., & WANG, J.-C. A computerized calibration service
supporting system. II. A web interface design. International Journal of Computer
Applications in Technology, v.12, n.1, p. 60-70, 1999.
LOPES, Uberdan dos Santos. Arquivos e a organização da gestão documental. Revista
ACB, v. 9, n. 1, 2004.
PAIVA JUNIOR, Edson Ribeiro. Proposta de um plano de ação em gestão do
conhecimento para departamentos de tecnologia da informação: Estudo de caso.
Santa Catarina, 2003. Dissertação (Mestrado). Programa de Pós-Graduação em
Engenharia de Produção, Universidade Federal de Santa Catarina.
RAYNES, Michael. Document Management: is the time now right? Work Study, v.
51, n.6/7, p. 303-308, 2002
REZENDE, Yara. Informação para negócios: os novos agentes do conhecimento e a
gestão do capital intelectual. Ci. Inf., Brasília, v.31, n. 2, p. 120-128, maio/ago. 2002
REZGUI, Yacine. Review of information and the state of the art of knowledge
management practices in the construction industry. The Knowledge Engineering
Review , Cambridge , v.16, n.3, p.241-254, 2001
RICHARD, J. S.; RAHMAN, M. H.; THOMAS, S. M. Design issues for a Trusted
Eletronic Document Management System. In: IEEE CANDADIAN CONFERENCE
ON ELECTRICAL AND COMPUTER ENGINEERING SHOW CONFERENCE
CENTER, v.1, 1999. Proceedings …. Edmonton: IEEE, 1999. p.. 373- 378
ROSINI, Alessandro Marco; PALMISANO, Ângelo. Administração de sistemas de
informação e a gestão do conhecimento. São Paulo: Pioneira Thomson Learning,
2003.
ROSSATO, Maria Antonieta.(a) Gestão do Conhecimento: a busca da
humanização, transparência, socialização e valorização do intangível. Rio de
Janeiro: Interciência, 2002.
94
ROSSATTO, Maria Antonieta.(b) Uma proposta de modelo de gestão do
conhecimento. Rio de Janeiro, 2002. Tese (Doutorado) Programa de Pós – Graduação
em Engenharia,Universidade Federal Rio de Janeiro.
ROSSATTO, Maria Antonieta.(c) Uma nova estratégia tecnológica voltada para a
Gestão do Conhecimento. Anais Infoimagem, 2002
SANTIAGO, Márcio André Lima. Investigação sobre a eficácia do gerenciamento
eletrônico de documentos : GED nas organizações. Monografia – Curso de
Especialização-MBA em Administração e Sistemas de Informações da UFF.
Niterói : Universidade Federal Fluminense, 2004.
SEI, Software Engineering Institute. CMMI and Acquisition Frequently Asked
Questions. Disponível em: http://www.sei.cmu.edu/cmmi/faq/acq-faq.html#Q178.
2005
SILVA, Ricardo Vidigal da; NEVES, Ana. Gestão de empresas na era do
conhecimento. São Paulo: Serinews, 2003.
SILVA, Sérgio Luis da. Informação e competitividade: a contextualização da gestão do
conhecimento nos processos organizacionais. Ci. Inf., Brasília, v. 31, n. 2, p. 142-151,
maio/ago. 2002.
SILVA, Sérgio Luiz da . Gestão do Conhecimento: uma revisão crítica orientada pela
abordagem da criação do conhecimento. Ci. Inf., Brasília, v.33, n. 2, p. 143-151,
maio/ago. 2004.
SOFTWARE ENGINEERING INSTITUTE, “Software Acquisition Capability
Maturity Model”, (SA-CMM), versão 1.03” Março, 2002
SOFTWARE ENGINEERING STANDARDS COMMITTEE OF THE IEEE
COMPUTER SOCIETY. IEEE Std. 830-1998: recommended practice for software
requirements specifications. New York, 1998.
SOFTWARE ENGINEERING STANDARDS COMMITTEE OF THE IEEE
COMPUTER SOCIETY. IEEE Std. 1062-1998: recommended practice for software
acquisition. New York, 1998.
SOMMERVILLE, Ian. Engenharia de Software / Ian Sommerville. São Paulo:
Addison Wesley, 2003.
TEIXEIRA FILHO, Jayme. Gerenciando Conhecimento Rio de Janeiro: SENAC,
2000. 192 p.
95
THE COMPUTER Security Evaluation Frequently Asked Questions. Disponível
em <http://www.radium.ncsc.mil/tpep/process/faq.html>. Acessado em 13 out. 2005
ULKUNIEMI, Pauliina; SEPPÄNEN, Veikko. Definition of a COTS Software
Component Acquisition Process Framework: The Case of a Telecommunications
Company, 28
th
Euromicro Conference, September 4-6, 2002, Dortmund, Germany,
Proceedings, Ed. Fernandez, M, pp. 48-54.
VALLE, Rogério B. A.; BALDAM, Roquemar de L. EDMS: Como montar um projeto
viável. In: CONGRESSO ANUAL DA SOCIEDADE BRASILEIRA DE GESTÃO
DO CONHECIMENTO, 1. 2002, São Paulo. Anais... São Paulo, 2002. p.26901-26916.
VARAJÃO, J. E. Q.; AMARAL, L. A. M. Contributo para o desenvolvimento de um
sistema de procurement. Informação & Informática (2001:26), 2001, pp. 17-32
WAZLAWICK, Raul Sidnei. Análise e projeto de sistemas de informação
orientados a objetos. Rio de Janeiro: Elsevier, 2004.
96
ANEXOS
Anexo I - Softwares de EDMS no mercado brasileiro
Aqui serão listados a maioria dos softwares de EDMS que possuem fornecedores
no Brasil e que possuem versão em português.
Para se chegar nesta lista de softwares, foram usados os seguintes recursos:
a) Consulta ao Guia brasileiro de software para GED (CENADEM, 2002);
b) Pesquisa através de ferramentas de busca na Internet.
a) Consulta ao Guia brasileiro de software para GED.
O Guia brasileiro de software para GED é o resultado de uma pesquisa
executada pelo CENADEM – Centro Nacional de Desenvolvimento do Gerenciamento
da Informação – com todos os softwares para GED existentes no país e que estão
cadastrados no banco de dados do CENADEM.
Ao todo o guia apresenta 60 softwares para GED. Mas, conforme já explicado
nesta dissertação, o EDMS é um tipo de gerenciador eletrônico de documentos e nem
todos os softwares de GED apresentam as funcionalidades necessárias para o
gerenciamento de documentação técnica. Desta forma, nem todos os softwares presentes
no guia serão avaliados nesta dissertação.
Uma grande vantagem de usar este guia para a pesquisa é que ele traz
informações sobre quem respondeu a pesquisa e sobre o revendedor. Desta forma, é
fácil entrar em contato, caso necessário.
b) Pesquisa através de ferramentas de busca na Internet
Usando ferramentas de busca na Internet como o Google, o Yahoo! e o Cadê?,
pesquisas foram feitas com a intenção de verificar se há mais algum software de EDMS
que atende aos requisitos de possuir fornecedor no Brasil e estar em português, mas que
não está presente no guia do CENADEM.
97
Após estes passos, chegou-se a esta lista de softwares de EDMS:
Nome do Software Fabricante Fornecedor(es)
Active PDF Server Active PDF PDF Brasil
Adobe Acrobat Adobe Systems PDF Brasil
Alchemy Premium IMR Power Imaging
Ascent Capture Kofax Metron
Interconect
AutoEDMS ACS Software Akron
AutoManager Meridian Cyco GAMA
SKA
Pontodoc
AutoManager TeamWork Cyco SKA
Pontodoc
Bscan Capture Image Access Interconect
Docman Suite BKM Sistemas BKM
Docs Open Hummingbird Politec
DocSpider Impacto Tecnologias Impacto Tecnologias
Documentum 4i Documentum Xerox
Soluziona
Docuware DocuWare Corp. Docuware
FlyPaper Image Technology Imagetec
Folder245 Content
Management
Lab245 Lab245
Folder245Flow Lab245 Lab245
Galileo SIAV SIAV
Golden Track Light Infocon
Tecnologia
Light Infocon
IBM Content Manager IBM IBM
Image Controls Kofax Metron
Isodoc Softexpert Softexpert
98
IXOS-Econ IXOS Software DBA
Livelink Intranet Open Text Corp.
Metaviewer Enterprise Metafile Scanning
NDDigital ERM Tortelli NDDigital NDDigital
Panagon IDM FileNET Soluziona
Poliflow Poliedro Poliedro
ProjectWise Bentley Systems Bentley Systems
SiteScape Enterprise Forum SiteScape Inc. Multidoc
Staffware Staffware Politec
Vincent SIAV SIAV Brasil
Webdesk Datasul Datasul
WI-Viewer Work Image Work Image
Win Document Win Master Win Máster
Tabela 7. Lista de softwares de EDMS que estão no mercado brasileiro
Para cada fornecedor desta lista, foram levantadas as seguintes informações:
a) Endereço WEB
b) E-mail
c) Telefone
d) Nome de uma pessoa para contato
e) E-mail deste contato
f) Telefone deste contato
Estas informações constam no Guia brasileiro de software para GED. Muitas
delas tiveram de ser atualizadas via telefone ou sítio na Internet.
99
Fornecedor
Endereço WEB / E-mail / Telefone Contato / E-mail contato /
Telefone Contato
Akron www.akron.com.br
[email protected]
(31) 3291-6800
Newton Amaro de Oliveira Jr.
[email protected]
(31) 3291-6800
Bentley
Systems
www.bentley.com.br
[email protected]
(11) 5181-2666
Rogério Duarte
[email protected]
(11) 5181-2666
BKM www.bkm.com.br
[email protected]
(31) 3284-2899
Haroldo Meirelles Vieira
[email protected]
(31) 3284-2899
Datasul www.datasul.com.br
[email protected]
(47) 441-7000 Ram 7282
Gilmar Valério Hansen
[email protected]
(47) 441-7000 Ram 7282
DBA www.dba.com.br
[email protected]
(21) 2515-3222
Aníbal Oliveira
[email protected]
(11) 3875-6772
Docuware www.docuware.com
[email protected]
(19) 3253-2451
Aécio Luiz P. de Souza
[email protected]
(19) 3253-2451
Gama www.gama.inf.br
[email protected]
(51) 579 9000
Gerson Fioravante
[email protected]
(51) 579 9000
IBM www.ibm.com.br
[email protected]
(11) 3050-3996
Rogério Inomata
[email protected]
(11) 3050-3996
Imagetec www.imagetec.com.br
[email protected]
(11) 3846-3190
Roberto Hart
[email protected]
(11) 3846-3190
Impacto
Tecnologias
www.impacto.tecnologias.com.br
[email protected]
(47) 454-5050
Luciano Stein
[email protected]
(47) 454-5050
100
Interconect www.bscan.com.br
[email protected]
(11) 3061-2520
Jarbas P. Beznos
[email protected]
(11) 3061-2520
Lab245 www.lab245.com
[email protected]
(21) 3084-0245
Maria Luiza Reis
[email protected]
(21) 3084-0245
Light
Infocon
www.lightinfocon.com.br
[email protected]
(83) 333-1904
Alexandre J. Beltrão Moura
[email protected]
(83) 333-1904
Metron www.metron.com.br
[email protected]
(11) 5548-7644
Rodrigo Ramos Paschoito
[email protected]
(11) 5548-7644
Multidoc www.multidoc.com.br
[email protected]
(19) 3233-6123
Silvia Fujino
[email protected]
(19) 3233-6123
NDDigital www.tortelli.com.br
[email protected]
(49) 221-2700
Jean Rodolfo Taruhn
[email protected]
(49) 221-2700
PDF Brasil www.pdf.com.br
[email protected]
(11) 5052-7588
Luiz Augusto
[email protected]
(11) 9169-0075
Poliedro www.poliedro.com.br
[email protected]
(61) 443-7700
Antonio Dantas
[email protected]
(61) 443-7700
Politec www.politec.com.br
[email protected]
(61) 3038-6800 ram. 6814
Suely Sanches
[email protected]
(61) 3038-6800 ram. 6814
Pontodoc www.pdoc.com.br
[email protected]
(11) 4437-1727
Macia Fonatanello
[email protected]
(11) 4437-1727
101
Power
Imaging
www.powerbrasil.com.br
[email protected]
(51) 3337-0061
Júlio Rossi
[email protected]
(51) 3337-0061
Scanning www.scanning.com.br
[email protected]
(11) 3266-4432
Sebastião Alves dos Santos
[email protected]
(11) 3266-4432
SIAV
Brasil
www.siav.com.br
[email protected]
(11) 3167-6995
Carlos Eduardo Rizk
[email protected]
(11) 3167-6995
SKA www.ska.com.br
[email protected]
(51) 5912-900 ram. 939
Fábio O. da Silva
[email protected]
(51) 5912-900 ram. 939
Softexpert www.softexpert.com
[email protected]
(47) 422-3933
Patrícia Souza Vieira
[email protected]
(47) 422-3933 ram. 204
Soluziona www.soluziona.com
[email protected]
(11) 3094-3200
Orlando Rodrigues
[email protected]
(11) 3094-3355
Win Máster www.winmaster.com.br
[email protected]
(21) 2252-9433 / 2508-7218
Henrique Fernandez
[email protected]
(21) 2252-9433 / 2508-7218
Work
Image
www.workimage.com.br
[email protected]
(11) 3661-7732
Moacir Augusto C. de Souza
[email protected]
(11) 3661-7732
Xerox www.xerox.com.br
[email protected]
(21) 2271-1366
César Cunha de Souza
[email protected]
(21) 2271-1026
Tabela 8. Contato dos fornecedores de EDMS
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo