Prof. Me. Marcos Danilo Chiodi Martins - UniSEB

UniSEB COC 

TRABALHO DE CONCLUSÃO DE CURSO - QUALIFICAÇÃO 

BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO 

TRABALHO DE CONCLUSÃO DE CURSO: 

GESTÃO DO CONHECIMENTO – UMA PROPOSTA DE 

UM BA VIRTUAL MULTIPLATAFORMA 

Aluno: Otávio Luiz Leite 

Orientador: Prof. Me. Marcos Danilo Chiodi Martins 

RIBEIRÃO PRETO 

2011

Otávio Luiz Leite 

TRABALHO DE CONCLUSÃO DE CURSO: 

GESTÃO DO CONHECIMENTO – UMA PROPOSTA DE 

UM BA VIRTUAL MULTIPLATAFORMA 

Trabalho de conclusão de curso apresentado ao UniSEB 

COC de Ribeirão Preto, no Curso de Ciência da 

Computação, como parte dos requisitos para obtenção do 

grau de Bacharel em Ciências da Computação. 

Orientador: Prof. Me. Marcos Danilo Chiodi Martins 

RIBEIRÃO PRETO 

2011

L525g 

Leite, Otávio Luiz 

Ficha Catalográfica 

Gestão do conhecimento - uma proposta de um BA virtual 

multiplataforma - Ribeirão Preto, 2011. 

72 f., il.. 

Orientador: Prof. Me. Marcos Danilo Chiodi Martins. 

Trabalho de conclusão de curso apresentado ao Centro Universitário 

UNISEB de Ribeirão Preto, como parte dos requisitos para obtenção do 

Grau de Bacharel em Ciência da Computação sob a orientação do Prof. 

Me. Marcos Danilo Chiodi Martins. 

1. Gestão do conhecimento. 2. Informação 3. Inteligência Organizacional. 

I. Título. II. Martins , Marcos Danilo Chiodi. 

CDD 658.3 

iii

TRABALHO DE CONCLUSÃO DE CURSO 


Aluno: Otávio Luiz Leite 

Código: 6104 

Curso: Ciência da Computação 

Semestre/Ano: 8º/2011 

Tema: Gestão do Conhecimento – Uma Proposta de um Ba Virtual Multiplataforma 

Objetivos pretendidos: Propor uma ferramenta multiplataforma para gestão do conhecimento 

em uma organização pública. 

_____ /_____ /________ _________________________________________ 

Prof. Me. Marcos Danilo Chiodi Martins 

Professor 

_____ /_____ /________ _________________________________________ 

Otávio Luiz Leite 

Aluno 

_____ /_____ /________ _________________________________________ 

Prof. Me. Paulo César de Carvalho Dias 

Coordenador 

_____ /_____ /________ _________________________________________ 

Prof. Reginaldo Arthus 

Vice-Reitor 

iv


FORMULÁRIO DE AVALIAÇÃO – FATCC 

Tema do trabalho: Gestão do Conhecimento – Uma Proposta de um Ba Virtual 

Multiplataforma. 

Data da apresentação: _____ /_____ /________ 

Horário: ____________ 

Local: _____________________________________________________________________ 

Comissão Julgadora: 

1) Professor Orientador: ______________________________________________________ 

2) Professor da Área: _________________________________________________________ 

3) Professor Convidado: ______________________________________________________ 

v

Folha de pontuação 

Fatores de avaliação Pontuação (0.0 a 2.0) 

1. Atualidade e relevância do tema proposto. 

2. Linguagem técnica utilizada em relação ao tema e aos 

objetivos, e competência lingüística. 

3. Aspectos metodológicos e formais da editoração do 

trabalho escrito - seqüência lógica e coerência interna. 

4. Revisão Bibliográfica realizada em relação ao tema 

pesquisado. 

5. Apresentação oral – segurança e coerência em 

relação ao trabalho escrito. 

Média: _______________ ( _________________________________________________ ) 

Assinaturas dos membros da Comissão Julgadora: 

1) _____ /_____ /________ ____________________________________________________ 

2) _____ /_____ /________ ____________________________________________________ 

3) _____ /_____ /________ ____________________________________________________ 

vi

Dedicatória 

vii 

À minha família.

AGRADECIMENTOS 

Não poderia deixar de agradecer, além do meu orientador Marcos Danilo Chiodi Martins, 

estas pessoas, que tiveram influência decisiva nesta minha trajetória acadêmica: 

Carlos Henrique Odenique Jardim (Linguagem e Laboratório de Programação, Estrutura de 

Dados, Ordenação e Pesquisa de Dados, Paradigmas de Programação II, Análise e Projeto 

de Sistemas, Teoria da Computação e Linguagens Formais, Compiladores e Sistemas 

Operacionais II) 

Celso Luiz Franzotti (Física para Computação I e II) 

Daniel Lobato (Estrutura de Dados) 

Daniel Pires (Paradigmas de Programação I e Teoria dos Grafos e Aplicações) 

Elaine Risques (Estudo Técnico da Língua Inglesa I e II) 

Henrique Fabricio Gagliardi (Tecnologias Web e Programação para Dispositivos Móveis) 

Iara Santiago (Redação e Interpretação de Textos I e II) 

Janaina Cintra Abib (Algoritmos e Programação de Computadores e Modelagem de Sistemas) 

Jean-Jacques Georges Soares De Groote (Cálculo Diferencial e Integral Aplicado I e II) 

Luciana Tarlá (Princípios de Lógica e Matemática Discreta) 

Lucio Andre de Castro Jorge (Inteligência Computacional, Processamento Digital de Imagem, 

Computação Gráfica e Realidade Virtual, Programação Concorrente e Tópicos de 

Inteligência Artificial) 

Mara Cristina Castelli (Metodologia Científica e Empreendedorismo e Novos Negócios) 

Marcos Danilo Chiodi Martins (Engenharia de Software I e II) 

Neide Maria Bertoldi Franco (Geometria Analítica, Álgebra Linear e Métodos Numéricos) 

Patrícia Magna (Arquitetura de Computadores I e II, Organização de Computadores e Trabalho de 

Conclusão de Curso I) 

Paulo César de Carvalho Dias (Circuitos e Sistemas Digitais, Microprocessadores e 

Microcontroladores, Sistemas Operacionais I, Estágio Supervisionado I e II, Redes de 

Computadores I e II e Segurança de Redes) 

Reginaldo Aparecido Gotardo (Banco de Dados I e II, Complexidade e Técnicas Avançadas de 

Algoritmos, Interação entre Usuário e Computador e Informática e Sociedade) 

Ricardo A. Coppola Germanos (Sistemas Distribuídos e Trabalho de Conclusão de Curso II) 

Thiago Wellington J. de Almeida (Extração e Análise de Conhecimentos em Banco de Dados) 

Wagner Aparecido Cavali (Probabilidade e Estatística e Processos Estocásticos) 

viii

A grande finalidade do conhecimento 

ix 

não é conhecer, mas agir. 

Thomas Henry Huxley

LEITE, Otávio Luiz. Gestão do Conhecimento – Uma Proposta de um Ba Virtual 

Multiplataforma. Trabalho de Conclusão de Curso. Curso de Ciência da Computação. 

Centro Universitário UNISEB. Ribeirão Preto, 2011. 72 f. 

RESUMO 

Em virtude da multiplicidade de informação e de suas inúmeras fontes, a gestão do 

conhecimento tem sido tema recorrente na atual sociedade, seja no primeiro (governamental), 

segundo (privado) ou terceiro setor (entidades sem fins lucrativos ligadas a filantropia). Dada 

esta relevância, este trabalho teve como objetivo pesquisar a utilização de ferramental 

destinado a este contexto. Neste estudo, a escolha foi direcionada para as tecnologias web. 

Além do baixo investimento, tais tecnologias tem outro importante atrativo: a fácil assimilação. 

Além de avaliar o contexto de uma instituição pública, identificando uma determinada 

necessidade, foi proposta uma ferramenta que terá a finalidade de atuar como um Ba virtual 

para gerenciamento de um processo, além de todo o conhecimento neste gerado. 

Palavras chaves: gestão do conhecimento, informação, inteligência organizacional. 

x

LEITE, Otávio Luiz. Gestão do Conhecimento – Uma Proposta de um Ba Virtual 

Multiplataforma. Trabalho de Conclusão de Curso. Curso de Ciência da Computação. 

Centro Universitário UNISEB. Ribeirão Preto, 2011. 72 f. 

ABSTRACT 

Due to the multiplicity of information and its numerous sources, knowledge management has 

been a recurring theme in present society, is in the first (governmental), second (private) or 

third sector (non-profit entities linked to Philanthropy). Given this relevance, this work was 

aimed at researching the use of tooling for this context. In this study, the choice was directed to 

web technologies. In addition to the low investment, such technology has another important 

attractive: a good usability. Besides evaluating the context of a public institution, identifying a 

particular need, was proposed a tool designed to act as a virtual Ba to manage a process, as well 

as all the knowledge generated from this tool. 

Keywords: knowledge management, information, organizational intelligence. 

xi

LISTA DE IMAGENS 

01 – Figura 1 - As duas dimensões da criação do conhecimento ................................................ 6 

02 – Figura 2 – Modelo SECI ..................................................................................................... 7 

03 – Figura 3 – Utilização das Ferramentas de Gestão do Conhecimento ............................... 11 

03 – Figura 4 – Departamentos mais importantes no processo ................................................ 14 

04 – Caso de Uso - UC1 Indicação do Prefeito ........................................................................ 19 

05 – Caso de Uso - UC2 Habilitação Técnica do Município ................................................... 20 

06 – Caso de Uso - UC3 Elaboração da Peça Técnica ............................................................. 21 

07 – Caso de Uso - UC4 Licitação ........................................................................................... 22 

08 – Caso de Uso - UC5 Habilitação ........................................................................................ 24 

09 – Caso de Uso - UC6 Análise Final ..................................................................................... 25 

10 – Caso de Uso - UC7 Diário de Obra .................................................................................. 26 

11 – Caso de Uso - UC8 Entrega da Obra ................................................................................ 26 

12 – Caso de Uso - UC9 Prestação de Contas .......................................................................... 27 

13 - Protótipo da Ferramenta UC1-1 ........................................................................................ 32 


15 - Protótipo da Ferramenta UC2 ........................................................................................... 33 












27 - Protótipo da Ferramenta UC7 ........................................................................................... 39 



30 - Protótipo da Ferramenta Obra Finalizada (fim do processo) ............................................ 41 

xii

LISTA DE ABREVIATURAS E SIGLAS 

01 - 3M ............................................................................ Minnesota Mining and Manufacturing 

02 – BB ................................................................................................................. Banco do Brasil 

03 – BP ............................................................................................................. British Petroleum 

04 – CEF ............................................................................................... Caixa Econômica Federal 

05 – CND ......................................................................................... Certidão Negativa de Débito 

06 – CNPq ........................... Conselho Nacional de Desenvolvimento Científico e Tecnológico 

07 – ECT ................................................................. Empresa Brasileira de Correios e Telégrafos 

08 – HP .............................................................................................................. Hewlett-Packard 

09 – IBM .................................................................................... International Business Machines 

10 – IHC ...................................................................................... Interface Homem Computador 

11 – IPEA ................................................................... Instituto de Pesquisa Econômica Aplicada 

12 – OCDE ................................ Organização para Cooperação e Desenvolvimento Econômico 

13 – OSL ...................................................................................... Ordem de Serviço de Licitação 

14 – SECI ....................................... Socialização, Externalização, Combinação e Interiorização 

15 – SWEBOK .......................................................... Software Engineering Body of Knowledge 

16 – UC .................................................................................................. Use Case (Caso de Uso) 

xiii

SUMÁRIO 

CAPÍTULO 1 - INTRODUÇÃO ........................................................................................... 1 

1.1 - Contexto ................................................................................................................ 1 

1.2 - Motivação ............................................................................................................. 2 

1.3 - Objetivo ................................................................................................................ 2 

CAPÍTULO 2 - GESTÃO DO CONHECIMENTO ............................................................ 3 

2.1 – Teoria do Conhecimento - Tácito - Explícito ....................................................... 4 

2.2 – O Modelo SECI ................................................................................................... 6 

2.3 – O Conceito de Ba ................................................................................................. 8 

2.4 – O Sistema de Preços ............................................................................................. 8 

2.5 – Aplicação Desses Modelos nas Organizações ..................................................... 9 

2.5.1 - O Modelo da BP Exploration ................................................................... 9 

2.5.2 - O Modelo da Microsoft ............................................................................ 9 

2.5.3 - O Modelo da 3M .................................................................................... 10 

2.6 – Ferramentas de Gestão do Conhecimento ......................................................... 11 

CAPÍTULO 3 - LEVANTAMENTO DE NECESSIDADES ............................................ 12 

3.1 – Metodologia Utilizada ....................................................................................... 12 

3.2 – Estudo de Caso .................................................................................................. 13 

3.2.1 - Empresa A - Setor Privado .................................................................... 13 

3.2.2 - Empresa B - Setor Privado ..................................................................... 14 

3.3 – Justificativa e Objetivos com o Estudo de Caso ................................................ 17 

CAPÍTULO 4 - ENGENHARIA DE SOFTWARE ........................................................... 18 

4.1 – Ciclo de Vida ..................................................................................................... 18 

4.2 – Metodologias ..................................................................................................... 18 

4.3 – Objetivos da Ferramenta ................................................................................... 19 

4.3.1 - UC 1 - Indicação do Prefeito ................................................................ 19 

4.3.2 - UC 2 - Habilitação Técnica do Município ............................................ 20 

xiv

4.3.3 - UC 3 - Elaboração da Peça Técnica ...................................................... 21 

4.3.4 - UC 4 - Licitação .................................................................................... 22 

4.3.5 - UC 5 - Habilitação ................................................................................ 24 

4.3.6 - UC 6 - Análise Final ............................................................................. 25 

4.3.7 - UC 7 - Diário de Obra ........................................................................... 26 

4.3.8 - UC 8 - Entrega da Obra ........................................................................ 26 

4.3.9 - UC 9 - Prestação de Contas .................................................................. 27 

4.4 – IHC (Interface Humano Computador) ......................................................... 28 

4.4.1 - As Heurísticas de Nielsen ....................................................................... 29 

CAPÍTULO 5 - PROTÓTIPO DA FERRAMENTA ........................................................ 31 

5.1 – O Modelo de Caso de Uso ................................................................................. 31 

5.2 – O Protótipo da Ferramenta ................................................................................. 32 

CAPÍTULO 6 - CONCLUSÃO ............................................................................................ 42 

REFERÊNCIAS ................................................................................................................... 43 

Apêndice A - DOCUMENTO DE REQUISITOS ............................................................... 46 

xv

1.1 Contexto 

CAPÍTULO 1 

INTRODUÇÃO 

Não é de hoje que corporações ou instituições buscam pela Gestão do Conhecimento. 

Há décadas empresas do calibre da HP investem na pesquisa e desenvolvimento de ferramentas 

com o objetivo de gerir melhor o seu conhecimento. Um exemplo disso, é que em meados dos 

anos 90, a HP já utilizava sua rede intranet para discussão de projetos em andamento, pois se 

trata de uma corporação com inúmeras divisões espalhadas pelo mundo e essas divisões, como 

política da própria corporação, sempre privilegiaram a independência dessas divisões. Assim, 

um cientista que estivesse desenvolvendo determinado projeto de pesquisa, poderia estar 

buscando uma informação que outro cientista do outro lado do mundo, também estivesse na 

mesma linha de pesquisa (DAVENPORT & PRUSAK, 1998). 

Essa simples mudança da maneira de compartilhar informações fez com milhares de 

horas fossem economizadas e avanços significativos fossem alcançados. 

O sucesso foi tanto que em pouco tempo já estavam implantando diversas ferramentas 

para gerenciar o conhecimento da corporação; um que mereceu destaque foi o HP Networks 

News que permitia que qualquer revendedor de computadores HP obtivessem o conhecimento 

sobre produtos e serviços sem ter fazer um único telefonema (DAVENPORT & PRUSAK, 

1998). E estamos falando de uma época que a internet mal era conhecida pelos usuários 

comuns. 

Diversas corporações podem ser citadas como referência nessa busca pela gestão do 

conhecimento desde os primórdios dessa área, como por exemplo, a Buckman Laboratories, 

que utilizou repositórios para armazenagem de documentos e discussões do conhecimento 

sobre clientes, produtos e concorrentes; Ernest & Young, Andersen Consulting, Price 

Waterhouse e Coopers & Lybrand que há muito gerenciam milhares de banco de dados que 

reúnem conhecimento não só de seus clientes, mas sobretudo, sobre a prestação de serviços 

prestados a esses clientes, portanto, de valor inestimável para futuros trabalhos; a Chrysler 

criou o seu Livro do Conhecimento que se referia a um conjunto de lições aprendidas em todos 

os seus projetos, ou seja, o que funcionou e o que não funcionou; isso serviu como diretriz para 

1

os novos projetos melhorando o que deu certo evitando o que deu errado, aprendendo com 

esses erros. E isso para citar apenas alguns (DAVENPORT & PRUSAK, 1998). 

Relevantes avanços foram alcançados deste então, seja na tecnologia, seja nos processos 

que utilizam essa tecnologia. 

1.2 Motivação 

É fato que gerir toda essa massa de informação que as organizações possuem para 

extrair o que deverá ter relevância, ou seja, conhecimento não só é necessário, mas obrigatório 

e certamente precisarão de ferramentais que facilitem essa interação para poder gerar valor para 

si, para as corporações onde estão inseridos e por último ao país. 

E é daí que vem o valor da riqueza de uma organização. Este valor é diretamente 

proporcional aos seus ativos intangíveis, entre os principais, o conhecimento tácito de seus 

funcionários (SKYRME, 1998). Assim, em tese, quanto maior o tempo que a organização está 

no mercado, maior será seu conhecimento acumulado. 

Claro que isso dependerá de sua cultura, metodologia, boas práticas entre outros fatores. 

Ainda que muitas vezes seja intangível, o conhecimento é um dos ativos mais valorosos numa 

organização e esta tem de reconhecer que geri-lo é fundamental e merece o mesmo esforço que 

o engendrado para os ativos tangíveis (DAVENPORT & PRUSAK, 1998). 

1.3 Objetivo 

Desenvolver um protótipo de ferramenta capaz de atender a gestão do conhecimento de 

uma organização gerenciar o andamento de projetos, que seja multiplataforma e que tenha um 

custo de investimento baixo, sendo portanto, acessível a organizações que não disponham de 

grande orçamento para investir em ferramentas de gestão dessa natureza. 

Para conseguir atingir tal objetivo, será proposta uma ferramenta multiplataforma (o Ba 

- NONAKA e TAKEUCHI (2008) virtual) com filosofia de código aberto (open source), que 

seja capaz de receber informações técnicas e tácitas - resultado de suas experiências em campo 

e de discussão em reuniões de brainstorming - inseridas pelos participantes ao longo do 

processo e cujas informações possam criar conhecimento para que este processo seja 

melhorado constantemente num ciclo virtuoso conforme proposto no modelo SECI de 

NONAKA e TAKEUCHI (1995). 

2

CAPÍTULO 2 

GESTÃO DO CONHECIMENTO 

Neste trabalho será abordada a gestão do conhecimento no ambiente corporativo 

privado e público, entretanto, é fundamental ter uma definição bastante consistente sobre o que 

realmente significa gerir conhecimento no ambiente corporativo. 

Segundo DRUCKER (1999, apud DAVENPORT & PRUSAK, 1998), conhecimento 

“São dados interpretados, dotados de relevância e propósito”. NONAKA e TAKEUSHI (2008), 

definem que “o conhecimento, diferentemente da informação, refere-se a crenças e 

compromisso”. DAVENPORT & PRUSAK (1998) definiram de maneira bastante apropriada 

que “o conhecimento pode ser comparado a um sistema vivo, que cresce e se modifica à 

medida que interage com o meio ambiente”. 

Iniciando pelo elemento básico, o dado. Neste contexto, segundo DAVENPORT & 

PRUSAK (1998), dados representam um conjunto de fatos distintos e objetivos e que estão 

relacionados a eventos. Em termos mais técnicos, são registros estruturados resultantes de 

transações, como por exemplo, uma livraria vende um livro. O resultado dessa venda ou 

transação pode ser considerado um dado, DAVENPORT & PRUSAK (1998). Os dados em si, 

no entanto, não possuem significado relevante; eles descrevem apenas um momento passado. 

Assim, embora considerados matéria-prima de qualquer processo a ser mapeado, apenas dispor 

desses dados, não significa que eles dirão o que deve ser feito ou que decisão deverá ser 

tomada, mas são fundamentais na construção da informação. 

Ainda segundo DAVENPORT & PRUSAK (1998), a informação, por sua vez, como a 

própria origem etnologia indica, tem como papel dar forma aos dados observados, ou seja, ela 

passa a ter um significado. Mas, para que essa informação seja criada é necessário 

considerarmos diversos métodos, como: 

1. Contextualizar: os dados coletados. É fundamental definir a finalidade que os dados 

coletados terão; 

2. Categorizar: significa estabelecer o domínio dos dados, as unidades que estes deverão 

ser analisados; 

3. Calcular: este processo determina se o seu tratamento será através de mecanismos 

matemáticos ou estatísticos, por exemplo; 

3

4. Corrigir: tratar erros que eventualmente possam ocorrer durante o processo; 

5. Condensar: para que os dados possam ser resumidos para um modelo mais conciso, 

exemplo, um relatório de vendas global. 

O conhecimento, que tem como matéria-prima a informação, já foi definido por 

diversos epistemólogos, entretanto, a que melhor pareceu adequada ao contexto deste trabalho 

foi a de DAVENPORT & PRUSAK (1998): 

Conhecimento é uma mistura fluida de experiência condensada, valores, informação 

contextual e insight experimentado, a qual proporciona uma estrutura para avaliação e 

incorporação de novas experiências e informações. Ele tem origem e é aplicado na 

mente dos conhecedores. Nas organizações, ele costuma estar embutido não só em 

documentos ou repositórios, mas também em rotinas, processos, práticas e normas 

organizacionais. 

Este conceito é um dos princípios em que está baseada a teoria do conhecimento de 

NONAKA e TAKEUCHI (2008). E isso é visível em qualquer instituição que se estuda. Em 

geral, o conhecimento, na maioria delas reside na cabeça de poucas pessoas. 

Ainda segundo DAVENPORT & PRUSAK (1998), o conhecimento, dependendo da 

abordagem, pode ser encarado como um processo ou ainda como um ativo dentro da 

organização e cabe aos seres humanos o trabalho de transformá-lo, por meio de: 

1. Comparação: analisar de que maneira as informações de um determinado 

conhecimento se relaciona com outras situações já conhecidas; 

2. Conseqüências: qual é o impacto ou as implicações que tais informações trarão para a 

corporação se uma decisão for tomada baseada nelas; 

3. Conexões: quais são as relações que tal conhecimento possui em relação a outros 

conhecimentos que já estão integrados ao domínio; 

4. Conversação: quais os pontos de vista que as pessoas da organização têm em relação a 

este novo conhecimento. 

2.1 Teoria do Conhecimento - Tácito - Explícito 

Uma das etapas mais importantes da transformação é converter o conhecimento tácito 

para o explícito, ou seja, converter todo aquele conhecimento empírico que invariavelmente é 

difícil de se explicar, para o conhecimento explícito, que possui características de estruturação; 

simples de se compreender e armazenar pela maioria da pessoas que estão em seu domínio. 

Quando convertido e devidamente armazenado, o conhecimento explícito torna-se de 

fácil recuperação e interpretação. Para exemplificar, seria como aprender com o nosso pai 

4

como pescar um peixe, conhecimento tácito que nos é passado quando pequenos, para um 

documento digital estruturado, com facilidades de busca e cheio de arquivos de ajuda. 

Como a própria origem indica o conhecimento tácito (do latin, tacitus, que significa 

aquele que cala, que fica em silêncio) está dentro da cabeça de quem o possui. Nesse sentido 

são dois os desafios a serem vencidos, primeiro que o dono do conhecimento tácito tem que 

estar disposto a ceder esse conhecimento, segundo que ele também deverá ser capaz de traduzir 

conceitos muitas vezes abstratos e não estruturado para uma forma compreensível e de fácil 

acesso a outros que necessitem do mesmo. 

Segundo SCHÖN (1997, p. 82) referenciando POLANYI (1966), uma das referências 

mais importantes no estudo do conhecimento tácito e que foi um filósofo e polímata húngaro- 

britânico, definiu, o conhecimento tácito, da seguinte maneira (apud DUARTE, 2003): 

... espontâneo, intuitivo, experimental, conhecimento cotidiano, do tipo revelado pela 

criança que faz um bom jogo de basquetebol, (…) ou que toca ritmos complicados no 

tambor, apesar de não saber fazer operações aritméticas elementares. Tal como um 

aluno meu me dizia, falando de um seu aluno: Ele sabe fazer trocos, mas não sabe 

somar os números. Se o professor quiser familiarizar-se com este tipo de saber, tem de 

lhe prestar atenção, ser curioso, ouvi-lo, surpreender-se, e atuar como uma espécie de 

detetive que procura descobrir as razões que levam as crianças a dizer certas coisas. 

Esse tipo de professor se esforça por ir ao encontro do aluno e entender o seu próprio 

processo de conhecimento, ajudando-o a articular o seu conhecimento-na-ação com o 

saber escolar. Este tipo de ensino é uma forma de reflexão-na-ação que exige do 

professor uma capacidade de individualizar, isto é, de prestar atenção a um aluno, 

mesmo numa turma de trinta, tendo a noção do seu grau de compreensão e das suas 

dificuldades. 

O maior desafio de todos na gestão do conhecimento: transformar o conhecimento 

tácito em conhecimento explícito, NONAKA e TAKEUCHI (2008). Foi dessa necessidade que 

surgiu a teoria do conhecimento proposta por NONAKA e TAKEUCHI (1995), que desenha as 

duas dimensões do conhecimento, a dimensão epistemológica, onde o conhecimento transita de 

tácito para explícito, e a dimensão ontológica, que se refere aos níveis por onde o conhecimento 

flui, ou seja, do indivíduo para a organização, conforme pode ser visto abaixo. 

5

Figura 1 - As duas dimensões da criação do conhecimento 

Quadro reelaborado que representa as duas dimensões do conhecimento, segundo NONAKA & 

TAKEUCHI, (1997, p. 55) 

É importante ressaltar que, embora o modelo apresentado acima ter sido construído no 

formato de eixos cartesianos, não significa que ocorre uma evolução ascendente e da esquerda para 

a direta, na verdade o a evolução ocorre em espiral, conforme demonstrado no Modelo SECI. 

2.2 O Modelo SECI 

Existem muitos trabalhos de pesquisa que tentam identificar mapear formas de 

conversão do conhecimento tácito em conhecimento explícito, como (McADAM; 

McCREEDY, 2000), (McINERNEY, 2002), (SPENDER; SCHERER, 2007), (THOMPSON; 

WALSHAM, 2004), (DAVENPORT & PRUSAK, 1998), para citar alguns. (NONAKA E 

TAKEUCHI, 1997), por exemplo, trouxeram um conceito novo, eles criaram o modelo SECI. 

Trata-se de um modelo inserido num plano bidimensional, epistemológico (1) e ontológico (2) e 

propõe que quando há interação entre conhecimento tácito e explícito em determinados níveis é 

possível não só transformar o conhecimento tácito em conhecimento explícito como também 

criar novo conhecimento em uma “espiral de criação” contínua. As bases do modelo SECI são: 

_____________ 

(1) Epistemológico: Relativo a epistemologia, termo também conhecido como teoria do conhecimento, tem origem 

do grego Episteme, ou ciência, conhecimento + Logus, estudo, ou seja, estudo do conhecimento. 

(2) Ontológico: Relativo à ontologia, do grego Ontos + Logus, ou seja, conhecimento do ser. Parte da filosofia que 

trata da natureza do ser, da realidade, da existência dos entes e das questões metafísicas em geral 

6

1. Socialização. Onde os interessados na troca de conhecimento utilizam-se de 

mecanismos de socialização, uma boa conversa em pessoa, para trocarem informações, 

desenvolvendo com isso conceitos próprios sobre o domínio em questão; 

2. Externalização. Esta etapa consiste na capacidade de articular o conhecimento tácito de 

modo que o interlocutor possa compreender captar a essência do assunto tratado e poder 

extrair significado do mesmo. 

3. Combinação. Este processo refere-se a troca de conhecimento tácito entre 

interlocutores e que eventualmente resultará em um novo conhecimento tácito e que 

através de combinação ou processamento poderá ser explicitado, ou seja, armazenado 

de forma estruturada para futuras consultas; 

4. Interiorização. Aqui o ciclo se fecha, fazendo com que o conhecimento explícito 

armazenado possa retornar aos interlocutores para reaproveitamento como 

conhecimento tácito e, futuramente, retornar aprimorado na forma de conhecimento 

explícito num ciclo contínuo de aprimoramento. 

Figura 2 - Modelo SECI 

Quadro reelaborado que representa a espiral do conhecimento, segundo NONAKA & TAKEUCHI, (1997, p. 80) 

7

2.3 O Conceito de Ba 

A proposta de NONAKA E TAKEUCHI (2008) com o modelo SECI foi tornar esse 

conceito mais próximo das pessoas, a solução foi associar o modelo SECI ao Ba, termo de 

origem japonesa e que significa literalmente “porto”. A analogia, segundo NONAKA E 

TAKEUCHI (2008), é que desde a época dos fenícios, um porto, significa não apenas um local 

onde mercadorias chegam e partem, mas também, é um excelente contexto para que pessoas de 

diversas nacionalidades troquem conhecimento e experiências. 

O conceito de Ba foi abordado pela primeira vez pelo filósofo japonês Kitaro, 1970 

numa época em que o Japão buscava se firmar entre a industrialização que corria o mundo e 

seus valores tradicionais. Para se alinhar com os avanços tecnológicos sem, entretanto, abrir 

mão dos seus conhecimentos milenares ele propôs o Ba, que posteriormente foi desenvolvido 

por SHIMIZ, 1995. 

NONAKA e TAKEUCHI (1995), simplesmente adaptaram esse conceito de Ba ao seu 

modelo SECI como forma de sistematizar a geração de conhecimento. 

2.4 O Sistema de Preços 

A ferramenta que está sendo proposta aproveita o modelo SECI de NONAKA e 

TAKEUCHI (1995), além disso foi considerado o chamado “Sistema de Preços” 

(DAVENPORT & PRUSAK, 1998) que está intrinsecamente relacionado à predisposição dos 

donos desse conhecimento em “vendê-lo”. 

Existem aspectos que o indivíduo considera no hora da “venda”, segundo 

DAVENPORT & PRUSAK (1998), o primeiro deles é a Reciprocidade; “o que eu vou ganhar 

em troca de ceder o meu conhecimento?”. De acordo com essa tese, para que um indivíduo 

possa ceder o seu conhecimento, este deverá receber algo em troca, seja um conhecimento que 

o primeiro não possui, seja conseguindo vantagens em seu meio ambiente. Outro aspecto que 

impacta na batalha cotidiana pelo conhecimento é a Reputação. Todo indivíduo quer ser 

reconhecido como referência na detenção de determinado conhecimento. Isso fará com que sua 

reputação seja valorizada e indiretamente ele poderá “vender” ou “trocar” por outros ativos de 

valor. Um exemplo clássico desse perfil é o Consultor que, quanto melhor for a sua reputação, 

mais este receberá pelo seu conhecimento. 

Certamente existe um número, embora reduzido, de indivíduos com perfil Altruísta, 

que passa o seu conhecimento simplesmente por gostar de compartilhá-lo. 

8

O quarto fator, ainda segundo DAVENPORT & PRUSAK (1998), que estabelece 

relação de valor com os proprietários de conhecimento tácito é a Confiança. De maneira geral, 

em um ambiente, onde impera a confiança, os membros da organização se sentirão à vontade 

para compartilhar seus conhecimentos, pois não correrão o risco de terem esse conhecimento 

usurpado em nome da ambição e encontrarão ressonância nos outros membros que também 

estarão dispostos a compartilhar os seus. Em uma organização onde o trabalho em equipe tem 

precedência ao talento individual, as chances de realização de “bons negócios” no campo do 

conhecimento são bem maiores. 

2.5 Aplicação Desses Modelos nas Organizações 

Para manter a competitividade, inúmeras organizações buscam a gestão do 

conhecimento e se utilizam dos modelos mencionados anteriormente, adaptando estes modelos 

ao seu contexto. 

Os modelos a seguir foram descritos por DAVENPORT & PRUSAK (1999). 

2.5.1 O Modelo da BP Exploration 

A BP Exploration é uma subsidiária da BP (British Petroleum) tinha uma necessidade 

de integrar suas diversas unidades espalhadas pelo mundo e compartilhar conhecimento tácito 

contido em cada uma delas. Era uma proposta para tornar uma empresa multinacional com 

características de empresa pequena que toma decisões rápidas. 

Em 1994 foi lançado um projeto que foi denominado de Programa de Trabalho em 

Equipe Virtual. Nesse programa foram utilizados diversos itens de tecnologia, como 

videoconferência, digitalização de documentos, correio eletrônico multimídia e internet, que 

permitiu a troca de experiência entre os técnicos, aumentando consideravelmente o 

conhecimento corporativo e reduzindo consideravelmente os custos nas soluções de problemas. 

Esse aumento se deve ao fato que a maioria das interações foram feitas cara a cara, ainda que 

de forma virtual. 

2.5.2 O Modelo da Microsoft 

A Microsoft em 1995 começou um projeto que tinha como objetivo estabelecer as 

relações entre os funcionários e seus respectivos cargos que ocupavam além de associar esses 

9

cargos a conhecimentos inerentes a esses cargos e a organização. Com isso, pretendiam colocar 

as pessoas certas nas atividades que elas pudessem produzir mais num primeiro momento e 

posteriormente fomentar a disseminação dos diversos conhecimentos da empresa, a medida que 

o funcionário fosse subindo na hierarquia, assim, ele estaria familiarizado com estrutura 

organizacional, produtos e serviços e obviamente pronto a dar idéias, soluções e propor novos 

produtos, pois conheceria bem o contexto. 

A empresa possui quatro níveis de competências (básico, funcional, de liderança e 

especializado) que vai aumentando conforme o funcionário avança na hierarquia e seus 

conhecimentos vão aumentando. No total são 137 competências implícitas, que se referem a 

habilidades que estão mais associadas ao conhecimento tácito e 200 explícitas, que são 

avaliadas em reuniões de avaliação entre cada funcionário e seu respectivo supervisor; só que 

neste modelo todos da equipe podem participar da avaliação. Após as avaliações os dados vão 

para uma base que pode ser consultada no futuro, por exemplo, por um gerente que esteja 

montando um time para desenvolver um determinado projeto, conseqüentemente ele terá o 

melhor time com possibilidades de desenvolver melhores produtos. 

2.5.3 O Modelo da 3M 

A 3M possui um modelo bastante representativo da importância da gestão do 

conhecimento e como esse trabalho pode resultar em lucro. Dos mais de sessenta mil produtos 

que a empresa comercializa no mundo todo 30% do seu lucro vem de produtos com menos de 4 

anos do lançamento. Em 1996 a 3M criou mais de quatrocentos produtos novos. 

Para atingir uma força de criação dessa magnitude o compartilhamento do 

conhecimento é crucial, pois novos produtos, na maioria das vezes, vem de ideias já existentes 

(DAVENPORT & PRUSAK, 1999). A própria política da empresa já estimula esse poder de 

inovação, pois, muito antes do Google existir, a 3M já destinava aos funcionários quinze por 

cento do seu tempo de trabalho, para pesquisas de interesse pessoal. O processo conta também 

com um encontro mensal do conselho que representa os laboratórios de pesquisa da empresa, 

para trocarem ideias, além disso, existe um fórum anual de cientistas e técnicos que promovem 

seus conhecimentos em um evento que dura três dias. Todo esse conhecimento gerado na 

socialização de seus funcionários, a 3M disponibiliza em uma intranet para outros 

pesquisadores possam acessar. E foi desse modelo que saíram invenções como a fita Scotch, 

10

que foi inventada por um vendedor de lixas, Dick Drew e o Post-It, inventado por Art Fry, idéia 

que surgiu numa troca de memorandos com outro cientista da organização. 

2.6 Ferramentas de Gestão do Conhecimento 

Conforme pode ser observado nos modelos apresentados, não existe uma ferramenta 

única e com destinação exclusiva para a gestão do conhecimento. Na verdade as ferramentas 

são apenas o catalisador das políticas engendradas pelas instituições que as utilizam. 

Entretanto, existem uma convergência dessas ferramentas para as tecnologias web, por sua 

facilidade de implementação e principalmente integração de ambientes heterogêneos. 

As ferramentas de gestão do conhecimento mais utilizadas, segundo GELENSKI (2010) 

são mostradas no gráfico abaixo. O mais curioso é em relação à fonte desta informação, que faz 

parte de um grande projeto colaborativo de gestão do conhecimento aberto e que foi criado por 

uma brasileira, Fernanda Viégas para a IBM Research. 

Figura 3 - Utilização das Ferramentas de Gestão do Conhecimento 

Quadro reelaborado que apresenta resultado de pesquisa, segundo GELENSKI, (2010) 

11

CAPÍTULO 3 

LEVANTAMENTO DE NECESSIDADES 

Neste capítulo, foram apresentados os aspectos que nortearam o estudo que levou a 

proposição da ferramenta de gestão do conhecimento, desde a escolha da metodologia até a 

proposta final e também como se deu a escolha do estudo de caso ao qual se destinou tal 

ferramenta. 

3.1 Metodologia Utilizada 

Nesta pesquisa, para identificação dos requisitos do projeto, foram utilizados os 

métodos, previsto no SWEBOK (Software Engineering Body of Knowledge) versão 2004, de 

entrevista informal e reuniões de brainstorming com toda a equipe. Para não intimidar os 

entrevistados, após conseguir sua confiança e autorização, era iniciada gravação em áudio da 

entrevista. 

Esse modelo deixava as pessoas mais à vontade do que o modelo tradicional, anotando 

em uma planilha de dados e as deixavam suscetíveis a serem mais abertas na exposição das 

ideias. 

É claro que esse modelo aumentava o tempo de coleta, pois ao concatenar e identificar 

cada processo, foi necessário ouvir as gravações inúmeras vezes. 

Uma prova sobre como é complexo extrair conhecimento tácito dos funcionários, em 

diversas oportunidades, algumas entrevistas e reuniões tiveram que ser refeitas, pois em 

diversas ocasiões, não estava claro na entendimento dos funcionários algumas de suas próprias 

atividades, menos ainda sobre as atividades dos funcionários de etapas anteriores ou posteriores 

às quais o seu próprio processo estava intimamente ligado. Esta inclusive, foi apontada nas 

reuniões como a causa principal de erros no processo ocorrerem com freqüência, causando 

atrasos indevidos e, em algumas oportunidades, prejuízos financeiros, quando se gerava 

reserviço, impactava em horas extras de trabalho, novos documentos a serem expedidos, custos 

cartoriais, sem mencionar o atraso da obra em si de que se tratava o processo. 

12

3.2 O Estudo de Caso 

Como estudo de caso, tomamos como exemplo, duas entidades, uma corporativa, 

doravante identificada meramente como Empresa A, para termos uma visão alinhada às 

expectativas do mercado corporativo privado e outra do setor público que, por sua vez, será 

identificada como Empresa B e que terão suas identidades preservadas. 

3.2.1 Empresa A – Setor Privado 

A Empresa A, da área de desenvolvimento de software, tem um perfil bastante alinhado 

as necessidade de produção de um mercado competitivo. Possui um modelo de certificação 

notoriamente reconhecido e, portanto, está familiarizada com as boas práticas aceitas no 

segmento. Sua equipe de colaboradores é bem qualificada e foi criteriosamente selecionada. 

Além disso, possui um portfólio de clientes bastante relevante e tem um porte representativo, 

com cerca de 80 funcionários e faturamento da ordem de 5,5 milhões de reais ao ano. 

Todas essas credenciais, supostamente, seriam mais que necessárias para uma boa 

aderência ao processo de gestão do conhecimento, entretanto, não é o que foi observado. O 

próprio gestor, responsável pela implantação da gestão do conhecimento, encontra enormes 

desafios no seu dia-a-dia. 

Nesta observação preliminar, não foi possível identificar um único fator de explícita 

relevância que justificasse tais desafios. Na verdade, foi relatado que são os diversos pequenos 

aspectos é que se tornaram os desafios grandes. A começar pela cultura corporativa. Embora a 

equipe seja bem selecionada e treinada, ainda falta um dos pontos mais importantes para o 

sucesso da implementação, a cultura. 

Ainda segundo relato do gestor, a gestão do conhecimento ainda não faz parte do 

escopo oficial da produção da empresa. Assim, sempre quando surge uma emergência mais 

agravante que impacta diretamente na entrega do serviço contratado, esse processo tende a 

ocupar um segundo plano entre as prioridades. 

Isso é plenamente justificável, pois a empresa ainda está passando por um processo de 

amadurecimento na gestão do conhecimento, além disso, por causa da cultura organizacional, 

ainda é difícil identificar o que são os processos ligados especificamente à gestão do 

conhecimento e quais são os que estão ligados ao processo de certificação na área de produção 

de software pelo qual a empresa também está atravessando. 

13

Um ponto ficou bem claro e também foi relatado pelo gestor, a participação da alta 

gerência é crucial para o sucesso do plano, talvez o sucesso ainda não foi pleno por conta do 

envolvimento de alguns dos parceiros ainda não ser total. Isso também foi identificado na 

pesquisa mencionada no capítulo anterior, conforme podemos ver a seguir na Figura 4. 

Figura 4 – Departamentos mais importantes no processo 

Quadro reelaborado que apresenta pesquisa publicada na Revista HSM MANAGEMENT. Edição número 42, 

janeiro-fevereiro 2004 

3.2.2 Empresa B - Setor Público 

A Empresa B foi um grande desafio por se tratar de um órgão público da região. Neste 

setor também existem diversos trabalhos realizados sobre Gestão do Conhecimento. Para dar 

uma perspectiva sobre o tamanho da dificuldade presente no setor público é importante 

mencionar a conjuntura atual do setor público no Brasil. 

Para tentar compreender em que nível está a área pública, a seguir é citado um trabalho 

de pesquisadores patrocinado pelo IPEA (Instituto de Pesquisa Econômica Aplicada), Gestão 

"Do Conhecimento Na Administração Pública" é traçado um panorama de como a setor público 

no Brasil vem tratando a Gestão do Conhecimento. Este trabalho faz uma análise em 28 órgãos 

do governo, entre ministérios e empresas estatais e deixa claro que o setor público ainda tem 

muito que caminhar para alcançar uma gestão do conhecimento relevante. Comparando com 

14

outros países da OCDE, Organização para Cooperação e Desenvolvimento Econômico, o Brasil 

ainda produz resultados muito insignificantes. 

As principais razões apontadas pelo estudo fazem menção à falta de compartilhamento e 

mesmo falta de informação, o desconhecimento por parte da alta administração, sobre o tema e 

iniciativas isoladas muitas vezes dentro de um mesmo órgão. 

As estatais, contudo, demonstraram um maior nível de aderência a esse modelo de 

gestão, algumas inclusive, já se encontrando em processo de implementação; talvez por terem 

participação do capital privado e contarem com uma administração mais dinâmica, como são os 

casos da Petróleo Brasileiro S/A, (Petrobras), Banco do Brasil (BB), Caixa Econômica Federal 

(CEF), Empresa Brasileira de Correios e Telégrafos (ECT), Serviço Federal de Processamento 

de Dados e Eletrosul Centrais Elétricas S/A (Eletrosul) (BATISTA, et al. 2005). 

A partir desta referência, pode-se vislumbrar a dimensão do desafio de se implementar, 

ou mesmo incentivar a gestão do conhecimento salientando a importância de se ter boas 

práticas nesta área. 

Primeiro que, neste estudo de caso, trata-se de uma entidade pública municipal com um 

orçamento muito menor e com nível cultural administrativo proporcionalmente inferior ao de 

órgãos federais. Porém, como o objetivo deste trabalho é também mapear setores que 

eventualmente poderiam se beneficiar de uma ferramenta de gestão do conhecimento, ainda 

que bem prosaica, para aprimorar a gestão e, sobretudo, se alinhar com práticas mais modernas 

de gestão pública. 

Segundo, o meio público é um meio ambiente muito diferente do setor privado; a 

cadência é muito mais lenta, em virtude de uma série de aspectos culturais e até mesmo 

jurídicos que envolvem a administração pública, o que torna todo o processo extremamente 

moroso e burocrático. 

Dentro de uma administração municipal, por menor que seja a cidade, desmembram-se 

uma infinidade de secretarias, diretorias, setores, divisões e departamentos que, muitas vezes 

possuem leis próprias que as regem, exemplo disso, é o Departamento de Licitações. Isso tudo 

sem mencionar as autarquias, que são órgãos que possuem relativa autonomia sem, no entanto, 

a interferência do poder central, o executivo. 

Para este trabalho, foi escolhido certo Departamento, que, por motivos de preservação 

da identidade dos envolvidos, não será mencionado, como sendo o foco do estudo. A razão é 

que este departamento possui uma série de procedimentos cujas operações tem origem focada 

15

no conhecimento tácito dos funcionários, assim, a gestão do conhecimento seria de grande valia 

para que o desempenho operacional deste fosse aprimorado de forma considerável. 

De imediato, foi identificado um cenário típico, à medida que o tempo de serviço 

aumentava no currículo dos funcionários, diminuía consideravelmente a motivação em 

compartilhar o seu conhecimento. Esse cenário só começou a mudar com a intervenção da alta 

direção, ou seja, o Secretário ao qual o departamento era subordinado. 

No setor público existem duas classes de funcionários: os concursados, os chamados 

funcionários estatutários; e os nomeados, ou cargos em comissão, que são indicados de acordo 

o mapa político dominante. Desta maneira, como os cargos chaves no departamento em questão 

eram ocupados por cargos oriundos de nomeação e, portanto, passíveis de demissão sumária, 

no caso de não colaboração, foi obtida razoável contribuição ao projeto. 

O intuito inicial era criar uma ferramenta que pudesse controlar todo o processo de 

gerenciamento de projetos financiados com verbas públicas e que pudesse estar disponível 

online, em qualquer lugar e a qualquer hora. A resposta foi a criação de uma ferramenta 

desenvolvida com tecnologia web. 

Para viabilizar o projeto era necessário fazer um mapeamento de todo o processo e 

respectivas atividades envolvidas no gerenciamento de projetos. E como estas atividades 

sempre geraram muito conhecimento tácito e quase nenhum explícito, foi a oportunidade 

perfeita para este trabalho. 

Foram cerca de 20 dias de mapeamento de processos e as principais dificuldades 

encontradas foram: 

1. Quase todos os processos estavam na cabeça dos usuários. Não existia nenhuma 

documentação que fizesse qualquer referência às atividades desenvolvidas no 

departamento; 

2. Muita resistência do funcionário em fornecer detalhes das operações, um deles 

chegou a declarar: “Ah isso eu não vou passar não. Eu ralei muito pra aprender isso 

e não vou dar de bandeja.”; 

3. Pela própria falta de documentação ou explicitação do conhecimento, o mesmo 

processo que estava na cabeça de um funcionário não era exatamente o mesmo na 

cabeça de outro, seja no processo sucessor, seja no anterior; 

16

4. Disputa política, entre funcionários, onde um fora indicado por um partido e outro, 

que fora indicado por outro que, embora na época da eleição fossem coligados, já 

não compartilhavam dos mesmos objetivos, o que certamente atrasou o processo; 

5. Falta de verba para investir na Infra-estrutura física para hospedar a nova 

ferramenta; 

6. Obter disponibilidade dos funcionários para validar os processos mapeados; 

7. Criar uma interface que pudesse congregar diferentes gerações de funcionários, 

desde os mais jovens até os mais antigos no cargo e de forma intuitiva; 

8. E finalmente, talvez a maior dificuldade, era vencer aqueles que não queriam ver o 

sucesso do projeto, por razões que não cabem neste trabalho, serem discutidas. 

9. Embora a ferramenta encontra-se em estágio inicial de testes e ainda contando com 

certa resistência na implantação, teve-se uma amostra das dificuldades encontradas 

e o desafio que é a implantação não somente da Gestão do Conhecimento, mas, 

sobretudo na mudança de cultura. Havendo disponibilidade, posteriormente, no 

trabalho final, serão apresentados os resultados mais conclusivos de utilização e o 

impacto que isso eventualmente tenha causado. 

3.3 Justificativa e Objetivos com o Estudo de Caso 

Finalizado a coleta das entrevistas e a descrição final dos requisitos, todos deram 

aprovação ao texto final e iniciou-se o processo de construção da IHC. Foi realizado um projeto 

focado no perfil dos usuários que partia dos mais jovens e experientes com interface web aos 

mais velhos que não tinham muita experiência com interação com aplicações web. 

Assim, optou-se por uma interface extremamente simples, que expusesse apenas que fosse 

relevante para cada etapa do processo. 

Devido às atividades do departamento serem muito extenuantes e, este projeto não fazer 

parte do escopo principal da administração e a urgência do projeto ser alta, a interface gráfica 

não foi totalmente homologada. Apenas os responsáveis por cada departamento fizeram a 

homologação e era objetivo desta pesquisa que todos homologassem a IHC. 

Outra justificativa relevante é o fato da organização necessitar de uma aplicação de 

baixo custo, devido às dificuldades de caixa. 

Após homologação foi realizado um estudo para o desenho do banco de dados e iniciou- 

se o desenvolvimento. 

17

CAPÍTULO 4 

ENGENHARIA DE SOFTWARE E ESPECIFICAÇÃO DA 

FERRAMENTA 

Neste capítulo foram descritos os critérios utilizados para a especificação da ferramenta 

e a abordagem adotada para capturar os procedimentos realizados pelos usuários de um 

processo mapeado, neste caso, a gestão de projetos de obras do município. uma vez que este 

processo atualmente é realizado em grande parte de forma manual. 

4.1 Ciclo de Vida 

Devido as características da organização, ou seja, uma prefeitura municipal de uma 

pequena cidade do interior (Estudo de Caso Empresa B, p. 26), e o contexto que esta prefeitura 

em específico está inserida, a abordagem adotada foi a incremental. 

As principais razões que levaram a esta escolha foram: 

1. É grande a urgência na utilização da ferramenta, assim os usuários já poderão utilizar 

uma ferramenta ainda que esta não possua todos os requisitos necessários; 

2. Alguns dos requisitos não são conhecidos plenamente pelos usuários; 

3. As mudanças nesses requisitos não são raras, o que vai acarretar constantes e inevitáveis 

mudanças na ferramenta (SOMMERVILLE, 2011). 

4.2 Metodologias 

Segundo SOMMERVILLE, 2011, cada organização tem que buscar o melhor modelo 

para realizar a elicitação e especificação dos requisitos necessários ao desenvolvimento de uma 

ferramenta. Neste caso, foram feitas diversas entrevistas com os stakeholders para identificar os 

requisitos de cada um e como cada requisito se relaciona com os demais. 

Também foram equacionados alguns conflitos de requisitos durante o processo de 

elicitação, decorrentes da falta de conhecimento por parte dos usuários, sobretudo, sobre como 

sua atividade impacta da atividade subseqüente. 

Obter os requisitos de um usuário, em especial, que não conhece muito bem sua 

atividade é muito difícil, principalmente em uma instituição pública. 

18

Para se ter uma referência do que significa especificar uma ferramenta para uma 

prefeitura, basta observar apenas uma das dificuldades no processo de elicitação mencionado 

por SOMMERVILLE (2011, p. 71): 

4.3 Objetivos da Ferramenta 

Fatores políticos podem influenciar os requisitos de um sistema. Os gerentes podem 

exigir requisitos específicos, porque estes lhes permitirão aumentar sua influência na 

organização. 

Neste trabalho foi utilizada classificação de caso de uso do tipo nuvem. Segundo 

COCKBURN (2001), a classificação do tipo nuvem permite um curso normal abstrato, bem 

próxima às necessidades deste trabalho. 

A ferramenta terá como principal objetivo, a congregação de todas as informações 

geradas durante o processo de gerenciamento da obra para extração de conhecimento. Assim, 

esta atuará como um Ba Virtual; e sendo construída com tecnologia web, será multiplataforma. 

A cada obra subsequente, a informação armazenada servirá de guia para aprimoramento 

do conhecimento adquirido, especialmente nas reuniões de planejamento, conforme modelo 

SECI de NONAKA e TAKEUCHI (1997). 

Durante o processo de elicitação de requisitos, cujo documento está no Apêndice A, 

foram levantados alguns processos que resultaram nos seguintes casos de uso: 

4.3.1 UC 1 - Indicação do Prefeito 

19

Justificativa: 

Este passo é fundamental para que o processo inicie corretamente. Hoje esta etapa é 

feita na maioria das vezes verbalmente, o que pode levar a uma série de problemas devido a má 

interpretação das necessidades, gerando reserviço. 

Curso normal: 

1. Prefeito recebe uma demanda que pode ser popular, exemplo, abaixo assinado, ou 

oficial, por exemplo, do legislativo (câmara municipal), faz suas considerações em 

reuniões com responsáveis e insere no sistema através de formulário próprio; 

2. Secretário acessa o sistema e a respectiva indicação e insere as considerações técnicas 

que julgar necessárias para complementar a indicação; 

3. O sistema altera o status do registro e passa a ser exibido na pauta de trabalho do gestor 

de projetos; 

4.3.2 UC 2 - Habilitação Técnica do Município 


Este registro é um dos mais importantes, pois toda a documentação principal é inserida 

aqui, hoje é um dos motivos de maior reserviço de todo o processo, pois em geral a falta de 

documentos na hora de aprovar junto ao agente financeiro faz com que o processo pare e fique 

em looping até que se tenha todos os documentos necessários. Aqui também começa a Gestão 

do Conhecimento, pois como cada projeto pode demandar inúmeros documentos diferentes e 

ter características diferentes, isso será fundamental para agilizar o processo no próximo projeto 

com as mesmas características. 

20

Curso normal: 

1. Gestor de Projetos reúne documentação e lança no sistema (upload de arquivos 

digitais); 

2. Após receber parecer do agente financeiro, lança parecer no sistema, além de 

informações complementares como por exemplo, se necessita de Trabalho Técnico 

social; Faz o upload dos documentos gerados pelo agente financeiro e lança a data 

que o projeto deverá ser apresentado. 

3. Sistema altera o status do registro e notifica os stakeholders e cai na pauta da 

Secretaria de Infra-estrutura para elaboração da Peça Técnica (projeto); 

4.3.3 UC 3 - Elaboração da Peça Técnica 


Mais uma etapa na qual as atividades são feitas manualmente e a documentação é 

exclusivamente física. É crucial armazenar essa documentação em um repositório e mantê-la 

associada ao projeto, informar o próximo funcionário que ele tem trabalho a fazer em sua 

pauta, além de notificar todos os envolvidos. 

21

Curso normal: 

1. Secretário da Infra-estrutura faz uma análise do projeto e se sua secretaria será capaz de 

atender a demanda e insere no sistema um parecer técnico justificando se atenderá ou 

não a demanda; 

2. Engenheiro Responsável envia toda a documentação (plantas, memorial descritivo, 

planilhas orçamentárias, etc.); 

3. Sistema notifica os stakeholders e cai na pauta do Gestor de Projetos para que 

providencie a aprovação da Peça Técnica; 

4.3.4 UC 4 - Licitação 

22


Mais um processo em que a organização e preservação dos documentos e dos processos 

peculiares à respectiva obra é fundamental para agilizar o processo. Aqui é onde a organização 

mais perde documentos, por se tratar de uma grande quantidade. 

Curso normal: 

1. Técnico de Licitação entra no sistema e faz a solicitação de Dotação Orçamentária 

para o departamento Financeiro, que é automaticamente notificado; 

2. Diretor financeiro aprova a dotação orçamentária e lança no sistema, liberando a 

licitação; 

3. Sistema notifica a todos; 

4. Diretor de Licitação providencia Ordem de Serviço de Licitação e anexa link para que o 

Prefeito baixe o arquivo do tipo DOC, imprima-o, assine para oficializar a licitação, 

para que também digitalize esta OSL (Ordem de Serviço de Licitação) e também faça 

upload para o repositório; 

5. Após a oficialização do prefeito, o Diretor de Licitação é notificado e encaminha 

para a pauta do seu jurídico; 

6. Jurídico da Licitação emite parecer técnico atestando a corretude do processo até 

então; 

7. Após receber parecer jurídico, o Diretor de Licitação abre licitação e quando receber 

as propostas, anexa as respectivas documentações e encaminha para a Secretaria de 

Infra-estrutura para que analise e emita parecer da documentação atestando a 

qualidade técnica das empresas participantes do processo licitatório; 

8. Sistema notifica a todos, altera o status do registro e envia para a pauta da Secretaria 

da Infra-estrutura para habilitação das empresas participantes e aguarda para 

finalizar o processo licitatório. 

23

4.3.5 UC 5 - Habilitação 


Esta etapa pode ser bem complexa em função das diversas iterações até que esteja 

juridicamente adequado e o controle e o armazenamento dos pareceres é fundamental para que 

não ocorram os mesmos erros. 

Curso normal: 

1. Engenheiro Responsável faz a análise de toda a documentação e faz a Habilitação, 

emite e lança no sistema o parecer técnico; 

2. Sistema notifica a todos e lança na pauta da Licitação para que finalize a licitação; 

3. Diretor de Licitação analisa e encaminha para o Departamento Jurídico fazer mais 

uma avaliação; 

4. Sistema altera o status e notifica a todos; 

5. Departamento Jurídico emite Parecer no sistema; 

6. Sistema notifica o Diretor de Licitação elabora contrato e lança no sistema a data de 

abertura dos envelopes; 

24

7. Escolhida a vencedora, Diretor de Licitação lança no sistema Observações finais 

(dados para gestão do conhecimento: desafios enfrentados e possíveis melhorias na 

próxima licitação), data da assinatura do contrato e faz o upload de uma cópia do 

contrato no repositório; 

8. Sistema notifica a todos e segue para a pauta do Departamento e o status é alterado. 

4.3.6 UC 6 - Análise Final 


Só a facilidade do Gestor de Projetos ir num único lugar e baixar todos os documentos e 

imprimir já justificaria o caso de uso, mas também existe a facilidade de já armazenar a Ordem 

de Serviço adequadamente sem risco de perda, o que ocasionaria diversos problemas e 

reserviço. 

Curso normal: 

1. Gestor de Projetos reúne toda a documentação do repositório, imprime e encaminha 

para o agente financeiro para análise final; 

2. parecer do agente financeiro é lançado, é feito o upload da Ordem de Serviço do 

agente financeiro. Este documento é importantíssimo, ele diz que as obras, 

finalmente podem começar. 

3. sistema notifica os stakeholders. 

25

4.3.7 UC 7 - Diário de Obra 


Caso de uso fundamental para que todos, principalmente o prefeito, saiba exatamente, 

de onde quer que ele esteja, o andamento de suas obras, se estão dentro do cronograma ou não e 

o se precisa ajustar algum processo e cobrar dos responsáveis determinadas situações. 

Curso normal: 

1. Departamento de Infra-estrutura, através de um técnico coleta periodicamente 

informações sobre o andamento da obra, o que gera um documento denominado 

“Boletim de Medição” que é lançado no sistema; 

2. É feito o upload das eventuais fotos tiradas do estágio atual da obra; 

3. sistema notifica os stakeholders a cada lançamento. Quando se tratar do último 

boletim, indicando a finalização da obra, o registro é enviado para a pauta do 

engenheiro responsável que fará a entrega da obra. 

4.3.8 UC 8 - Entrega da Obra 

26


Mais uma etapa importantíssima onde documentos de grande relevância são lançados 

armazenados no repositório, além de observações sobre os desafios encontrados durante a 

operação que agregarão informações na gestão do conhecimento. 

Curso normal: 

1. engenheiro responsável faz o lançamento de todas as informações finais relativos a 

finalização da obra; 

2. É feito o upload de todos os documentos legais necessários que ainda estão faltando, 

como Laudo dos Bombeiros, CND (Certidão Negativa de Débito) da Empreiteira, 

etc.; 

3. sistema grava a informação e notifica a todos e envia para a pauta do Gestor de 

Projetos. 

4.3.9 UC 9 - Prestação de Contas 


A mais importante de todas as etapas, pois é onde hoje ocorrem os maiores problemas. 

A falta de qualquer documento obrigatório, pode ser passível de rejeição por parte do agente 

financeiro e comprometer futuros convênios e conseqüentemente, novas obras. Com o parecer 

final do Gestor de Projetos, os procedimentos envolvendo obras que se utilizem de 

procedimentos semelhantes, poderão ser realizados de forma mais racional e, com certeza, mais 

baratas para o contribuinte. 

27

Curso normal: 

1. Gestor de Projeto reúne toda a documentação do repositório para fazer a prestação 

de contas para enviar ao agente financeiro; 

2. Faz upload de mais alguns documentos para complementar o processo; 

3. Lança no sistema o parecer do agente financeiro sobre a documentação apresentada; 

4. Lança seu próprio parecer resumindo o que foi todo o desenvolvimento da obra; 

5. sistema grava esta operação e notifica todos os stakeholders. 

4.4 IHC - Interface Humano Computador 

Um dos aspectos mais relevantes de uma ferramenta é a IHC. A razão dessa relevância 

está no fato de quanto maior a dificuldade de um usuário ao utilizar a ferramenta, menor será a 

aderência a mesma, comprometendo assim todo o processo. Por esta razão, para a elaboração 

da ferramenta foi dedicado um esforço para alinhar esta com as boas práticas propostas por 

alguns dos mais respeitados estudiosos no assunto. 

A IHC trata dos aspectos que facilitem a utilização ou usabilidade de uma ferramenta 

por parte dos usuários. Esse não é um tema novo. Segundo a Dra. Anamaria de Moraes - 

respeitada pesquisadora do CNPq (Conselho Nacional de Desenvolvimento Científico e 

Tecnológico) e Professora da PUC do Rio de Janeiro, em entrevista disse que, em 1991 quando 

convidou o Prof. John Long da University College London para ministrar uma palestra no 

Brasil ele já era coordenador de um laboratório de usabilidade. Como na maioria dos avanços 

tecnológicos, suas pesquisas eram desenvolvidas para a marinha britânica e também para 

aeroportos, onde estudava como melhorar a interface do monitoramento do controle de tráfego 

aéreo, uma aplicação extremamente crítica. Ainda segundo a Dra. Anamaria por conta da 

importância do tema grandes corporações como IBM, Oracle e Microsoft possuem laboratórios 

de usabilidade em constante pesquisa (WEBINSIDER, 2003) e (MORAES e MONT'ALVÃO, 

2000). 

Outros pesquisadores deram importantes contribuições para o avanço da IHC, como 

Dra. Jenny Preece (PREECE, 2002), pesquisadora da Universidade de Maryland e o Dr. Jacob 

Nielsen (MOLICH e NIELSEN, 1990) da Universidade de Copenhague, Dinamarca, de cujas 

heurísticas criadas por este último que a ferramenta proposta foi projetada. 

28

4.4.1 As Heurísticas de Nielsen 

Segundo NIELSEN e MOLICH (1990), há dez princípios gerais para se desenvolver um 

projeto com boa interface e que Nielsen denominou de heurísticas, pois segundo ele, tem muito 

mais a ver com as experiências práticas do que regras formais de usabilidade. São elas: 

1. Visibilidade da situação ou status do sistema – o sistema deve estar sempre exibindo de 

forma clara o que está realmente acontecendo; 

2. Correspondência entre sistema e o mundo real – O sistema deve falar a linguagem do 

usuário, com palavras ou frases que lhe são familiares. Isso é mais importante do que 

um sistema orientado a termos técnicos. Seguir as convenções do mundo real, fazendo 

com que a informação apareça na ordem natural e lógica; 

3. Controle e Liberdade para o usuário – Em geral usuários cometem erros por escolher 

opções erradas, assim ele deverá ter à sua disposição formas de sair ou se recuperar de 

tal situação, assim a ferramenta deverá ter opções para fazer ou refazer uma 

determinada ação; 

4. Consistência e Padrão – O usuário não tem concluir que palavras, situações ou ações 

diferentes significam a mesma coisa. Manter um padrão nas convenções utilizadas; 

5. Prevenção de Erro – Primeiro, melhor que uma boa mensagem de erro é um design que 

previna um problema de ocorrer; Eliminar condições que são propensas a erros ou 

sempre solicitar ao usuário uma decisão antes de confirmar a ação; 

6. Reconhecimento a Recordar – Minimizar a utilização da memória do usuário ao efetuar 

uma ação, sempre que possível manter a informação visível. O usuário não tem que se 

lembrar dos passos de uma tela para outra. As informações deve estar visíveis ou 

facilmente alcançáveis sempre que necessárias; 

7. Flexibilidade e eficiência de uso – facilitadores (como teclas de atalho) podem acelerar 

a velocidade de interação com usuários experientes, contudo, o sistema deve fornecer 

aos usuários experientes ou não, a mesma experiência; 

8. Estética e design minimalista – Telas não devem ter informações desnecessárias, 

irrelevantes ou raramente utilizadas. Cada informação inócua numa tela compete com 

aquelas que são importantes e como conseqüência, diminui sua visibilidade; 

29

9. Ajude o usuário a reconhecer, diagnosticar e recuperar de erros – Mensagens de erros 

devem ser expressas em linguagem simples, sem códigos ou termos técnicos e serem 

precisas ao indicar o erro ocorrido e sugerindo de forma construtiva uma solução; 

10. Ajuda e documentação – Ainda que o melhor seria se o sistema pudesse ser usado sem 

documentação, esta pode ser necessária para prover ajuda e referência documental. As 

informações contidas na documentação deve ser fácil de encontrar, focada na tarefa do 

usuário com a seqüência necessária a sua consulta e não muito extensa. 

30

5.1 O Modelo de Caso de Uso 

CAPÍTULO 5 

PROTÓTIPO DA FERRAMENTA 

Baseado nas experiências etnográficas foi observado um comportamento de certa forma 

arredio dos usuários de tecnologias quando tem que interagir com algum sistema 

computacional, além disso, quando tratamos de Gestão do Conhecimento, em geral os “donos 

do conhecimento”, não tem nenhuma motivação para compartilhar aquilo que durante anos teve 

de sofrer para aprender, o que, conforme mencionado em capítulos anteriores é o maior desafio, 

aliás, sempre foi. DAVENPORT & PRUSAK (1998, p. 172) concluíram: 

Nestes primórdios da Gestão do Conhecimento, o mais importante, numa estratégia da 

tecnologia do conhecimento, é tomar a sopa pelas bordas. Até que você construa um 

sistema e veja como a organização responde, não dá para saber nem até que ponto as 

pessoas estão dispostas a compartilhar conhecimento através de sistemas. Será difícil 

determinar que tipos de aplicativos se coadunam melhor com a organização até que se 

façam experimentos. No momento, não existe tecnologia certa para a Gestão do 

Conhecimento. Estamos todos começando a abrir nossas trilhas e, uma vez que a 

tecnologia não é o único aspecto do seu esforço da Gestão do Conhecimento, o 

elemento mais essencial é começar, seja com o que for. 

A relação produtiva entre tais elementos humanos com a tecnologia deve ser 

colaborativa e de fácil utilização, deixando toda a complexidade da parte computacional 

abstraída do usuário final. (Idem, ibid.,1998, p. 159, 161 e 162) também mencionaram: 

Se você está iniciando um projeto de gestão do conhecimento envolvendo publicação, 

discussão e pesquisa recomendamos usar a web por causa de sua trajetória de 

amadurecimento e porque é muito mais simples de ser dominada pelos usuários. 

(...) 

Todavia, se planeja usar tecnologia web na gestão do conhecimento (particularmente a 

pesquisa e recuperação do conhecimento estruturado, baseado em documentos, não 

pense que um browser e um software de servidor da web são tudo que você precisa. 

Um complexo conjunto de ferramentas costuma ser necessário para captar 

informação, armazená-la e propiciar amplo acesso a ela. Os requisitos incluem 

ferramentas de editoração de HTML (Hypertext Markup Language) para geração de 

documentos para web, um sistema de banco de dados relacional para armazená-los, 

mecanismos de localização e recuperação e algum método para gerir o 

metaconhecimento que descreve e facilita o acesso ao conhecimento que você obteve 

(...). 

A ferramenta tem como objetivo a utilização em multiplataforma, assim a construção 

deverá ser baseada em linguagens compatíveis com a internet. Também foi considerado que a 

ferramenta pudesse ser executada em qualquer navegador. Também foi considerada a utilização 

31

do conceito Open Source, evitando dessa maneira, atrelar a ferramenta a quaisquer plataformas 

proprietárias, passíveis de cobrança de royalties. 

A ferramenta também deve garantir confidencialidade e seguranças dos dados, 

utilizando recursos para encriptação das transações entre aplicação e o banco de dados. 

Todos os elementos foram desenhados de modo a facilitar a compreensão por parte do 

usuário em cada etapa do processo, por isso, as heurísticas de Nielsen foram consideradas 

durante o desenvolvimento do protótipo. 

5.2 O Protótipo da Ferramenta 

UC1-1 - Tela inicial da área de projetos, onde usuário possui recurso de pesquisa de projetos, interação com cada 

projeto através de menu complementar. Para criar um projeto, basta clivar em "Criar". 

32

UC1-2 - Tela na qual o prefeito dá entrada no projeto que será desenvolvido. Ele insere os dados preliminares, 

conforme imagem. Caso o Secretário queira acrescentar uma informação que acha pertinente, ele altera, e o 

sistema deixa registrado. 

UC 2 - O Gestor de projetos recebe uma notificação por email e, baseado nas características do projeto, ele insere 

os documentos necessários para dar início a tramitação. 

33

UC 3-1 - Caso o Gestor de Projetos tente inserir documentos que estão fora do padrão, o sistema informa. Aqui ele 

também informa todos os documentos que serão necessários em cada etapa posterior. 

UC 3-2 - Diretor de Infra-estrutura emite parecer sobre a capacidade de a própria prefeitura de realizar a obra. 

34

UC 3-3 - Gestor de Projetos recebe e lança o parecer da viabilidade do projeto e lança todas as etapas do projeto. 

UC 4-1 - Técnico da Licitação faz a solicitação de dotação orçamentária. 

35

UC 4-2 - Diretor Financeiro aprova dotação orçamentária e emite parecer técnico. 

UC 4-3 - Engenheiro Responsável habilita tecnicamente o projeto emitindo 

36

UC 5-1 - Diretor de Licitação emite o seu parecer, informa a data de e o tipo de publicação e também a data e hora 

da abertura dos envelopes. 

UC 5-2 - Engenheiro Responsável homologa as empresas participantes 

37

UC 6-1 - Quando a empresa é declarada vencedora, uma cópia do contrato é anexado. 

UC 6-2 - Caso o usuário tentar encerrar esta etapa vai acusar que um documento deverá ser anexado. 

38

UC 6-3 - O Gestor emite parecer final e encaminha todos os documentos para o Agente Financeiro. Quando o 

parecer retornar do Agente Financeiro, o Gestor de Projetos insere parecer no sistema bem como uma cópia da 

Ordem de Serviço. 

UC 7 - Diário de Obra, onde são inseridas as informações colhidas a cada visita à obra, inclusive imagens. 

39

UC 8-1 - Observações finais de Entrega de obra preenchido pelo Engenheiro Responsável 

UC 8-2 - Gestor de Projetos deve inserir os documentos necessários a esta etapa. 

40

Obra finalizada (fim do processo). 

41

CAPÍTULO 6 

CONCLUSÃO 

Como foi visto nos casos relatados por DAVENPORT & PRUSAK (1998), inúmeras 

organizações pelo mundo estão utilizando tecnologia web para transformar seu conhecimento 

tácito em conhecimento em eficiência e melhores práticas. Assim, baseados nesses modelos 

pode-se mudar paradigmas e com baixo investimento. 

Por esta razão, o objetivo proposto na introdução, uma ferramenta de baixo custo, 

multiplataforma e uma boa IHC, para gestão do conhecimento proposta neste trabalho trará 

uma melhoria significativa, sobretudo, para organizações públicas, como prefeituras de 

pequenas cidades, que não possuem nenhum ferramental ou não dispõe de recursos de grande 

monta para melhorar a gestão de projetos de suas obras públicas. 

Para alcançar isso, a implantação da ferramenta no formato de página de internet cria 

um ambiente propício a geração do conhecimento, analogamente, um Ba, aliado a boas práticas 

e conceitos de melhoria constante, conforme proposto no modelo SECI de NONAKA e 

TAKEUCHI (1997), certamente promoverá a troca de informações fomentando o aumento do 

conhecimento disponível e conseqüentemente, reduzindo custos e trazendo mais transparência 

para o contribuinte que deseja ver seus recursos bem administrados. 

O modelo proposto neste estudo pode evoluir de maneira significativa. A partir deste 

modelo, uma organização que já estiver familiarizada com as boas práticas e os benefícios da 

Gestão do Conhecimento, ainda que utilize um ferramental básico como o que foi proposto 

neste estudo, pode agregar mineração de dados e aprimorar ainda mais as técnicas para coletar 

de dados, transformá-los em conhecimento e, posteriormente, chegar ao conhecimento. 

Outra melhoria importante que pode ser pesquisada e implementada, que também 

acrescentará grande valor e facilidade a Gestão de Informação é a integração para dispositivos 

móveis, que alinharia a ferramenta com a tendência atual de convergência tecnológica. 

42

REFERÊNCIAS 

ANGELONI, Maria Terezinha. Gestão do Conhecimento no Brasil. Brasil: Qualitymark, 

2008. 

BASSIS, Nihad Faissal. Gerência de Projetos Aplicada à Gestão do Conhecimento. Brasil: 

Brasport, 2009. 

BATISTA, Fábio F.; QUANDT, Carlos O.; PACHECO, Fernando F. e TERRA, José C., 

Gestão Do Conhecimento Na Administração Pública, IPEA - Instituto de Pesquisa 

Econômica Aplicada, Brasília, 2005. 

BESSELAAR, Peter Van Den; MICHELIS Giorgio de; PREECE, Jenny. Communities and 

Technologies 2005 Proceedings of the Second Communities and Technologies 

Conference. Milano, 2005. 

COCKBURN, Alistair. Escrevendo Casos de Uso Eficientes. São Paulo-SP – ARTMED 

Editora S/A, 2001. 2a Ed. p. 73-86 

DAVENPORT, Thomas H., PRUSAK, Laurence. Working Knowledge - How Organizations 

Manage What They Know. Harvard Business School Press, Boston, Massachusetts 

1998. 

DRUMMOND, Rivadávia Correa. Gestão do Conhecimento em Organizações: Proposta de 

Mapeamento. Brasil: Saraiva, 2008. 

DUARTE, Newton. Conhecimento tácito e conhecimento escolar na formação do professor 

(por que Donald Schön não entendeu Luria). Educ. Soc. vol.24 no.83 Campinas Aug. 

2003. . Acessado em 22 de setembro de 2010. 

FAYYAD, U., PIATETSKY-SHAPIRO G., & SMYTH P. From data mining to knowledge 

discovery: an overview. Em Advances in Knowledge Discovery & Data Mining, pp. 1- 

34. 1996a 

FAYYAD, U., PIATETSKY-SHAPIRO G., & SMYTH P. The KDD process for extracting 

useful knowledge from volumes of data. Comunications of the ACM 39(11), 27-34. 

1996b 

43

FAYYAD, U., PIATETSKY-SHAPIRO G., & SMYTH P. Knowledge Discovery and Data 

Mining: Towards a unifying framework. Em Proceedings of the Second International 

Conference on Knowledge Discovery and Data Mining. 1996c 

GELENSKI, Ana - Blog sobre gestão do conhecimento - Many Eyes IBM Research 

Acessado em 23 de setembro de 2011. 

HSM MANAGEMENT, A Gestão do Conhecimento na Prática. Pesquisa realizada pela E- 

Consulting. Edição número 42, janeiro-fevereiro 2004. 

KITARO, Nishida; Fundamental Problems of Philosophy: The world of Action and the 

Dialectical World, Tokyo: Sophia University, 1970 

MOLICH, R., and NIELSEN, J. (1990). Improving a human-computer dialogue, 

Communications of the ACM 33, 3 (March), 338-348 apud 

http://www.useit.com/papers/heuristic/heuristic_list.html acessado em 10 de setembro 

de 2011. 

MORAES, Anamaria de e MONT´ALVÃO, Claudia. Ergonomia: conceitos e aplicações. Rio 

de Janeiro (Rio de Janeiro), 2AB – Série Oficina, 2000. 2a Ed. 132p. Apud 

http://webinsider.uol.com.br/2003/01/10/usabilidade-nao-nasceu-ontem-e-tem-historia/ 

acessado em 10 de setembro de 2011 

NONAKA, Ikujiro; TAKEUCHI, Hirotaka. GESTÃO DO CONHECIMENTO, Porto Alegre 

RS. Bookman, 2008. 

NONAKA, Ikujiro; TAKEUCHI, Hirotaka, The knowledge creating company: how Japanese 

companies create the dynamics of innovation, New York: Oxford University Press, pp. 

284, 1995 

PREECE, Jenny. INTERACTION DESIGN - Beyond Human-Computer Interaction. John 

Wiley & Sons, Inc., Danvers, MA, 2002. 

REZENDE, Solange Oliveira [et al.]. Sistemas Inteligentes – Fundamentos e Aplicações. 

Barueri-SP: Manole, 2005. 

ROSINI, Alessandro Marco, PALMISANO, Ângelo. Administração de Sistemas de 

Informação e a Gestão do Conhecimento. Brasil: Cengage Learning, 2003. 

SANTOS, Antônio Raimundo dos [et al.]. GESTÃO DO CONHECIMENTO: Uma 

experiência para o sucesso empresarial. Curitiba: Champagnat, 2001, 

44

SCHÖN, D. Formar professores como profissionais reflexivos. In: Nóvoa, A. (Org.). Os 

professores e a sua formação. 3. ed. Lisboa: Dom Quixote, 1997. p. 82, apud DUARTE, 

N. Conhecimento tácito e conhecimento escolar na formação do professor (por que 

Donald Schön não entendeu Luria) Educ. Soc. vol.24 no.83 Campinas Aug. 2003. 

SECTESMG - Secretaria de Estado de Ciência, Tecnologia e Ensino Superior de Minas Gerais, 

edição de 22 de maio de 2010, Belo Horizonte. Jornal Eletrônico. Disponível em: 

. Acesso em 26 maio de 2010. 

SHIMIZU, Hiroshi, Ba-Principle: New Logic for the Real-time Emergence of Information, 

Holonics, 1995 p. 67-69 

SKYRME David J.; Knowledge Management: Solutions: The Role of Technology, ACM 

SIGGROUP Bulletin, Special Issue on Knowledge Management at Work (March 1998). 

SOMMERVILLE, Ian; Engenharia de Software. São Paulo: Pearson Education do Brasil, - 9ª 

edição, 2011. 

VON KROGH, G., ICHIJO, K., NONAKA, I. In: Facilitando a criação de conhecimento. 

Rio de Janeiro: Campus, 2001. 

WEBINSIDER, Portal de Tecnologia. Entrevista concedida em 10 de janeiro de 2003 pela Dra. 

Dra. Anamaria de Moraes sobre o tema usabilidade 

. Acessado em 14 de junho de 2010. 

45

Apêndice A - DOCUMENTO DE REQUISITOS 

Processo de Gerenciamento de Projetos 

(Convênios) 

O Fluxo 

A Ferramenta 

O que é 

Sistema para acompanhamento de projetos 

Características 

- Interface web com os seguintes recursos: 

- Cadastro de usuários com seus respectivos papéis; 

- Cadastro de Obras; 

- Cadastro de parecer/justificativa de cada etapa; 

46

- Acompanhamento das obras (Status e Cronograma); 

- Inclusão de documentos (Docs, PDFs e Imagens relativas a cada obra) e pareceres 

emcada etapa pertinente; 

- Filtros de exibição, por exemplo, por Status, Indicação ou por Período; 

Infra-estrutura Operacional 

Inicialmente, não será necessária pois a hospedagem será terceirizada. 

Principais Etapas do Processo: 

1. Indicação do Prefeito; 

2. Habilitação Técnica do Município; 

3. Elaboração da Peça Técnica; 

4. Aprovação da Peça Técnica; 

5. Licitação; 

6. Habilitação da Empresa Vencedora; 

7. Análise Final 

8. Diário de Obra; 

9. Entrega da Obra; 

10. Prestação de Contas. 

Etapa 1: Indicação do Prefeito 

Tabela RACI: R: Prefeito; A: Prefeito; C: Secretaria(s); I: Secretaria(s). 

A Atividade Projeto tem início quando uma demanda é feita ou através do Prefeito, Câmara 

Municipal, ou outra fonte, como por exemplo, um abaixo assinado da população. Para o 

gerenciamento, vamos considerar como usuário principal o Prefeito. 

Origem do Recurso 

Esta pode indicar, por exemplo, uma determinada obra a ser realizada, segundo sua 

percepção e indica a provável origem dos recursos para tal obra. Estes recursos poderão ser: 

1) Recurso Próprio (Prefeitura); 

2) Recurso Estadual (Planejamento - Estado); 

3) Recurso Federal (SICONV); 

4) Recurso Federal (Emenda Parlamentar). 

Cadastramento da Obra 

O Prefeito deverá dar entrada no sistema da referida obra ou demanda. Podem existir 

diversos tipos de demandas para o município, entretanto, dada a urgência especificamente 

em obras, vamos tratar apenas deste tópico na Gestão do Projeto. 

Os dados a serem cadastrados nesta etapa serão: 

1) Nome (Descrição provisória da Obra); 

2) Motivação (Objetivos Gerais que motivaram a obra); 

3) Secretaria(s) Envolvida(s); 

4) Localização (Endereço); 

5) Origem do Recurso (Opções acima); 

47

6) Contrapartida (S/N - Descritivo); 

7) Gestor(a) do Projeto (exibe apenas os que estão no grupo Projetos); 

8) Data Ideal para Inauguração; 

9) Observação (Observações complementares); 

A partir do preenchimento do cadastro da obra o prefeito terá duas opções: 

1) Gravar o registro no ponto em que está, neste caso o status será: “Elaborando 

Demanda”; 

2) Finalizar o processo, gravando o registro e emitindo a solicitação da demanda para 

o DP (Departamento de Projetos). Após a gravação deste registro a solicitação 

torna-se oficial mudando o status para “Demanda solicitada”; e esta demanda será 

exibida na pauta do Gestor do Projeto que fora escolhido no cadastramento e o(s) 

Secretário(s) envolvidos são notificados e deverão complementar a Motivação, que 

servirá de base para a Habilitação Técnica. Além disso, o Secretário envolvido, por 

exemplo, saúde, deverá informar os aspectos técnicos que deverão ser levados em 

consideração quando da elaboração da Peça Técnica (Campos: Observações 

Complementares e Parecer Técnico). 

Etapa 2: Habilitação Técnica do Município 

Tabela RACI: R: Gestor do Projeto; A: Gestor do Projeto; C: Jurídico, Secretária(s); I: 

Secretaria(s). 

Para receber financiamento, a obra terá que passar pelo processo de Habilitação 

Técnica do Município e, de acordo com a Origem do Recurso que a financiará, exigirá uma 

relação específica de documentos (do Prefeito e do Município): 

- Plano de Trabalho assinado pelo Prefeito; 

- Documentos do Prefeito (CPF, RG) cópia autenticada; 

- Ofício do Prefeito dirigido ao órgão concedente, justificando o empreendimento; 

- Diploma Eleitoral; 

- Atestado do Presidente da Câmara sobre o prefeito; 

- Termo de Posse (Ata da Câmara Municipal); 

- Portaria de Gestores do Convênio (Gestor Técnico e Contador); 

- Lei que Autoriza o Município a receber o tal convênio; 

- Publicação da Lei (Cópia de Jornal); 

- CRMC- Certificado de Regularidade do Município para celebrar Convênios; 

- CAUC - Regularidade SIAFI; 

- Certidão Conjunta Negativa de Débitos na União; 

Reunida a documentação, esta é encaminhada para o órgão competente para que 

este avalie. Status: “Habilitação Técnica do Município em Andamento”. 

Após esta avaliação, o referido órgão emite um parecer aprovando ou não a documentação 

apresentada. 

Ao final desse processo, após a aprovação, o Gestor do Projeto transcreve o parecer do 

órgão competente e notifica (lançando no sistema) os demais interessados no processo, 

dando uma posição sobre a Habilitação Técnica. 

> Campos preenchidos nesta etapa: 

1) Campo de texto contendo o parecer transcrito do órgão competente; 

2) Data e hora que tal parecer fora emitido; 

48

3) Demanda Trabalho Técnico Social? (Sim/Não) 

4) Relação de Documentos Necessários; 

4) Data Limite para que o projeto seja apresentado. 

Neste momento é anexado o documento que é emitido e enviado pelo órgão 

governamental que informa os prazos de entrega do projeto. 

No caso de uma obra civil, o Projeto solicita para que a Infra-estrutura elabore os 

artefatos que farão parte da peça técnica: 

- Projeto Arquitetônico; 

- Projeto Estrutural; 

- Projeto Elétrico; 

- Projeto Hidráulico; 

+ Memorial Descritivo; 

+ Planilha Orçamentária; 

+ Cronograma Físico e Financeiro; 

Esses documentos comporão a chamada Peça Técnica. 

A partir deste momento, o processo do Projeto passa a ser de responsabilidade da 

Infra-estrutura com anuência das Secretarias envolvidas e o status será: “Elaborando Peça 

Técnica”. Todas as secretarias são notificadas do estágio do Projeto. 

Etapa 3: Elaboração da Peça Técnica 



Antes de elaborar os projetos necessários ao objeto, o Secretário da Infra-estrutura 

avalia se será capaz de atender a demanda no que se refere aos projetos. Neste ponto 

podem-se desenrolar dois cenários diferentes: 

Cenário 1 

A Secretaria de Infra-estrutura possui capacitação para atender a demanda. 

Sendo assim, é nomeado o engenheiro responsável e seu respectivo registro no 

CREA. Em seguida irá providenciar os projetos e respectivas documentações. Informará 

quais serão os projetos e documentação que irá providenciar e especificará uma data para 

finalização dessa etapa. 

A Infra-estrutura providencia os artefatos que farão parte do projeto, Projeto 

Arquitetônico, Estrutural, Elétrico, etc. 

Ao final deste processo, toda a documentação é enviada para o Departamento de 

Projeto e o status será: “Peça Técnica Finalizada”. Gestor do Projeto é notificado por email. 

A partir deste ponto cabe ao Projeto, providenciar a Aprovação da Peça Técnica. 


1) Parecer indicando a finalização dos artefatos do projeto e detalhes que julgar 

necessários; 

2) Engenheiro Responsável; 

3) Registro no CREA; 

49

4) Data e hora da finalização desses artefatos. 

Cenário 2 

A Secretaria de Infra-estrutura NÃO possui capacitação para atender a demanda. 

Desta forma, informará através do sistema tal situação. Insere parecer justificando e o status 

será: “Projeto Não Capacitado”. 


1) Parecer justificando a Não Capacitação; 

2) Data e hora. 

Decisão 

Neste ponto do processo, o Prefeito escolhe se aguarda Capacitação da Infraestrutura 

ou se contrata empresa terceirizada. Caso escolha contratar empresa terceirizada, 

aprovará, através de parecer, que uma licitação seja aberta para contratação da mesma. 

Insere parecer justificando e o status será: “Aprovada Licitação de Projeto”. (Ver detalhes em 

Licitação). 


1) Parecer justificando a Licitação; 

2) Data e hora. 

Etapa 4: Aprovação da Peça Técnica 



Toda a documentação (projetos) é enviada para o órgão público para análise e 

aprovação. Esta documentação pode ser aprovada ou não, por exemplo, por falta de 

documentação ou informação. 

Este órgão emite parecer se aprovou ou não. O status será: “Aprovação de Peça 

Técnica” até que o parecer seja favorável. Quando este for aprovado, o status muda para 

“Empenhado” e a(s) data(s) limite do convênio devem ser informadas. E todos os envolvidos 

deverão ser notificados por email. 

É marcada uma data para assinatura do contrato, entre a Prefeitura e o órgão 

financiador. 

Com esse status, as secretarias envolvidas, o gestor do projeto, bem como o Prefeito, 

se for o caso, reúnem-se para planejar o andamento da obra, baseado na data de vigência do 

convênio. 

Após esta reunião, o Gestor do Projeto insere um parecer geral de planejamento 

inclusive com as datas de cada etapa. A DL é notificada para que o processo seja iniciado. 

Todos os participantes são notificados do parecer geral. 


1) Parecer que dá sustentação à Licitação; 

2) Data da Assinatura do Contrato; 

2) Insere as etapas com respectivas datas de finalização; 

50

Etapa 5: Licitação 

Tabela RACI: R: Técnico Licitação; A: Diretor; C: Jurídico; I: Diretor, Secretaria(s). 

O Departamento de Licitação faz a Solicitação de Dotação. 


1) Parecer solicitando Dotação Orçamentária; 

2) Data do Sistema; 

O status passa a ser: “Solicitação Dotação Orçamentária” 

Observação: terá que ser exibido na tela do financeiro a origem do recurso (Convênio 

ou recurso do Tesouro). 

Decisão 

O Departamento Financeiro, neste ponto do processo, avalia e aprova ou não a 

Dotação Orçamentária, cujo status será: “Aprovada Dotação Orçamentária” ou “Rejeitada 

Dotação Orçamentária”. 


1) Parecer justificando aprovação ou não da Dotação Orçamentária; 

2) Indicação da Dotação Orçamentária (pode ser mais de um Departamento ou 

Secretaria); 

3) Número da Dotação Orçamentária (Só aprova se tiver este número); 

4) Data e Hora da Aprovação. 

Em caso de aprovação da Dotação Orçamentária, o DL providencia a elaboração da 

Ordem de Serviço de Licitação e anexa o link ao projeto para que o Prefeito baixe o arquivo 

(DOC), imprima, assine para oficializar a Licitação. 

O DL escolhe a Modalidade de Licitação, que pode variar conforme o tipo do projeto. 

No caso de projetos de obras civis, as modalidades podem ser: 

Dispensa de Licitação: cujo valor vai até R$ 15.000,00 (esta modalidade dispensa edital); 

Carta Convite: cujo valor vai de R$ 15.000,01 até R$ 150.000,00 (esta modalidade requer 

edital); 

Tomada de Preços: valor entre R$ 150.000,01 e R$ 650.000,00 (esta modalidade requer 

edital); 

Concorrência: valor de R$ 650.000,00 (esta modalidade requer edital). 

Para maiores informações, consulte: http://www.planalto.gov.br/ccivil_03/Leis/L8666cons.htm 

Após redigir o Edital o encarregado do DL encaminha para o seu Jurídico solicitando 

parecer 

Neste ponto do processo o status será: “Aguardando Parecer Jurídico”. 


1) Minuta do Edital; 


51

Decisão 

O Jurídico do DL analisa e emite parecer, que pode ser favorável ou não. 


1) Parecer do Edital; 


No caso de parecer favorável, o DL publica o edital, conforme a modalidade escolhida. 

Neste ponto do processo o status será: “Em Licitação”. 

Após o recebimento do material da empresas participantes da licitação, o DL 

encaminha cada documentação para a SI para que este faça uma avaliação e promova a 

Classificação das concorrentes, habilitando ou desabilitado cada um dos concorrentes. O 

status muda para: “Habilitação das Concorrentes”. 

Etapa 6: Habilitação 

Tabela RACI: R: Engenheiro Responsável; A: Secretário Infra; C: Não tem; I: Secretário Infra. 

Decisão 

O Engenheiro Responsável analisa e emite parecer, que pode ser favorável ou não a 

cada uma das participantes. Neste caso será um campo único contendo o parecer total. 


1) Parecer da Habilitação; 

2) Data e Hora do Sistema; 

O status será: “Finalizada Habilitação de Concorrentes”. 

> Volta para Licitação 

O DL solicita parecer do Jurídico para obter aval para publicação. 

São dois cenários possíveis que virá do Jurídico: Parecer Favorável ou Parecer 

Desfavorável. O status será: “Aguardando Parecer Jurídico - Publicação”. Prazo: ? 


1) Publicação; 

2) Data de Abertura; 

Decisão 

O Jurídico analisa e emite parecer, que pode ser favorável ou não a publicação. Neste 

caso será um campo único contendo o parecer total. 


1) Parecer da Publicação; 


52

O status será: “Parecer Favorável – Publicação da Classificação” ou “Parecer Desfavorável – 

Publicação da Classificação”. 

Se o parecer for favorável, o processo segue. Caso contrário, busca-se uma solução 

recomendada pelo Jurídico até que seja favorável. Seguindo o processo (pareceres jurídicos), 

repete-se o procedimento para “Homologação”. 

Nota: Existem licitações que podem não ter todas essas fases, por exemplo, finaliza na 

“Classificação”. 


1) Observações; 

2) Data de Abertura dos Envelopes; 

Após a finalização da Homologação, o DL entra na fase de elaboração do Contrato. O 

status será: “Elaboração de Contrato”. Quando estiver pronto, marca-se a data para 

assinatura do mesmo. Quando for assinado, o processo de Licitação é finalizado. 


1) Observações Finais; 

2) Data da Assinatura; 

3) Anexar cópia do Contrato (DOC). 

O status será: “Análise Final”. Os stakeholders são notificados. 

Etapa 7: Análise Final 



O DP reúne toda a documentação e envia para análise final na Caixa Econômica 

Federal, que emite parecer aprovando a contratação ou não. O status será: “Contratação 

Aprovada”, “Contratação Reprovada”. Na maioria das vezes, a reprovação é oriunda da falta 

de documentação. 


1) Parecer da Análise Final; 

2) Data e Hora do Sistema; 

3) Anexar arquivo da Ordem de Serviço (Emitida pela Caixa Econômica) 

Este processo se repete até que o laudo seja favorável. 

Observação: O status “Contratação Aprovada” só poderá ser inserido (ex: através do 

bt “Aprovar”, quando uma imagem (OS) for anexada). Para os pareceres complementares, 

por exemplo, requisição de novos documentos ou correção de um procedimento, o parecer 

poderá ser inserido, mas não aprovado. 

Após a aprovação os stakeholders são notificados e o processo entra para a pauta da 

SI. Normalmente a SI e Secretário(s) envolvidos, fazem uma reunião de trabalho para 

planejar a obra. Inicia-se o a atividade: “Diário de Obra”. 

53

Etapa 8: Diário de Obra 

Tabela RACI: R: Engenheiro Responsável; A: Secretário Infra; C: Não tem; I: Secretaria(s). 

O DI faz um trabalho diário de acompanhamento da obra. Este acompanhamento 

resulta no preenchimento de um relatório resumido e a anexação de fotos da obra em 

andamento. 

A partir do primeiro registro no Diário de Obra, o status passa a ser “Obra em 

Andamento” 

Periodicamente, são anexados os chamados Boletins de Medição, que atestam a 

finalização de cada etapa da obra. 


1) Parecer do andamento da obra; 

2) Data e Hora da visita; 

3) Anexar imagem(ns) do andamento da obra; 

4) Anexar imagem (ou planilha?) do Boletim de Medição; 

5) Data e Hora do sistema – do momento em que o Boletim de Medição foi anexado. 

Este processo de Diário de Obra segue até a finalização da Obra e todos os 

stakeholders poderão acompanhar cada uma das etapas do diário de obra. 

Ao final da última etapa, a SI deve formalizar a entrega da obra através da 

homologação do Boletim de Medição. 

A cada Boletim de Medição, o Projeto (Prestação de Contas) deve ser notificado para 

providenciar a Prestação de Contas Parcial. 

Etapa 9: Entrega da Obra 

Tabela RACI: R: Engenheiro Responsável; A: Secretário Infra; C: Não tem; I: Secretaria(s). 

O Engenheiro Responsável deve fazer a entrega formal da obra. Para isso deverá 

anexar as imagens de todos os documentos que a obra demanda. 


1) Observações finais da entrega; 

2) Data e Hora da Entrega; 

3) Anexar imagem(ns) dos arquivos; 

A entrega só poderá ser considerada concluída, após a anexação de TODOS os 

documentos alusivos à obra, que, dependendo da obra podem ser: 

a) Laudo dos Bombeiros; 

b) Laudo da Vigilância Sanitária; 

c) Laudo do Meio Ambiente; 

d) Laudo da CETESB; 

e) Alvará de Funcionamento; 

f) CND da Empreiteira; 

g) Habite-se; 

h) Averbação (Registro em Cartório). 

Etapa 10: Prestação de Contas 

54

Tabela RACI: R: Resp. pelo projeto; A: Resp. pelo Depto.; C: Jurídico, Secretária(s); I: 

Prefeito 

A prestação de Contas se dá de duas maneiras, a Prestação de Contas Parcial, que 

ocorre ao final de cada etapa da obra, que ter sido definida ou não. E a Prestação de Contas 

Final que é realizada após a finalização da obra. 

Prestação de Contas Parcial 

No caso de Contrato de Repasse, o Projeto encaminha documentação para a Caixa 

para o Engenheiro desta possa aferir e liberar o pagamento parcial. Caso seja com verba do 

próprio tesouro o própria SI se encarrega da aferição. 

Cada obra demanda certos documentos, mas em geral são: 

a) Boletim de Medição homologado pela SI; 

b) Nota Fiscal; 

c) Guia de INSS; 

d) Declaração do Empreiteiro confirmando recebimento; 

e) Documento da Transferência da respectiva Conta do Empreiteiro; 

f) Relação de Pagamentos. 

E mais toda a documentação inicial. 

A Caixa Econômica recebe esta documentação, analisa e pode aprovar ou não. Caso 

aprove, esta homologa a prestação de contas parcial. 

O procedimento de envio de documentação, emissão de parecer com data e hora, se 

dá até que a Prestação de Contas Parcial seja homologada. 

Após a homologação, o Prefeito tem que ser notificado dando ciência de que existe 

um documento para que assine. 


1) Parecer da Caixa; 

2) Data e Hora da Aprovação (Em caso de aprovação, senão Rejeitado); 

3) Imagem (documento emitido no site da Caixa, que comprova a homologação 

Parcial). 

Prestação de Contas Final 

Na Prestação de Contas Final, o Projeto repete o mesmo processo que a Prestação 

de Contas Parcial, ou seja, envia-se toda a documentação anterior e mais alguns 

complementares: 

a) Relatório de Complemento da Situação do Objeto; 

b) Cronograma Físico Financeiro; 

c) Termo de Notificação; 

d) Consolidado de Receita; 

Ao final do processo, com a aprovação, o status será: “Obra Finalizada” e todos os 

envolvidos deverão ser notificados. 

55

Campos preenchidos nesta etapa: 

1) Parecer da Caixa; 

2) Data e Hora da Aprovação (Em caso de aprovação, senão Rejeitado); 

3) Imagem (documento emitido no site da Caixa, que comprova a homologação Final); 

4) Parecer do DP*. 

O parecer do DP será de grande importância, pois neste parecer, podem ser inseridas 

as considerações do Gestor do Projeto no sentido de melhorar o andamento do próximo 

projeto, como por exemplo, mudança de contato (nome, telefone, ou email) ou de 

procedimento no órgão que libera a verba, aspectos que não foi considerado no projeto que 

está sendo finalizado e que não pode deixar de ser considerado no próximo. 

56

Fonte de Informações 

Todas as informações aqui descritas foram colhidas em reuniões com cada um dos 

responsáveis diretos ou indiretos pelo processo e ocorreram entre os dias 19/01 e 

28/01/2011. 

Glossário 

DF 

DL 

DP 

Departamento Financeiro; 

Departamento de Licitação; 

Departamento de Projetos; 

Gestor do Projeto 

Funcionário pertencente ao grupo Projetos, responsável desde o início pelo andamento 

da obra a qual foi relacionado no cadastro inicial; 

Peça Técnica 

Documentação relativa ao projeto aprovado pelo órgão competente e que será a fonte 

de informações sobre as características desse projeto. Ela pode ser composta de vários 

artefatos, entre eles: Projeto Estrutural, Projeto Arquitetônico, Projeto Elétrico, Projeto 

Hidráulico, Memorial Descritivo, Planilha Orçamentária e Cronograma Físico e 

Financeiro. 

SI 

Secretaria da Infra-estrutura; 

SICONV 

Sistema de Gestão de Convênios e Contratos de Repasse - SICONV - órgão ligado ao 

Ministério do Planejamento. 

Stakeholder 

Qualquer pessoa interessada no processo em andamento. 

Tabela RACI 

Tabela que identifica os principais atores dentro de determinada atividade no processo 

(Acrônimo de Responsable, Accountable, Consulted e Informed). 

Responsable: Pessoa que tem a responsabilidade sobre a execução do processo; 

Accountable: Dono do processo; que dá a palavra final sobre o processo; 

Consulted: Pessoa que deverá ser consultada ANTES que qualquer decisão seja 

tomada no processo; 

Informed: Pessoa que deve ser informada que uma decisão ou ação foi tomada no 

processo; 

57

Tabelas Complementares do Sistema 

Sites Úteis 

1) Usuários (Intranet); 

2) Secretarias e Departamentos; 

3) Endereço (Tipo de logradouro, logradouro, complemento, coordenadas GPS*, etc.); 

4) Documentos (necessários aos projetos); 

(*) Não obrigatório 

http://www.planalto.gov.br/ccivil_03/Leis/L8666cons.htm 

https://www.convenios.gov.br/portal/ 

58

Prof. Me. Marcos Danilo Chiodi Martins - UniSEB

Create successful ePaper yourself

Delete template?

Save as template?