sábado, 18 de julho de 2009

Gestão do Conhecimento em Projetos de TI

Os dados podem ser considerados como sendo uma seqüência de números e palavras, sob nenhum contexto específico. Quando os dados são organizados com a devida contextualização, há a informação. Já o conhecimento é a informação organizada, com o entendimento de seu significado. A Gestão de Conhecimento cuida de agregar valor às informações filtrando, resumindo e sintetizando estas, e dessa forma, desenvolvendo um perfil de utilização pessoal que ajuda a levá-las à ação e tomada de decisão. O conhecimento explícito, ou codificado, é o conhecimento cuja transmissão se dá através da linguagem formal e de forma sistemática. Pode ser armazenado e compartilhado, logo, mais fácil de gerenciar, podendo ser armazenado em normas, manuais e livros. O conhecimento não-explícito é igual ao conhecimento tácito. O conhecimento tácito é o conhecimento que a pessoa possui, incluindo suas habilidades. É pessoal, não pode ser expressado formalmente. É intrínseco à pessoa. Bem, Takeuchi e Nonaka (os autores mais conhecidos nesta área) já falavam que o conhecimento é criado através de interações entre os seres humanos e seu ambiente. Nossas ações e interações com o ambiente criam e ampliam o conhecimento, através do processo de conversão do conhecimento tácito e explícito. Ainda segundo os dois autores, existe quatro padrões básicos para a criação do conhecimento em qualquer organização: a) De tácito para tácito quando um individuo compartilha o conhecimento tácito diretamente com outro; b) De explícito para explícito, quando o indivíduo combina partes distintas do conhecimento explícito em um novo todo; c) De tácito para explícito com a articulação do conhecimento tácito e sua conversão em explícito e, finalmente, e) De explícito para tácito, quando à medida que o novo conhecimento explícito é compartilhado pela organização, outros empregados começam a internalizá-los.

Ainda sobre Gestão de Conhecimento, aconteceu neste mês de julho o V CNEG – Congresso Nacional de Excelência em Gestão na Escola de Engenharia da UFF - Universidade Federal Fluminense em Niterói-RJ. Estive presente apresentando um artigo sobre Gestão do Conhecimento em Serviços de TI, utilizando o modelo SKMS do ITIL v3. Trata-se de um modelo incorporado no processo de Gestão de Conhecimento na Transição de Serviços. Abrange o CMDB e CMS, bem como a aplicação das melhores práticas de gestão do conhecimento em serviços de TI. Bem, tivemos vários trabalhos interessante sobre Qualidade, Inovação, Conhecimento e Projetos. Os anais do congresso estão disponíveis em: http://www.vcneg.org/. Destaca-se um artigo sobre Gestão da Qualidade Total em Tecnologia da Informação de uma aluna de pós-graduação da UFF, Priscila Fraga. Mas, o que mais me chamou a atenção foi a grande quantidade de bons artigos relacionados com o tema Gestão do Conhecimento. Um assunto bastante comentado foi a Gestão de Conhecimento em Projetos. É um tema bastante atual e que é bastante citado no mercado. Neste mês de julho, foi publicado um artigo na revista Mundo PM sobre o tema, de autoria do Professor da FGV-SP, Paulo Sabbag. Também foi publicado um artigo no Project Management Journal do PMI, de autoria de professores da Simon Fraser University. Os autores citam os tipos mais comuns de conhecimentos em projetos de TI, sendo eles: a) Conhecimento do processo (estrutura do projeto, metodologias, atividades etc.); b) Conhecimento do domínio (conhecimento da indústria, cenários atuais, problemas, oportunidades e potenciais soluções); c) Conhecimento institucional (história da organização, estrutura de poder e valores) e, finalmente, d) Conhecimento cultural que abrange a necessidade de conhecimento que os gerentes de projeto precisam para liderar times de diferentes disciplinas e culturas.

No CNEG, tive um debate interessante com um doutor em Gestão de Conhecimento pela UNB. Ele apresentou um artigo sobre a gestão do conhecimento no Banco do Brasil, com destaque para a colaboração interna, visando ganhos de sinergia em projetos. É um assunto bem interessante. Sobre este aspecto, saiu uma matéria na Harvard Business Review de abril/2009 indicando benefícios potenciais da colaboração, como por exemplo: desenvolvimento transfuncional de produtos inovadores, maior faturamento graças à venda cruzada e transferência de melhores práticas para redução de custos. No entanto, existe um alerta. O artigo, assinado por Morten Hansen da Universidade de Berkeley e do INSEAD, sugere que a colaboração entre as unidades de negócios de um provedor de TI, por exemplo, não pode ser feita só pela colaboração em si. Existe um risco nesta atividade.

"A colaboração pode trazer enormes benefícios (produtos e serviços inovadores, novas receitas). Mas também pode trazer prejuízos se os custos (incluindo atrasos devido a brigas por território) foram maiores do que o esperado."


O certo seria perguntar se a colaboração em um projeto vai criar ou destruir valor. Colaborar bem é saber quando não colaborar. Um exemplo citado pelo autor foi em propostas de outsourcing de TI. Ele citou um estudo de caso: travando uma disputa acirrada com rivais como IBM e Accenture por contratos, equipes de pré-vendas volta e meia iam pedir conselho de equipes com experiências em, digamos, uma tecnologia que seria implementada no potencial cliente. Com o estudo, o autor chegou à conclusão de que quanto maior a colaboração (medida pelo total de horas de ajuda recebida por uma equipe), pior o resultado (medido pela conquista ou não do contrato). No final, houve a conclusão que uma equipe experiente em geral não aprende tanto com os colegas como achava que aprendia, não compensando o tempo que deixara de trabalhar na formulação da proposta. O problema era, antes, determinar quando colaborar fazia sentido. O autor também sugere três tipos de colaboração em época de crise: a) venda cruzada, criando programas para a venda de outros produtos à clientela atual; b) transferência de melhores práticas, identificando dentro da empresa, unidades eficientes em certas atividades e fazendo com que outras unidades sigam o exemplo; c) inovação de produtos transfuncionais, achando maneiras de combinar tecnologias, produtos e marcas existentes para criar novos produtos e serviços. Custa menos do que criar algo do zero e a chance de sucesso é maior.

2 comentários:

  1. Bom post!
    Você poderia enviar este artigo da HBR citado ?

    ResponderExcluir
  2. Cova, claro. me envie seu e-mail: gilmarsouza.santos@gmail.com.

    ResponderExcluir