1

GESTÃO DE SISTEMAS LEGADOS UTILIZANDO TÉCNICAS DE GESTÃO DO CONHECIMENTO1

Janaine A. da Silva Vieira <janaines@terra.com.br>

Anderson Yanzer2 < anderson.yanzer@gmail.com> - Orientador

Universidade Luterana do Brasil (ULBRA) – Curso de Sistemas de Informação – Campus Canoas Av. Farroupilha, 8.001 – Bairro São José – CEP 92425-900 – Canoas - RS

29 novembro de 2010

RESUMO Com as freqüentes atualizações tecnológicas e a necessidade de uso de um Sistema de ERP (Enterprise Resource

Planning: planejamento dos recursos empresariais) um dos principais problemas enfrentados pelas empresas é a falta de documentação sobre os Sistemas Legados. Para que se obtenha um repositório das informações e do conhecimento sobre os sistemas este trabalho tem por objetivo utilizar técnicas da Gestão de Conhecimento para desenvolver um protótipo que concentre as informações e proporcione um maior conhecimento sobre os Sistemas Legados.

Palavras-chave: Gestão do Conhecimento, Sistemas Legados, Sistemas Colaborativos.

ABSTRACT Title: “Legacy systems management techniques for knowledge management”

With the frequent technological updates and the need to use an ERP system (Enterprise Resource Planning) one of the main issues facing companies is the lack of documentation on the Legacy Systems. In order to obtain a repository of information and knowledge on the systems this study aims to use techniques of Knowledge Management to develop a prototype that compile the information and provide a better understanding of the Legacy Systems.

Key-words: Knowledge Management, Legacy Systems, Collaborative Systems.

1 INTRODUÇÃO As empresas se adaptam às mudanças tecnológicas desde a Revolução Industrial, este processo se

registra até os dias de hoje independente de sua área de atuação (MOREIRA, 2007), seja com a adaptação às melhores práticas de mercado assim como a atualização constante de suas tecnologias dado o ritmo das inovações (TORRES, 1995). Elas necessitam ter a sua disposição informações confiáveis que forneçam suporte a uma tomada de decisão estratégica no menor tempo possível a fim de que anteciparem-se à concorrência. Assim, surge a necessidade de investir em sistemas mais robustos como, por exemplo: um sistema de ERP (Enterprise Resource Planning: Planejamento dos Recursos Empresariais). Como nem sempre é possível incorporar ao ERP todos os sistemas até então existentes devido ao seu nível de particularidade, o investimento torna-se muito alto, consequentemente um pequeno grupo de pessoas pode ficar mantenedora de um determinado tipo de conhecimento.

Desta forma surge a necessidade de levar em consideração que as empresas não apenas vivem de processos, mas também das pessoas, dos seus conhecimentos e de suas habilidades. Senge (2004) destaca que líderes organizacionais começam a reconhecer que é preciso repensar radicalmente a filosofia empresarial necessária ao compromisso com a aprendizagem individual citando uma colocação de Kazuo Inamori (presidente da Kyocera – líder mundial em tecnologia avançada de cerâmicas)

A força ativa são – pessoas –. E pessoas têm vontade própria, mente própria e uma forma de pensar própria. Se os funcionários não estiverem suficientemente motivados a questionar as metas de crescimento e o desenvolvimento tecnológico simplesmente não haverá crescimento, ganho de produtividade ou desenvolvimento tecnológico.

1 Proposta de Trabalho de Conclusão de Curso em Sistemas de Informação, submetida ao Curso de Sistemas de Informação da Universidade Luterana do Brasil, Campus Canoas. 2 Coordenador dos Cursos de Sistemas de Informação e Ciência da Computação na Ulbra Canoas.

2

Diante do fato de que nem todos os sistemas podem ser incorporados ao ERP, existe uma oportunidade de melhoria, no sentido de disponibilizar para toda empresa o conhecimento referente aos sistemas legados, conhecimento este que poderia ficar restrito a um pequeno grupo de usuários. Conforme destaca Senge (2004) ninguém mantém uma organização na mente. Hoje não existe nenhuma ferramenta que inventarie ou armazene conhecimento. Atualmente para os negócios, é vital estar apto à enviar e receber informações quando e onde necessárias, instantaneamente (TORRES, 1995).

Sendo assim este trabalho tem como principal objetivo desenvolver o protótipo de um sistema que mantenha a centralização de informação e conhecimento pertinente aos sistemas legados utilizando uma ferramenta que auxilie na gestão do conhecimento como, por exemplo, um WIKI. Obtendo assim uma base única que contenha além das informações sobre os sistemas legados, conhecimento que os usuários possam compartilhar de forma prática, ágil e consistente.

2 FUNDAMENTAÇÃO TEÓRICA Nesta seção serão apresentados os principais conceitos e tecnologias existentes na literatura sobre os

principais tópicos abordados neste trabalho.

2.1 Inventário de Software Na literatura atual não foram encontradas conceituações e metodologias sobre como fazer um inventário

de software, são disponibilizadas apenas especificações e sugestões dos fabricantes de softwares de inventário informando quais as características do software por ela fabricado.

No dicionário inventário é definido como: registro; catálogo por escrito e por artigos, dos bens, móveis, títulos, papéis de uma pessoa: fazer o inventário de uma sucessão. O papel em que se acham escritos e descritos esses bens. Avaliação das mercadorias armazenadas e dos diversos valores, para conhecer lucros e perdas: o comerciante deve fazer de vez em quando seu inventário (FERREIRA, 1999).

2.2 Sistemas de ERP Na década de 60, o foco dos sistemas de manufatura era o controle de estoque. Na década de 70,

mediante o menor custo de aquisição de computadores surge o MRP (Material Requirement Planning: Planejamento de Necessidades de Materiais), voltados para aplicações em empresas manufatureiras. O sistema MRP “basicamente traduzia o planejamento de produção de vendas na necessidade de materiais para produzi-los à medida que estes conjuntos e subconjuntos de componentes fossem necessários no chão de fábrica” (TURBAN, 2004).

Nos anos 80, o sistema e o conceito do planejamento das necessidades de materiais foram expandidos e integrados a outras partes da empresa e o MRP evolui para o MRP II, uma extensão do antigo sistema para o chão de fábrica e o gerenciamento da distribuição das atividades. O MRP II era usado para o planejamento e monitoramento de todos os recursos de uma empresa de manufatura: Manufatura, Marketing, Finanças e Engenharia.

No início da década de 90, o conceito do MRP foi estendido às demais áreas da organização (Engenharia, Finanças, Recursos Humanos, Gerenciamento de Projetos, etc.). Surge então o conceito de ERP (Enterprise Resource Planning: Planejamento dos Recursos Empresariais), um software para auxiliar nas importantes fases de determinado negócio (SLACK et al, 1996).

Com este avanço tecnológico as grandes empresas se deparam com um desafio: controlar os principais processos de negócio com uma única arquitetura de software em tempo real. Turban apud Sandoe et al. (2001) apontam os principais benefícios da integração de sistemas:

• Benefícios tangíveis: redução de estoque, redução de pessoal, aumento de produtividade, melhoria na gestão de pedidos, melhoria no ciclo financeiro, redução de custo de TI, redução de custo de aquisições, melhoria a gestão de caixa, aumento de receita/lucro, redução do custo de logística de transporte, redução dos custos de manutenção e do índice de entregas dentro do prazo.

• Benefícios intangíveis: visibilidade da informação, processos novos ou aperfeiçoados, receptividade dos clientes, padronização, flexibilidade, globalização e desempenho do negócio.

3

2.3 Sistemas Legados Denominação atribuída aos sistemas de uma organização que, apesar de serem bastante antigos,

fornecem serviços essenciais. Normalmente são aplicações complexas, de difícil manutenção e que pelo grau de criticidade e custo para modernização, continuam ativas. Na contramão da tecnologia, em constante evolução, estes sistemas costumam entrar em produção desatualizados tecnologicamente, devido a algum atraso no seu ciclo de desenvolvimento. É importante salientar que nem sempre a decisão de integrar um sistema legado será simples ou se configurará na melhor opção. As opções possíveis devem ser cuidadosamente analisadas, para evitar insucesso ou perdas financeiras (PINTO e BRAGA, 2004).

As empresas realizam expressivos investimento em sistema, assim, o modo de obter um retorno é a utilização do software por vários anos. O tempo de duração do sistema é variável, e os de grande porte permanecem em uso por mais de dez anos. Algumas organizações ainda dependem de sistemas com mais de vinte anos de existência. Muitos desses antigos sistemas ainda são fundamentais para as empresas, isto é, as empresas dependem dos serviços fornecidos por estes sistemas, e qualquer falha desses serviços representaria um sério efeito (PINTO e BRAGA apud SOMMERVILLE, 2003).

A falta de documentação associada a saída da equipe técnica que participou originalmente no desenvolvimento do sistema legado pode apresentar problemas como: dificuldade de compreensão das regras de negócio neles implementadas, desconhecimento das razões que levaram a determinadas decisões, problemas na estruturação do código, miscelânea de diferentes estilos de programação, obsolescência das ferramentas de desenvolvimento. Desse modo, surge a necessidade de obter conhecimento sobre o sistema legado.

2.4 Dado, informação e conhecimento Antes de qualquer definição sobre conhecimento, se faz necessária a definição e diferenciação entre

dado, informação e conhecimento, pois conhecimento não é dado nem informação, embora estejam relacionados. A Gestão do Conhecimento diferencia três grandes classes de elementos relacionados com o conhecimento dentro das organizações, são elas:

• Dado: segundo Davenport & Prusak (1998), dados são um conjunto de fatos distintos e objetivos, relativos a determinados eventos. São utilitariamente descritos como registros estruturados de transações. Por exemplo, quando um cliente vai a um posto de gasolina e enche o tanque do seu carro, essa transação pode ser parcialmente descrita como dado, mediante os seguintes eventos: quando ele fez a compra, quantos litros foram consumidos, quanto ele pagou. Os dados não revelam por que ele procurou aquele e não em outro posto, e também não podem prever a probabilidade daquele cliente voltar ao mesmo posto. Quantitativamente, as empresas avaliam a gestão de dados em termos de custo, velocidade e capacidade. Indicadores qualitativos devem possuir exatidão, relevância e clareza. Todas as organizações precisam de dados, e alguns setores industriais dependem fortemente deles.

• Informação: segundo Turban (2004) informações são dados organizados, processados, precisos e fornecidos no momento oportuno (ou seja, conclusões tiradas a partir de dados dentro do prazo de validade) e preciso (ou seja, com relação aos dados originais) Turban apud (McFADDEN et. al., 1999; WATSON, 1998).

• Conhecimento: segundo Turban (2004) o conhecimento é informação que possui contexto, é relevante e é acionável. A implicação é que conhecimento tem fortes elementos experimentais e reflexivos que o distinguem da informação em determinado contexto. Ter conhecimento implica que ele pode ser aplicado para resolver um problema, enquanto que ter informação não possui a mesma conotação. A capacidade de agir é parte integrante de se possuir conhecimento. Por exemplo, duas pessoas em um mesmo contexto com a mesma informação podem não ter a mesma capacidade de utilizá-la com o mesmo nível de sucesso. O conhecimento como recurso é valioso, pois traz a atenção novamente para o que realmente importa Turban apud McFadden et. al., 1999. A Figura 1 ilustra a representação de dados, informação e conhecimento

4

Figura 1 - Representação de Dados, informação e conhecimento TURBAN (2004).

2.5 Gestão do Conhecimento Segundo Turban (2004) a gestão do conhecimento é uma nova forma de computação colaborativa. Para

que a empresa obtenha êxito, o conhecimento, por se tratar de um capital, precisa ser trocado entre as pessoas e deve ter a capacidade de crescer.

De acordo com Davenport & Prusak (1998), o conhecimento não é algo novo. Novo é reconhecer o conhecimento como um ativo corporativo e entender a necessidade de gerir e cercá-lo do mesmo cuidado dedicado à obtenção de valor de outros ativos mais tangíveis. A necessidade de extrair o máximo de valor do conhecimento organizacional é maior agora do que no passado.

O conhecimento implica uma compreensão e experiências implícitas que podem significar a diferença entre seu bom ou mau uso. Com o tempo, a informação se acumula e se deteriora, mas o conhecimento evolui. O conhecimento tem natureza dinâmica.

Conforme Senge (2004) a aprendizagem baseia-se no conhecimento passado e na experiência, ou seja, na memória. A memória organizacional deve depender de mecanismos institucionais, e não individuais, ou então é arriscado perder lições e experiências difíceis de ganhar, quando as pessoas migram de um emprego para outro, com o passar do tempo, o conhecimento evolui com a experiência. Refere Turban (2004) que considerando-se a amplitude de tipos e aplicações, o conhecimento é informação em ação.

Organizações aprendem somente através de indivíduos que aprendem. A Aprendizagem individual não garante aprendizagem organizacional. Entretanto, sem ela, a aprendizagem organizacional não ocorre” (SENGE, 2004).

2.5.1 Tipos de conhecimento Na literatura são encontrados vários níveis de classificação dos tipos de conhecimento, esta apresentação

está ligada diretamente ao campo em que se aplicada o conhecimento. Neste trabalho aborda-se o contexto organizacional, desta forma o principal grupo a ser apresentado é a diferenciação entre o conhecimento Tácito (ou Implícito) e o conhecimento Explícito.

• Tácito: o conhecimento tácito é o conhecimento adquirido ao longo do tempo e está armazenado na cabeça das pessoas. Segundo Turban (2004) o conhecimento tácito é: o acúmulo de experiências, mapas mentais, insights, perspicácia, conhecimento especializado, know-how, segredos de negócio, conjunto de capacidades, a compreensão e o aprendizado de uma empresa, bem como a cultura organizada que nela embutiu as experiências passadas e presentes das pessoas, processos e valores que fazem parte da empresa. Em geral reside na mente das pessoas ou está embutido nas interações em grupo, dentro de um departamento ou de uma filial da empresa. O conhecimento tácito em geral envolve conhecimento especializado e alto nível de habilidades. O conhecimento tácito é difuso, não-estruturado, não possui uma forma tangível e, portanto, é difícil de ser codificado. Turban apud Polanyi (1966) sugere que é difícil colocar o conhecimento tácito em palavras. O êxito na transferência ou no compartilhamento do conhecimento tácito normalmente se dá através de associações, estágios, aprendizados, conversas e outras formas de interação social e interpessoal, ou mesmo através de simulações.

• Explícito: já o conhecimento explícito lida com o conhecimento mais objetivo, racional e técnico são as políticas, as diretrizes de procedimento, os manuais, os relatórios, os desenhos, os produtos, as estratégias, as metas, a missão e as competências básicas da empresa e a infra-estrutura da tecnologia da informação. É o conhecimento que foi codificado (documentado) em uma forma que pode ser distribuída para as pessoas sem exigir interação interpessoal, ou pode ser transformado em um processo ou em uma estratégia. O conhecimento explícito também é conhecido como conhecimento com vazamento, pela

5

facilidade com que ele parte de uma pessoa, documento ou empresa, já que pode ser documentado de forma rápida e precisa (TURBAN apud Alavi, 2000).

2.5.2 Convertendo conhecimento Segundo os autores Nonaka e Takeuchi (2008), o conhecimento é gerado na organização, a partir da

interação contínua e encadeado por quatro processos conhecidos como modelo SECI, convertendo o conhecimento tácito em conhecimento explícito e vice-versa.

• Socialização (de conhecimento tácito para tácito): compartilhar e criar conhecimento tácito através de experiência direta.

• Externalização (de conhecimento tácito para explícito): articular conhecimento tácito através do diálogo e da reflexão.

• Combinação (de conhecimento explícito para explícito): sistematizar e aplicar o conhecimento explícito e a informação.

• Internalização (de conhecimento explícito para tácito): aprender e adquirir novo conhecimento tácito na prática.

O modelo SECI de Nonaka e Takeuchi (2008) é representado na Figura 2

Figura 2 - Modelo SECI NONAKA e TAKEUCHI (2008)

2.5.3 O Ciclo da Gestão do Conhecimento Conforme Turban et al. (2004), um sistema de gestão do conhecimento deve seguir seis passos de um

ciclo. Estes passos são: • Criar conhecimento: o conhecimento cria-se à medida que as pessoas descobrem novas formas de fazer

as coisas ou que desenvolvem know-how. • Capturar o conhecimento: é preciso reconhecer o valor do novo conhecimento e representá-lo de forma

razoável. • Depurar o conhecimento: o novo conhecimento precisa ser colocado dentro do contexto correto para

que possa ser acionado. • Armazenar o conhecimento: o conhecimento útil deve então, ser armazenado em formato razoável em

um repositório de conhecimento, de modo que os outros na empresa possam acessá-lo. • Administrar o Conhecimento: o conhecimento precisa ser mantido em movimento. • Difundir o conhecimento: o conhecimento precisa ser disponibilizado em formato útil para qualquer

pessoa da empresa que dele precise. A Figura 3 representa o ciclo de Gestão do Conhecimento com base em Turban (2004).

6

Figura 3 - Ciclo de Gestão do Conhecimento TURBAN (2004)

2.5.4 Dimensões do Conhecimento Conforme Nonaka e Takeuchi (2008) a estrutura básica do conhecimento possui duas dimensões: a

epistemológica e a ontológica. O conhecimento é criado apenas pelos indivíduos. Uma organização não pode criar conhecimento sem os indivíduos. A organização apóia indivíduos criativos ou propicia contextos para que criem conhecimento. A criação do conhecimento organizacional, desta forma, deve ser compreendida como um processo que amplifica organizacionalmente o conhecimento criado pelos indivíduos, esta é a dimensão ontológica.

Quanto à dimensão epistemológica fundamenta-se basicamente a distinção entre conhecimento tácito e conhecimento explícito. O conhecimento tácito é pessoal, específico ao contexto e, por isso, difícil de formalizar e comunicar. O conhecimento explícito, por outro lado, refere-se ao conhecimento que é transmissível na linguagem formal, sistemática.

2.6 Ferramentas Wikis Primeiramente cabe definir o que é um Wiki. Segundo Zimmerly (2009) Wiki é um site web, onde

qualquer pessoa pode adicionar, modificar ou editar um determinado tipo de material. Hoje em dia o Wiki mais conhecido é a Wikipedia com mais de 9 milhões de usuários registrados e, aproximadamente, 16 milhões de páginas de conteúdo, quando o artigo do autor foi escrito. Apesar de a Wikipedia ser atualmente o wiki mais famoso, é bastante novo. O primeiro wiki foi criado em 1994 por Ward Cunningham como uma maneira para programadores trocarem idéias através da Web. Tirado da palavra havaiana para rápido, o nome rede rápida tornou-se WikiWikiWeb e com ele surgiu um novo meio de colaboração.

Como pretende-se utilizar uma ferramenta Wiki nesse trabalho, são apresentados a seguir dois softwares que trabalham com a gestão de conhecimento utilizando o Wiki como recurso de colaboração.

Wintility Next da Pixsoft3 É um software de gestão do conhecimento que se propõe a eliminar o desencontro de informações

gerado pela inundação de conhecimento que as empresas estão diariamente expostas. O software permite criar modelos de procedimentos de trabalho, através da organização lógica dos

processos, padronização de critérios na criação de documentos, compartilhamento de e-mails, recursos de busca e filtro de informações, além de publicação e acesso via web.

Toda informação adquirida se torna um bem da empresa, pois está catalogada e organizada a um clique do seu alcance. As informações passam a fazer parte de um ambiente único e compartilhado, e assim, a empresa não corre mais o risco de perder esse bem de alto valor se, por exemplo, algum funcionário se desligar da empresa. Tais processos padronizados evitam o retrabalho, poupando tempo e dinheiro.

3 http://www.pixsoft.com.br

7

CW Collaboration da Conceito W4 As tecnologias tradicionais de comunicação entre os profissionais, como e-mail, softwares de mensagens

instantâneas e intranets, tendem a facilitar o trabalho em equipe. Mas quando o foco é inovação, integração e interação, são ferramentas pouco estimulantes, e não criam um ambiente adequado para a colaboração.

A constante mudança no mercado faz com que a inovação seja a principal competência a ser desenvolvida nas empresas. Dessa forma, as corporações estão investindo em seu capital intelectual, procurando ambientes onde todos se sintam livres para expor idéias. Surge então o conceito da “rede social corporativa”, voltada a estimular a troca de informações entre funcionários, parceiros, clientes e todos os demais envolvidos.

A solução vai além da interação entre colaboradores, permitindo a organização de arquivos e melhorando os processos internos de comunicação.

O CW Collaboration possibilita a criação de grupos de trabalho com o uso integrado de mensagens, fóruns, comunidades, wiki, enquetes e informativos. Facilita ainda o intercâmbio de documentos, vídeos e imagens, além de permitir que os usuários recebam retornos e comentários de outros membros.

O aproveitamento do Wiki vem a contribuir na colaboração de grupos diversos com conhecimentos diversos, poupando tempo ao procurar e examinar diversas informações.

3 PROPOSTA DE SOLUÇÃO A solução proposta visa atender a necessidade existente na área de suporte de uma fábrica após migração

para o sistema ERP. Visando preservar a identidade da empresa, utiliza-se a expressão “Fábrica”, a partir desde momento.

Conforme citado inicialmente, após a implantação do sistema ERP grande parte do conhecimento sobre o sistema legado desta Fábrica está na forma tácita. Sendo assim percebe-se a necessidade de transformar boa parte deste conhecimento tácito em conhecimento explícito visando facilitar o acesso dos envolvidos nos processos, uma vez que os sistemas mais específicos e de relevância para a empresa ainda permanecerão em uso. Com o passar do tempo e a redução de pessoas que farão uso do sistema legado, inevitavelmente haverá perda de informação e conhecimento. A falta de documentação que detalhe melhor a ferramenta, e desligamento de funcionários da equipe técnica participante do desenvolvimento são fatores agravantes para manter uma base de conhecimento desatualizada ou até mesmo inexistente.

Desta forma o foco deste trabalho é desenvolver um sistema que concentre as principais informações sobre o sistema legado. Porém, o conhecimento tácito relativo a estes sistemas legados já é existente, mas precisa ser capturado, e necessita de uma forma efetiva de gerenciamento. Sendo assim, para gerenciar este conhecimento tácito é proposta uma técnica de gestão de conhecimento baseado em um sistema Wiki que mantenha a centralização das informações e proporcione um maior conhecimento sobre o sistema legado, deixando mais conhecimento ao alcance de todos. Conhecimento este que pode ser: o que a aplicação faz; no que ela impacta caso pare de funcionar; quem são os responsáveis operacionais (usuário chave); os desenvolvedores, como fazer determinada operação; a localização do banco de dados, problemas e soluções recorrentes, etc. Obtendo assim uma base de conhecimento disponível e ao acesso de todos de forma prática e ágil. O protótipo estará sendo desenvolvido de acordo com a metodologia apresentada a seguir.

4 METODOLOGIA PROPOSTA O desenvolvimento deste trabalho seguiu duas etapas. A primeira envolveu os cadastros e gerenciamento

das informações sobre os sistemas legados e a segunda uma ferramenta que visando proporcionar algum tipo de gestão do conhecimento para o problema apresentado através de um wiki.

A metodologia utilizada para o desenvolvimento da etapa de gerenciamento das informações sobre o sistema legado seguiu o modelo do Ciclo de Vida de Software apresentado por Pressman (2006), representado na figura 4.

4 http://www.conceitow.com.br

8

Figura 4 - Ciclo de Vida de Software PRESSMAN (2006)

4.1 Metodologia para o Desenvolvimento Esta seção tem como por objetivo detalhar as fases envolvidas no desenvolvimento lógico do protótipo.

41.1 Engenharia de Sistema A Engenharia de Sistema é o estudo preliminar, neste momento são identificadas as atuais deficiências e

estabelecidos os objetivos do sistema. Neste trabalho foi utilizada a técnica de entrevista para fazer este levantamento.

• Levantamento de Requisitos: o levantamento de requisitos fundamentou-se na técnica de entrevista. A entrevista foi realizada com a área de suporte da Fábrica a fim de obter maiores informações sobre a necessidade de acesso a documentos que especifiquem as funcionalidades e resoluções de problemas apresentados nos sistemas legados. Durante o processo de entrevista identificou-se que atualmente não há um padrão de armazenamento instituído na área, existem os analistas mais antigos que possuem este conhecimento. Outros possuem um caderno de anotações onde descrevem a forma como tal procedimento precisa ser executado, outros já possuem estas anotações em formado digital e divulgam por e-mail para os demais analistas. Todos do grupo identificam que isto acarreta uma série de problemas dentre os principais deles os técnicos citam o tempo de resposta entre identificar um determinado problema e aplicar a sua devida solução, quando alguém já passou pela situação e se recorda, a solução é quase que imediata; caso contrario, procede-se uma consulta nos atuais canais (cadernos, arquivos eletrônicos, e-mails). Para a agilização dessa busca e visando uma resolução ou até mesmo mais de uma alternativa, a área necessita de um canal eletrônico tipo portal, ou um sistema em que todos os envolvidos na operação pudessem postar os seus conhecimentos e disseminar a todos que porventura viessem necessitar. Tal recurso agilizaria o suporte assim como reduziria a demanda, pois até mesmo os usuários poderiam consultar e sanar as suas dúvidas.

4.1.2 Análise Nesta etapa é preciso haver um entendimento do software, ou seja, depois de avaliar os problemas atuais

e as informações desejadas (entradas e saídas), começando assim a sintetizar uma solução. De acordo com o levantamento realizado o protótipo está modelado da seguinte forma, seguindo a

conceituação apresentada por Rezende (1999): • Modelo ER: seu principal propósito é representar os objetos de dados e suas relações. O ER deste

trabalho apresentou alterações em relação ao proposto no TCCI. A Figura 5 representa o modelo ER do protótipo.

9

Figura 5 - Modelo ER do protótipo

• Diagrama de classes: é um diagrama que representa as classes de um objeto apresentando os seus atributos e as operações possíveis sobre ele.

• Diagrama de caso de uso: um diagrama de caso de uso contém elementos modelados para um sistema: atores e casos, mostrando os diferentes relacionamentos entre os seus elementos.

• Diagrama de Seqüência: diagrama que mostra para um cenário em particular, os eventos externos gerados por um ator, seus pedidos e os eventos internos ao sistema.

Estes três diagramas já foram apresentados na proposta de TCCI.

4.1.3 Projeto A atividade de projeto preocupa-se com o desenvolvimento de uma hierarquia apropriada dos módulos

de programas e interfaces, estrutura de dados, arquitetura de software, processos e caracterização de interface. O processo de projeto traduz as exigências em uma representação do software que pode ser avaliada quanto à qualidade antes que a codificação se inicie.

Através do processo de levantamento de requisitos foi possível identificar a interface básica do protótipo, uma interface clara, objetiva e intuitiva.

4.1.4 Codificação O projeto deve ser traduzido de uma forma legível por máquina. A etapa de codificação é a responsável

por executar esta tarefa. Como parte do desenvolvimento que ocorrerá dentro da empresa, existe algumas limitações, dentre elas,

a principal refere-se às licenças de aplicativos, em decorrência, optou-se por ferramentas agregadas ao pacote Microsoft.

4.1.5 Testes Assim que o código for gerado, inicia-se a realização de testes do programa. O processo de realização de

testes concentra-se nos aspectos lógicos internos do software, garantindo que todas as instruções tenham sido testadas, e também nos aspectos funcionais externos, ou seja, realizando testes para descobrir erros e garantir que a entrada definida produza o resultado exigido.

4.1.6 Manutenção Provavelmente o software sofrerá mudanças depois de sua entrega, seja por erros encontrados, para

atender mudanças do ambiente, ou porque, acréscimos funcionais ou de desempenho são necessários, a

10

manutenção de software se reaplica à cada uma das etapas precedentes do ciclo de vida de um programa existente.

4.2 Metodologia para a Gestão do Conhecimento Nesta seção apresenta-se o ciclo de gestão do conhecimento proposto para este trabalho fundamentou-se

em Turban (2004). Esta metodologia possibilita associar o sistema que fará o gerenciamento das informações relacionadas aos sistemas legados com a ferramenta de gestão do conhecimento proposta. A seguir são apresentadas as etapas da metodologia proposta:

4.2.1 Capturar conhecimento Nesta etapa será preciso identificar em que este conhecimento descoberto poderá vir a contribuir para as

atividades realizadas. Sendo assim o objetivo é que este conhecimento tácito seja inserido no Wiki através do sistema GSL (Gestão de Sistema Legado) tornando-se um conhecimento explícito.

A fábrica analisada possui um grupo de qualidade muito atuante dentro da empresa e fortemente incentivado pela alta gerência, este pode ser um aliado no momento de divulgar o ganho corporativo de ter a informação acessível a todos.

4.2.2 Depurar o conhecimento A partir do momento em que se tem acesso ao conhecimento explicito é possível que os responsáveis

capacitados para isso possam avaliá-lo e sistematizá-lo dentro das necessidades da empresa, identificado qual o seu valor dentro do contexto operacional, e adequando às normas corretas de execução.

4.2.3 Armazenar conhecimento Após ter sido gerado o conhecimento, capturado e refinado, o mesmo deverá ser armazenado a fim de

que outras pessoas tenham acesso a este conhecimento e possam executar os processos da forma mais correta possível. Este sistema estará armazenado no Wiki em um servidor dentro da fábrica com as suas devidas regras de acesso, sendo que seus funcionários poderão acessá-lo de quaisquer de suas filiais.

4.2.4 Administrar o Conhecimento Nesta etapa existem dois pontos bem importantes para avaliação, o primeiro está ligado à confiabilidade

de uma ferramenta colaborativa. Uma vez que qualquer pessoa possa imputar dados para o Wiki, é necessário que o facilitador e o analista responsáveis pela aplicação, façam uma avaliação semanal do que foi publicado, e uma avaliação semestral da continuidade e aplicabilidade do processo publicado. O segundo ponto é acompanhar a evolução da empresa em utilizar esta nova forma de gestão do conhecimento, neste item é valido um trabalho paralelo de marketing divulgando o ranking dos processos mais utilizados e dos colaboradores que mais publicam ou realizam acesso a ferramenta.

4.2.5 Difundir o conhecimento A base de conhecimento armazenada no Wiki precisa estar armazenada, atualizada e com as devidas

restrições de acesso dentro da fábrica, ou seja, todos que executam um determinado processo ou venham executar precisam ter acesso aos conhecimentos já existentes e caso identifiquem uma forma otimizada de executar utilizem este fluxo de geração de conhecimento para refiná-lo. Para obter este nível de resposta pode-se fazer uso do ranking de consulta para periodicamente publicar na intranet os mais acessados incentivando assim o uso da ferramenta tanto em nível de consulta quando ao de publicação.

6 SOLUÇÃO APRESENTADA

6.1 Gestão de Sistemas Legados Conforme já apresentado este protótipo foi desenvolvido baseado na metodologia de desenvolvimento

proposto por Pressman (2006). Após realizada a analise dos requisitos, foi possível identificar o conjunto de informações necessárias para atender as necessidades de primeira instância.

Diante das necessidades identificadas o protótipo apresenta as operações básicas de gerenciamento das informações.

• Cadastro: nesta operação é possível realizar o cadastro base dos três principais elementos que compõem o protótipo sendo estes o cadastro de: sistema, analista e facilitador, além dos cadastros complementares de: cargo, departamento (que estão diretamente ligados ao analista e facilitador), situação e área de

11

atuação (que por sua vez estão interligados diretamente ao sistema). Sendo que as últimas quatro bases de cadastro estão neste primeiro momento bem simples para atender as necessidades iniciais de avaliação, mas que conforme as necessidades de negócio podem ter o cadastro de informações ampliado. Nas Figuras 6 e 7 são apresentadas as telas de cadastro de sistema e de analista; o cadastro de facilitador é similar ao de analista, ou seja, só muda o ator, mas a estrutura do conjunto de informações utilizada é a mesma.

Figura 6 – Tela do GSL para Cadastro de Sistema

Figura 7 - Tela do GSL para Cadastro de Analista

• Consulta (listagens): nesta operação são apresentados dois tipos de listagem: a sem filtro apresentada na consulta de analista e facilitador. E a listagem com filtro, que estão presentes na consulta de sistemas com as seguintes opções por: analista, facilitador e situação. Na Figura 8 é apresentada a tela de listagem de sistema filtrada por analista nas outras duas opções disponíveis (facilitador e situação) a apresentação dos dados é a mesma, muda apenas o tipo do filtro.

12

Figura 8 - Listagem do GSL com a opção de filtro.

É através das listagens de sistema que será possível acessar os Wikis cadastrados, esta acessibilidade será apresentada na seção 6.3. A Figura 9 apresenta a listagem GSL sem filtro.

Figura 9 - Listagem do GSL sem filtro

• Alteração: nesta operação é possível visualizar os dados atuais e efetuar alterações cadastrais do sistema, analista e facilitador.

• Exclusão: nesta operação é apresentada a listagem de analista e facilitador, sendo possível efetuar as suas exclusões. Para isso é necessário que os mesmos não estejam vinculados a nenhum sistema, em caso positivo será necessário efetuar uma alteração cadastral denominando um novo responsável para que seja possível realizar a exclusão da base de dados. Nesta operação não há a exclusão de sistema, pois o mesmo deve ser desativado da base de dados.

6.2 Ferramenta Wikia O Wikia é um portal que oferece hospedagem gratuita para o armazenamento de publicações

colaborativas disponível na URL: www.wikia.com. Baseado em conteúdo livre de direitos autorais, ou seja, as informações publicadas no wiki podem ser copiadas e reutilizadas por qualquer outra pessoa. Sendo assim para o desenvolvimento deste trabalho foram utilizados dados ficticios para preservar as informações da empresa em estudo.

No decorrer do trabalho outra ferramenta foi avaliada, a Wikispaces, disponível na URL: www.wikispaces.com. E esta por sua vez é licenciada sendo instalável e gerenciavel pela empresa que adquire. O Wikispaces disponibiliza o download para avaliação por um período de 30 dias o que tornou o seu uso inviável para o desenvolvimento do trabalho. Já para o uso corporativo o Wikispaces pode vir a tornar-se um recurso viável devido ao seu gerenciamento ser interno e estar protegido pelas politicas de segurança da empresa.

Desta forma foi escolhida para este trabalho a ferramenta Wikia por apresentar características mais adequadas ao que se propõe no momento.

6.3 Acessando o Wiki pelo GSL No GSL o acesso ao Wiki para cadastros e consultas está disponibilizado através da opção de listagem de

sistema, em que clicando sobre o sistema desejado o mesmo será direcionado para o site do Wikia. O wiki cadastrado no portal da Wikia para armazenar a base de conhecimento deste trabalho é o Wiki

Sistema Legados o qual está disponível na URL: http://pt.legado.wikia.com/wiki/Wiki_Sistema_Legados. A

13

Figura 10 representa a tela da listagem do GSL com linck para acesso ao wiki.

Figura 10 - Listagem do GSL com o link para acesso ao wiki

6.4 Política de uso do Wiki O objetivo de desenvolver uma aplicação que faça uso de um wiki é ter as informações unificadas e

condições de fazer uso de colaboração entre as pessoas e, principalmente, tornar corporativo este conhecimento tácito adquirido ao longo do tempo, transformando em conhecimento explicito, porém este objetivo não é atingido se não houver responsáveis elegidos, que devem ter a atribuição e o comprometimento de validar as informações imputadas no sistema, desta forma todo o sistema possui uma analista e um facilitador responsável por ele, visando assim a confiabilidade das informações disponibilizadas para a empresa como um todo.

6.5 Estrutura de publicação A estrutura esquematizada para o wiki está dividida em três tópicos macros caracterizada da seguinte

forma: • Informações gerais: os itens apresentados neste nível caracterizam o sistema, ou seja, é através deste

tópico que o usuário terá uma visão geral do sistema. • Informaçõe operacionais: as informações inseridas neste tópico descrevem processos para a execução

de terminada tarefa. • Dados técnicos: este tópico é para uso da equipe de TI para que a mesma possa atuar sobre a

manutenção do sistema. No ínicio do projeto quando foram realizadas as entrevistas para identificar os problemas existentes,

também foram pontuados os itens de necessidade primária de conhecimento, aqueles em que numa situação de criticidade fazem a diferença, ou seja, agilizam a tomada de decisão. Desta forma foi possível definir a estrutura básica para criação dos wikis:

Estrutura sugerida:

1 Informações Gerais

1.1 Descrição

1.2 Finalidade

1.3 Área de Atuação

1.4 Analistas Responsáveis

1.5 Facilitadores de Área

1.6 Tipo de Impacto

2 Informações Operacionais

2.1 Modulos do Sistema

2.2 Procedimentos

3 Informações Técnicas

3.1 CheckList para Produção

3.2 Cadastrar Sistema no Portal

14

3.3 Perfis

3.4 Niveis de Acesso

3.5 Permissões NTFS

3.6 Servidores

3.7 Web site

3.8 Requisitos de Instalação

3.9 Configurações Adicionais

Vale salientar que a estrutura apresentada acima, é uma sugestão sendo esta de totalmente flexível, uma vez que a proposta do wiki é contribuir para a aquisição de conhecimento, uma estrutura enrijecidas iria inibir os colaboradores de fazerem uso da mesma, sendo assim a estrutura sugerida pode ser alterada conforme necessidade de cada sistema.

6.6 Cenário de Teste Os testes de uso da ferramenta foram realizados na Fábrica no período de outubro a novembro, por um

grupo de seis pessoas pertencentes aos seguintes grupos: 2 usuários, 2 facilitadores de área e 2 analistas. A escolha e divisão deste grupo tinham por objetivo obter de funções, interesses e percepções diferentes

as formas de explorar a ferramenta para que melhorias sejam aplicadas, sendo assim os testes avaliativos visavam três objetivos:

• primeiro, identificar se o conjunto de informações e operações básicas contidas no GSL atende de forma prática as necessidades iniciais de acesso a ferramenta;

• segundo, observar a reação do grupo de teste ao ter o primeiro contato com a ferramenta, assim como a aderência de uso durante o período de avaliação para postar o conhecimento até então tido como tácito para o Wiki e torna-lo um conhecimento explícito e que esteja ao alcance de todos;

• terceiro, identificar pontos de melhoria da ferramenta.

6.7 Exemplo de Uso – Instalação do sistema MCS para um usuário Nesta seção apresenta-se um exemplo prático utilizando o GSL para acessar o wiki de um sistema, o

MCS. A equipe de suporte técnico da Fábrica recebe uma solicitação para efetuar a instalação do sistema MCS,

com a disponibilidade do GSL: - o técnico acessará o GSL; - consultará a listagem de sistema; - irá clicar sobre o link disponibilizado no sistema MCS;

A Figura 11 apresenta a tela de representação da listagem do GSL com link para o acesso ao wiki.

Figura 11 - Listagem do GSL com o link para acesso ao wiki

• a URL do wiki será aberta;

• o técnico acessará o wiki desejado, neste caso o do MCS;

• já dentro do wiki o técnico irá até o tópico “Informações Técnicas”, neste instante será possível

15

consultar toda a base de conhecimento do MCS disponibilizada;

• por fim irá executar o procedimento de instalação do sistema, fazendo assim uso do conhecimento que alguém registrou.

A Figura 12 apresenta a tela do Wiki do sistema MCS, sobre informações técnicas

Figura 12 – Wiki do sistema MCS – Informações Técnicas

Como todo o processo de instalação, nosso usuário irá precisar saber também quais são os recursos disponíveis no sistema e como deverá fazer uso do mesmo. Desta forma no wiki do MCS o técnico irá acessar o tópico “informações operacionais”, onde estão descritos os processos de uso do sistema, neste exemplo o sistema possui uma apostila publicada no sistema Acervo. A Figura 13 apresenta o wiki do sistema MCS.

16

Figura 13 - Wiki do sistema MCS – Informações Operacionais

Neste momento existem duas possibilidades, o técnico continuar instruindo o usuário através do wiki, acessando o link do sistema Acervo acessível no MCS, ou orientar o usuário a:

• acessar o GSL; • consultar a listagem de sistemas; • acessar o link do sistema Acervo o qual irá redirecionar para o wiki.

Em ambos os casos o acesso ao wiki será no mesmo tópico “Informações Operacionais”. A Figura 14 apresenta a tela do wiki do sistema acervo.

Figura 14 - Wiki do sistema Acervo – Informações Operacionais

Nesta segunda etapa o ideal é que o usuário seja incentivado a acessar o GSL e fazer uso do wiki para obter o conhecimento ou orientação desejada, atingindo assim o objetivo ao qual a ferramenta se propõe.

6.8 Recursos do Wiki O wiki possui recursos que visam auxiliar na interatividade entre os usuários que realizam algum tipo de

publicação, dentre eles os principais são: o histórico de edições realizadas e o comparativo de alterações. Com estes dois recursos torna-se mais fácil o controle do que está sendo publicado e por quem está sendo publicado. A Figura 15 representa a tela de apresentação de histórico resumido do wiki.

17

Figura 15 – Apresentação de histórico resumido do wiki

1. Neste espaço é possível verificar quem foi a ultima pessoal que realizou uma edição no wiki corrente;

2. Neste espaço é possível verificar quem realizou as últimas alterações no wiki como um todo. Se a mesma for expandida é possível verificar quais seções foram alteradas.

A Figura 16 demonstra a tela de apresentação de histórico expandido do wiki.

Figura 16 – Apresentação de histórico expandido do wiki

Nas Figuras 17 e 18 do wiki é possível verificar o registro das alterações realizadas e efetuar a comparação de duas delas para visualizar as alterações feitas.

1

2

18

Figura 17 – Apresentação de histórico do wiki

Figura 18 – Comparativo de alterações realizadas no wiki

19

7 CONCLUSÃO Diante da necessidade de acompanhar o avanço tecnológico, e disputar mercado com os concorrentes, as

empresas precisam estar cada vez mais conhecedoras de seus processos. Desta forma apenas sistemas e tecnologias de ponta não atendem mais esta necessidade. O capital humano vem sendo cada vez mais importante para o desenvolvimento das pessoas e dos negócios. Tornando-se necessário estimular as pessoas, mostrando-lhes os benefícios da externalização de informação como, por exemplo, o ganho de tempo na busca de informações. Este ganho de tempo pode gerar tanto melhorias internas quanto oportunidades de negócio.

Os dados utilizados na base de construção deste trabalho tiveram como enfoque, o referencial teórico apresentado, bem como as informações adquiridas, as quais possibilitaram o desenvolvimento do GSL – Gestão de Sistema Legado como o objetivo de contribuir para a empresa como um instrumento associativo a uma ferramenta wiki, possibilitando a organização de conteúdo, centralizando e padronizando as informações. Compartilhando o conhecimento e estimulando a troca de informação e experiência. Além de estimular a inovação, fornecendo os recursos ideais para fomentar o espírito inovador e participativo entre os seus colaboradores. A introdução das praticas de gestão de conhecimento pode melhorar o controle de processos, facilitando o seu acesso, além de disponibilizar de forma prática informações detalhadas sobre como realizar determinada tarefa.

O motivo de usar o wiki neste trabalho se dá ao fato das pessoas poderem colaborar em uma base única, através de uma simples ação: a edição das páginas existentes, como se estivessem dando continuidade na digitação de um documento do word. Ao contrário do que acontece em um fórum de discussão, por exemplo, onde não existe a possibilidade de editar uma publicação para postar alterações. Na necessidade de agregar informação a única alternativa é realizar uma nova postagem, sendo que o cenário ideal seria um documento único com todas as considerações, contribuições reunidas, eliminado possíveis redundâncias e gerando assim um único documento onde o conteúdo tenha começo, meio e fim.

Sendo assim a área de gestão do conhecimento será vital para empresas que almejam um diferencial competitivo perante as demais e possuir conhecimento e saber o que fazer com ele é sem dúvida um diferencial. Baseado neste fato, as ferramentas de gestão do conhecimento ganham maior importância, e aumentando sua necessidade de forma que as empresas consigam resultados positivos.

Como expectativa de trabalho futuro deste projeto, a meta é que após o amadurecimento interno o mesmo possa ser expandido e utilizado para todos os sistemas em uso na empresa. Numa visão mais ampla o wiki tem condições de atender quaisquer necessidades de controle de processos ou documentos de cada área da empresa. REFERÊNCIAS CONCEITO W. CW Collaboration. Disponível em < http://www.conceitow.com.br > Acesso em 22 abril 2010.

DAVENPORT, Thomas H; PRUSAK, Laurence. Conhecimento empresarial. Rio de Janeiro: Campus, 1998.

FERREIRA, Aurélio Buarque de Holanda. Novo dicionário Aurélio: século XXI. SP. Nova Fronteira, 1999.

NONAKA, Ikujiro; TAKEUCHI, Hirotaka. Criação do conhecimento na empresa. Rio de Janeiro: Campus 2008.

MOREIRA, Bernardo Leite, Gestão do conhecimento. 12 nov. 2007. Disponível em <http://www.administradores.com.br/informe-se/artigos/gestao-do-conhecimento/20385/> Acesso em 12 abril 2010.

PINTO, Herbert Laroca Mendes; BRAGA, Jose Luis. Sistemas legados e as novas tecnologias: técnicas de integração e estudo de caso. Disponível em <http://www.ip.pbh.gov.br/ANO7_N1_PDF/IP7N1_mendespinto.pdf> Acesso em 22 abril 2010.

PIXSOFT. Wintility. Disponível em <http://www.pixsoft.com.br> Acesso em 22 abril 2010.

PRESSMAN, Roger. Engenharia de software. São Paulo: Makron Books, 2006.

REZENDE, Denis. Engenharia de software e sistemas de informação. Rio de Janeiro: Brasport, 1999.

20

SLACK, Nigel, et al. Administração da produção. São Paulo: Atlas, 1996.

SENGE, Peter M. A Quinta disciplina: arte e prática de organizações que aprendem. Rio de Janeiro: Best Seller, 2004.

TORRES, Norberto A. Competitividade empresarial. São Paulo: Makron Books, 1995.

TURBAN, Efraim; McLEAN, Ephraim; WETHERBE, James. Tecnologia da informação para gestão. 3.ed. Porto Alegre : Bookman, 2004.

ZIMMERLY, Bill. Entendendo o software wiki. 21 abr. 2009. Disponível em <http://www.ibm.com/developerworks/br/library/os-social-mediawiki/ > Acesso em 22 abril 2010.