Implementando a Gestão de Conhecimento em uma Autarquia Federal por Meio da Correção de Software com Apoio da Ferramenta Redmine

LEITE, Francisco Canindé da Silva [1]

PINTO, Aurílio Guimarães [2]

FREITAS, Caio Guimarães [3]

SILVA, Francisco Eronildo da [4]

OLIVEIRA, Geveson de Souza [5]

PERES, Paulo Júnior de Jesus [6]

RIBEIRO, Dallas dos Santos [7]

ALMEIDA, Cristiany Caliri de [8]

MORAIS, Gilvanete Melo de [9]

LEITE, Francisco Canindé da Silva. Implementando a Gestão de Conhecimento em uma Autarquia Federal por Meio da Correção de Software com Apoio da Ferramenta Redmine. Revista Científica Multidisciplinar Núcleo do Conhecimento. Edição 07. Ano 02, Vol. 01. pp 301-310, Outubro de 2017. ISSN:2448-0959

Resumo

Com a escassez de informação no âmbito organizacional, principalmente na área de tecnologia da informação, fez com que a administração perdesse a capacidade de gerir seus processos e serviços de Tecnologia da Informação. Este artigo apresenta os resultados preliminares de um trabalho de iniciação de um processo de Gestão de Conhecimento que visa à melhoria dos processos internos inerentes a manutenção de software. O reuso da informação e do conhecimento possibilitará que a organização reduza a independência em relação a empresas prestadoras de serviço. A partir dos resultados, pretende-se melhorar a base de conhecimento, bem como apontar direcionamentos de trabalho para consolidar a GC ambiente organizacional.

1. Introdução

O órgão federal em estudo é responsável por conceder e gerir incentivos fiscais nos estados da Amazônia Ocidental, onde desempenha um processo vital para o desenvolvimento regional. Entretanto, os softwares que comportam as regras de negócios dos sistemas não foram evoluídos, os mesmos operam de forma crítica e com desempenho insatisfatório. Alguns fatores tais como: falta de documentação e tecnologia obsoleta, são agravantes que elevam os custos com manutenção.

Para minimizar os problemas relacionados a manutenção de software, adotou-se de maneira ad hoc a Gestão de Conhecimento (GC) por meio da criação de um repositório denominado de Base de Conhecimento (BC). Para (Takeuchi e Nonaka, 2008 apud Rebelo, 2015) o conhecimento que uma organização consegue deter e sua capacidade de criar e utilizar esse conhecimento é a habilidade central para manter uma vantagem competitiva e inovar.

Para isso, as organizações necessitam criar um ambiente no qual as pessoas compartilhem conhecimento, de modo que suscitem novos conhecimentos, processos e produtos (Schlesinger et al., 2008). Nesse contexto, a GC é um forte aliado durante a manutenção e correção de incidentes nos sistemas, pois a adoção de modelos de padronização pode minimizar a manutenção e produzir uma modificação com qualidade, diminuindo com isso os custos para a organização (IEEE 1992, apud Milev, Zampirolli e Kobayashi 2013).

Ainda (IEEE 1992, apud Milev, Zampirolli e Kobayashi 2013) a manutenção de software torna-se crítica quando é feita em sistemas legados, porque a falta de conhecimento requer mais tempo para resolução do problema. Os sistemas, em sua maioria legados operam em diferentes plataformas o que tornam a manutenção e correção dificultosas. Além disso, os incidentes requerem esforços múltiplos da fábrica de software (empresa terceirizada) elevando os custos com a manutenção, e os resultados são sempre soluções paliativas.

Este artigo tem como objetivo mostrar os benefícios ganhos com a implantação da GC no âmbito do departamento de informática do órgão em estudo, pois o conhecimento retido torna-se ativo organizacional, cabe ressaltar que órgão não dispunha de BC, por isso, as demandas sempre eram encaminhadas a empresa terceirizada. Além dessa seção introdutória, este artigo está estruturado em: seção 2 apresenta o embasamento teórico, seção 3 mostra um estudo de caso, seção 4 apresenta a metodologia, seção 5 apresenta a avaliação qualitativa, seção 6 apresenta a discussão e 7 considerações finais.

2. A Gestão de Conhecimento na Administração Pública

Sommerville (2007) afirma que o software é um produto intangível, diferentemente de outros projetos de engenharias. A GC pode ser entendida, basicamente, como “a arte de gerar valor a partir de bens intangíveis da organização” (SVEIBY, 1998).

A Gestão do conhecimento inclui qualquer atividade relacionada com a captura, uso e compartilhamento do conhecimento pela organização (OECD, 2003). Ainda (OECD, 2003), um fato interessante é que o servidor público que participa das iniciativas de GC amplia seus conhecimentos e habilidades.

A criação da GC é uma das formas encontradas para melhorar o conhecimento organizacional, dar celeridade nas resoluções dos problemas e reduzir gastos com correção de incidentes que ocorrem com certa frequência nos módulos que compõem o Sis A. Seguindo o raciocínio de (Batista, 2004 apud Coser e Carvalho, 2012) muitas organizações não conhecem o termo “gestão do conhecimento”, mas executam práticas que podem ser classificadas como GC, seguindo essa linha de pensamento, a organização utilizou-se a GC de maneira ad-hoc, uma vez que criou um repositório que serve como base de conhecimento.­­­

2.1 Manutenção corretiva de software

A manutenção de software tem por finalidade manter o funcionamento do produto de forma que o mesmo se mantenha fidedigno conforme sua especificação. Segundo Pressman (2006), existem 4 atividades de manutenção: Manutenção corretiva, Manutenção adaptativa, Manutenção evolutiva e Manutenção preventiva.

Ainda Pressman (2006), a manutenção corretiva é o processo que inclui o diagnóstico e a correção de erros do programa após o produto ter sido entregue. Com base na afirmação citada no parágrafo anterior, entende-se que a manutenção é um processo que acompanha o ciclo de vida do software para que o mesmo permaneça com suas características originais.

Entretanto, a manutenção corretiva pode ficar comprometida quando não se sabe da complexidade do produto, tais como: regras de negócios e arquitetura do software. Outros fatores que ocasionam problemas durante a manutenção é o alto custo, acúmulos de solicitações e complexidade dos sistemas (Pressman, 2006).

2.3 Redmine

O redmine que é um software livre e de código aberto, licenciado sobre os termos da GNU General Public License (GLP), essa ferramenta funciona como gerenciador de bug (Redmine, 2015). Dentro da metodologia empregada para captar as informações, por possuir múltiplas funcionalidades o redmine oferece apoio sistematizado para o processo de Gestão de Conhecimento. As principais características são:

• Suporta múltiplos projetos;
• Suporte ao Gantt (calendários e gráficos);
• Possibilidades de anexar documentos e adicionar notícias aos projetos;
• Wiki por projeto;
• Fóruns por projeto
• Feeds e notificações via e-mail;
• Time Tracking;
• Personalização dos fields por projetos;
• Integração com ferramentas de controle de versão: SVN, CVS, Git, Mercurial, Bazaar and Darcs;
• Suporte autenticação LDAP;
• Suporte a diversos idiomas;
• Suporte a múltiplos bancos de dados;
• Pode ser projetos públicos e privados

3. Cenário                              

O órgão possui vários módulos que compõe os sistemas, sendo que os mesmos se acoplam em quatro grupos, que para fins deste trabalho serão denominados (nomes fictícios) de Sis A, Sis B, Sis C e Sis D. Para que os sistemas atendam os objetivos do órgão, alguns módulos se correlacionam entre si, porém a falta de integração entre os mesmos ocasiona inúmeras inconsistências. A grande maioria dos módulos são legados, o que dificulta a manutenção e sustentação dos softwares, para este trabalho será comtemplado o Sis A.

O Sis A, é um sistema que gerência a entrada de mercadorias nacionais e, é composto por 10 módulos. O estudo se aplica ao SIS A, pois é quem comporta todas as regras de operações de ingresso de mercadoria na região da Amazônia Ocidental e também é o que apresenta o maior índice de incidentes e consequentemente custos com manutenções corretivas.

Por ser um sistema antigo que foi evoluído com base em um pré-existente na plataforma mainframe, o mesmo opera de forma crítica para a organização, a falta de conhecimento sobre o sistema por parte dos analistas da autarquia, até então, era um dos principais problemas, pois o serviço sempre foi terceirizado e o conhecimento não ficou no âmbito do órgão.  Por isso, tem se adotado soluções paliativas para resolver incidentes recorrentes, com isso surgiu a necessidade de implantar mesmo que de forma ad hoc uma BC cuja finalidade é colocar em pratica uma das quatro formas (socialização, combinação, externalização e internalização) do conhecimento proposto por (Nonaka & Takeuchi, 1997; Nonaka & Konno, apud SILVA, 2004).

A implantação da GC objetiva capturar conhecimento para o órgão de modo que o mesmo não se dissipe com a saída de pessoas do setor. Todas as demandas solicitadas geram artefatos que ficam anexadas junto a ordem de serviço, esses artefatos contêm a descrição da solução utilizadas nas resolutividades dos problemas. Logo, a mesma solução pode ser reutilizada para dar tratativa a outros problemas similares que podem a ocorrer.

3.1 Sistema Sis A

O Sis A é composto por módulos que comportam as regras de negócio do sistema, cujas características são:

• Sistema pouco flexível, parametrizado, mas devido operar em plataformas diferentes requer manutenção direta na base;
• Código escrito em Cobol, CSP e Java;
• Não usa uma base de dados padrão o que dificulta a integração com os demais sistemas;
• Os dados ficam em três bases (Oracle, SQLServer e Mainframe);
• O espaço de armazenamento do Mainframe é reduzido, por isso há varias manutenções nas tabelas;
• As regras do sistema em sua maioria são escritas na base de dados por meio de procedures que foram configurados como JOB’s;
• O sistema não contempla todas as regras definidas pela área de negócio;
• Alguns casos de uso só contemplam o caminho feliz;

Por conta dos motivos elencados surgem diariamente vários incidentes pertinentes ao Sis A, para cada incidente é registrado uma Ordem de Serviço (OS). Logo, quando encaminhadas a fábrica de software geram ônus para a o órgão. O setor de coordenação de informática adotou a GC como possível solução para viabilizar a tratativa sem geração de ônus para o órgão. No âmbito organizacional de Tecnologia da Informação criou-se a BC, por isso, os problemas e soluções inerentes ao Sis A são armazenados em um repositório.

Na organização, servidores e contribuintes utilizam os sistemas do órgão, sendo que, os primeiros atendem nas áreas de negócio e são os responsáveis por registrar os incidentes. Esses usuários geram solicitações de correções de bug, de criação ou de melhoria de software para a referida área de negócio, bem como requisições de suporte nos programas já existentes. Em função do grande número de OS, criou-se um workflow visando registrar, tratar e monitorar as solicitações.

Ressalta-se que o fluxo de ocorrência tem vários detalhes específicos inerentes ao processo, abaixo será apresentada apenas a visão macro da entrada de requisições de serviços e o uso do Redmine. A Figura 1 mostra a visão do macroprocesso denominado ordem de serviço.

Abaixo será descrito as atividades do fluxo do processo que contem 10 passos até o ciclo final:

a) Cliente: São as áreas de negócios.
1- As áreas atendem os clientes internos e registram Ordem de serviço (OS – ABERTA);
1- O solicitante da demanda avalia se o serviço foi atendido ou não. Caso tenha sido atendido (OS – SOLUCIONADO), caso contrário a mesma voltará para o passo 7 (OS – IMPLEMENTAÇÂO) e segue o fluxo normal.

b) Analistas: Responsáveis pela fiscalização
2- Os analistas fazem a análise da OS, caso tenha registro de incidentes parecidos, a demanda é tratada internamente;
O status vai para REVISÃO E IMPLEMENTAÇÃO e Vai para o Passo 10 (OS – FEEDBACK);
3- Caso não consigam resolver, a OS vai para o status (OS – APROVAÇÃO);
9- Vai para (OS – REVISÃO E IMPLEMENTAÇÃO);
4 – OS – FEEDBACK;

c) Gestor: Gestor do contrato
10 Gestor Aprova a OS
6- Gestor AUTORIZA a execução do serviço

d)Fábrica de SW: Empresa que atende as solicitações.
5 – Os Gerentes de Projeto da FSW colocam em (OS – PLANEJAMENTO e Volta para o Gestor, ver passo 6;
6 – O GP põe em (OS – IMPLEMENTAÇÃO);
8 – Quando o serviço é executado a OS é colocada como (OS – IMPLEMENTADO) e volta para os Analistas.

Com o processo de implementação da GC reduziu-se o fluxo de algumas demandas, isso se deu devido a consulta que é realizada na BC. Com a criação da BC pode se utilizar formatos e conversões (externalização) citados em Silva (2004), cuja descrição de parte do conhecimento tácito são descritos e armazenados no repositório, a Figura 2 ilustra o fluxo de melhoria do processo.

4. Métodos

Esse trabalho contempla três fases: a primeira, criou-se um ambiente para registro das atividades, a segunda, desenvolveu-se o workflow de serviço e a terceira, coletou-se os dados. A criação da BC partiu da premissa em que se fez necessário reter o conhecimento no órgão. Para isso, criou-se de forma ad hoc um ambiente onde todas as problemáticas referentes aos sistemas pudessem ficar registradas.

A primeira fase, o redmine foi instanciado para atender os registros de ocorrência de bug nos softwares da organização, os mesmos foram classificados por sistemas. A ferramenta utilizada possui suporte a múltiplas funcionalidades conforme elencados no item 2.3.

A segunda fase, criou-se o mapeamento do processo de aberturas de OS, após a homologação do mapeamento do processo, o redmine foi instanciado de acordo com o workflow de serviço proposto no mapeamento, Figura 1, a ideia para organizar os registros de OS’s por sistemas, objetivou um melhor controle sobre as demandas, a Figura 3 ilustra os papeis que fazem parte do cenário.

Conforme a Figura 3, os papeis definidos são:

1. Área: são as áreas fins do órgão que são as donas do sistema, quando detectam um incidente, registram o problema no redmine.
2. Analistas: são os responsáveis por receber a demanda que fora aberta pela área fim, analisa-las, trata-las e/ou repassar a demanda para a fábrica de software.
3. Fábrica de Software: empresa terceirizada que presta serviço para o órgão.
4. Repositório: redmine que fora instanciado de acordo com mapeamento do processo.

Ao detectar erro em um dos módulos que compõe o Sis A, a área fim registra uma OS no redmine com a descrição do problema, justificativa e evidência que comprove o bug. O analista da área de informática efetua a análise, caso a demanda já tenha sido tratada e/ou exista solicitação similar à que fora registrada, o analista tem autonomia para efetuar a correção, visto que existem fundamentos para efetuar a tratativa do incidente. Entretanto, quando a demanda é nova e/ou não existem registros, a mesma é encaminhada para a fábrica de software.

A terceira fase, realizou-se a coleta de dados referente ao Sis A, fez-se um levantamento das solicitações que foram registradas no período de 24 meses, as demandas foram coletadas de acordo com o status que se encontram registrados na Tabela 1. Para esse estudo utilizou-se um universo de 476 OS’s que foram registradas no redmine. A metodologia aplicada é a descritiva, pois é baseada em estudo de caso e análise documental (Gerhardt e Silveira, 2009).

No estágio atual do trabalho estão sendo levantados os métodos determinantes para a implantação de GC. Com base na revisão de literatura foi definida a utilização de: (a) Ambiente Organizacional (Schlesinger et al., 2008); (b) Estrutura Organizacional (Batista,2012); (c) Conhecimento Organizacional (TCU, 2014). Além disso, o Redmine está sendo otimizado para que as atividades sejam melhores gerenciadas.

5. Resultados

A Tabela 1 mostra o total de solicitação que foi registrada, cada status representa um ponto no fluxo da OS, conforme fora descrito na Figura 1. Cabe ressaltar que o valor real do total demandado fica registrado no redmine e que todas as manipulações feitas em cada demanda foram guardadas como evidências.

Para a realização deste trabalho tomou-se como base a análise de 476 incidentes que foram registrados no Redmine referente aos anos 2015 e 2016, o total dos incidentes corresponde aos módulos que compõe o Sis A.

Tabela 1: Quantitativo de Ordens de Serviço

A Tabela 2 apresenta o quantitativo de OS’s que foram encaminhadas para a fábrica de software, do total de 272 exceto as que se encontram em análise não foram encaminhadas.

Tabela 2: Quantitativo de OS’s encaminhadas para Fábrica de Software

A Tabela 3 apresenta o quantitativo de OS’s fechadas em definitivo pela fábrica de software e pelo setor que utiliza a base de conhecimento para efetuar as manutenções corretivas. Um dos benefícios alcançados com a implantação da GC foi a redução dos custos com manutenção nos softwares, para tal conclusão levou-se em consideração o total de pontos de função (PF) que seriam pagos pelas demandas, caso não houvesse uma base de conhecimento. Do total de 189 OS’s fechadas pela fábrica de software, equivalem a 1269 pontos de função gastos.

Tabela 3: Quantitativo de OS’s fechada pela Fábrica e pelo Setor

Quanto ao quantitativo de PF economizados, não tem valores estimados, no que tange a mensuração dos custos pretende-se efetuar uma contagem acurada de quanto foi economizado em termos financeiros.  Isso se dará por meio da comparação de PF’s faturados pela fábrica de software e os PF’s estimados que deixaram de ser pagos tendo em vista as OS’s que foram solucionadas tomando como base as respostas existentes no repositório.

6. Discussão

Os resultados da GC assim como a criação da BC apontam para uma melhoria no ciclo do processo de OS, conforme apresentado na Figura 2, visto que o quantitativo de OS’s abertas em sua grande maioria reportam incidentes que já tem solução.  Outro fator importante é o conhecimento que fica registrado nos artefatos gerados nas demandas, conforme fora abordado no item 3 desse artigo. Incialmente, devido à falta de conhecimento referente aos incidentes que ocorriam nos módulos do sistema, todas as demandas eram encaminhadas para a fábrica de software.

De acordo Tabela 3, 168 demandas foram resolvidas pelos analistas internos após os mesmos consultarem a BC, isso reflete que o conhecimento armazenado está sendo utilizado. O processo de GC está em fase de melhoria, mas algumas metas foram alcançadas, a principal delas foi parte da documentação de alguns módulos que compõe o sistema Sis A, com os artefatos que são entregues como resposta para cada solução de incidente. A finalidade da GC é construir uma base de conhecimento sólida que permita o aprendizado organizacional, regras de negócios e a estrutura interna dos módulos que compõe os sistemas.

Os resultados apontam uma redução de independência de conhecimento do órgão com a fábrica de software, outro fator relevante foi a celeridade na resolutividade dos problemas como representado no diagrama da Figura 2. Uma das metas a serem alcançadas gradativamente com a BC é o desacoplamento forte que a organização mantém com a prestadora de serviço no que tange ao conhecimento sobre a estrutura do sistema, ressalta-se que tal independência ainda demandará algum tempo, que não pode ser estimado no momento.

Inicialmente, uma das limitações para implantar a GC em sua totalidade é a falta de representatividade do conhecimento no âmbito operacional, pois o mesmo é tácito e poucas pessoas o detêm, são fatores contribuem para que a implementação caminhe a passos lentos. Cabe ressaltar que os resultados seriam mais efetivos se houvesse na organização uma cultura organizacional definida, também se chegou à conclusão de que a GC quando iniciada em organizações da administração pública, torna-se um dos fatores estratégicos de sucesso.

Conclusão

Este artigo relata a experiência na manutenção corretiva de software com base em casos solucionados, para essa atividade foi necessário criar um repositório onde fossem armazenados artefatos com informações referentes aos módulos do sistema Sis A. Com a criação da base de conhecimento propiciou o aprendizado sobre como analisar, avaliar e corrigir erros no Sis A. O objetivo da BC é transformar conhecimento tácito em ativo organizacional.

O processo CG está em fase de iniciação, apesar de estar em curso há dois anos, pois em órgãos públicos a implantação torna-se lenta. Até o presente momento, a GC está implantada em sua totalidade, mas a falta de cultura organizacional impacta no ciclo de vida das OS’s. No escopo deste trabalho, abordou-se a GC como forma de melhorar o conhecimento com enfoque na correção de incidentes nos módulos do sistema Sis A por meio de base legal existente.

Este trabalho mostrou que a GC é uma forma eficaz de disseminação de conhecimento no âmbito organizacional. Espera-se que os resultados deste trabalho a longo prazo, propicie melhorias em implementações futuras. Os próximos passos desse trabalho são: definir um catalogo de serviço e otimização do processo de GC.

Referências

BATISTA, F. F., Modelo de Gestão do Conhecimento para a Administração Pública Brasileira: Como implementar a gestão do conhecimento para produzir resultados em benefícios do cidadão. Brasília: IPEA, 2012.

GERHARDT, E., SILVEIRA, D. T. Métodos de Pesquisa. Porto Alegre: Editora da UFRGS, 2009.

MILEV, E. C., ZAMPIROLLI, F. A., KOBAYASHI, G. Estudo de Caso em Manutenção de Software. Revista Interdisciplinar Aplicada. V.5, n,3. p. 27-39, TRI III. ISSN 1980-7031

OECD. MISTÉRIO DA INDÚSTRIA DO CANADÁ. Measuring Knowledge management in the business sector. First steps. Paris, OECD, 2003. Portal do Ruby on Rails. <http://rubyonrails.org>. Acessado em 25 de março de 2016.

PRESSMAN, R.S., Engenharia de Software, Rio de Janeiro, McGraw-Hill, 2006.

REBELO, J., CONTE, T., “Framework de Gerência do Conhecimento e Aprendizagem Organizacional com Fatores de Influência para Organizações de Software”. WTDQS 2015.

REDMINE (2009). Redmine. http://www.redmine.org. Acessado em 25 de março de 2017>

SHELESINGER, C.C.B., REIS, D.R., SILVIA, H., CARVALHO, H., SUS, J., FERRARI, J., SKROBOT, L., XAVIER, S. Gestão do Conhecimento na Administração Pública. 1º Ed. IMAP – 2008.

SOMMERVILLE, I. Engenharia de Software. São Paulo: Ed. Pearson, 2007.

TCU. <http: //www.jusbrasil.com.br/diarios/80388051/dou-secao-1-19-11-2014-pg-117> Acessado em 25 de março de 2016.

[1] Graduado na área de computação, atua como servidor público na SUFRAMA, no cargo de Analista Técnico Administrativo – TI.

[2] Graduado na área de computação, atua como servidor público na SUFRAMA, no cargo de Analista Técnico Administrativo – TI.

[3] Graduado na área de computação, atua como servidor público na SUFRAMA, no cargo de Analista Técnico Administrativo – TI.

[4] Graduado na área de computação, atua como servidor público na SUFRAMA, no cargo de Analista Técnico Administrativo – TI.

[5] Graduado na área de computação, atua como servidor público na SUFRAMA, no cargo de Analista Técnico Administrativo – TI.

[6] Graduado na área de computação, atua como servidor público na SUFRAMA, no cargo de Analista Técnico Administrativo – TI.

[7] Graduado na área de computação, atua como servidor público na SUFRAMA, no cargo de Analista Técnico Administrativo – TI.

[8] Graduada em Administração, atua como servidora pública na SUFRAMA, no cargo Administradora.

[9] Graduada em Economia, atua como servidora pública na SUFRAMA, no cargo de Economista.