A área financeira da SEOP/DECOM é composta por três macro funções: Contabilidade, Tesouraria e Programação e Controle. Das três, apenas a área de Programação e Controle conta com sistema informatizado. Deseja-se ampliar o nível de informatização para as demais macrofunções da área.

1.1 Objetivo

O objetivo deste projeto é o desenvolvimento de uma nova solução, que atenda a todas as funções da área financeira do DECOM, ampliando, desta forma, as funções apoiadas por sistemas de informação.

1.2 Caracterização do Problema

O sistema que atualmente suporta as atividades operacionais da Gerência Financeira do DECOM - GEF, foi desenvolvido em Clipper, funciona sob DOS, e está precisando de alterações em algumas rotinas, além de necessitar que sejam desenvolvidas novas funções.

Várias das funções do sistema atual foram desenvolvidas com redundância de dados e processos não integrados. Além de oferecerem resistências a evoluções desejáveis, o desenho do sistema atual não permite o intercâmbio de dados com outras aplicações.

Entre as novas funções necessárias podemos citar: controle de faturas a pagar e a receber, controle de contrato OP – Obras Públicas e interface com o sistema SIAF.

Todo o ambiente do DECOM vem evoluindo tecnologicamente. Novas ferramentas estão sendo disponibilizadas. Também está sendo necessário que os sistemas sejam integrados, ou possam intercambiar informações com confiabilidade e segurança.

O NII – Núcleo de Informática e Informações da SEOP – Secretaria de Estado de Obras Públicas coordenou um trabalho de modelagem de processo com a área financeira da SEOP/DECOM – Departamento Estadual de Construção de Obras e Manutenção, cujo produto está anexado no final deste trabalho. Durante as reuniões realizadas, foram identificados os seguintes fatos ou problemas que devem ser considerados quando do desenvolvimento de novo sistema:

1. a falta de padronização dos históricos causa, muitas vezes, dubiedade nas informações prestadas;

2. os procedimentos para controle e atualização da ficha financeira são totalmente manuais. O levantamento de algum dado exige às vezes a pesquisa a arquivo morto (dados anteriores a 1998). Muitas vezes também a ficha é retirada para consulta e não é devolvida, tornando trabalhosa cada pesquisa para levantamento de informações;

3. a falta de melhor definição das atribuições de cada área faz com que muitas vezes a mesma tarefa seja executada em duplicidade e de forma não padronizada;

4. Boletim de Crédito é emitido manualmente, sem integração com a Ficha Financeira e a transferência de recursos;

5. saldo financeiro das OP´s diverge do saldo contábil;

6. as transferências de saldos entre as OP´s nem sempre são informadas à Contabilidade;

7. os lançamentos nem sempre acontecem durante o mês de competência;

8. os "empréstimos" entre contratos OP não são contabilizados. Existe somente registro financeiro dos mesmos;

9. a multiplicidade de contratos e contas correntes de um mesmo órgão dificulta o controle tanto financeiro como contábil;

10. os lançamentos contábeis extra-orçamentários são feitos manualmente e em duplicidade, nos sistemas financeiro e contábil, não acontecendo no momento da ocorrência. Quem efetua o lançamento nem sempre é a mesma pessoa que o gera;

11. nem sempre as entradas e saídas de dinheiro são informadas à Contabilidade;

12. a posição financeira nem sempre é atualizada durante o mês de competência. Isto provoca, às vezes, o aparecimento errôneo do registro no mês em que o documento chega ao GEF;

13. objeto referente às obras é pouco claro;

14. controle das cauções, em dinheiro ou em títulos, é totalmente manual, tornando difícil identificar algumas condições básicas como títulos vencidos ou a conta bancária;

15. sistema hoje utilizado, em linguagem Clipper, não permite integração fácil com outras bases de dados, como o Acompanhamento de Obras, desenvolvido em Lotus Notes. Também não é possível a geração de relatórios especiais, sem prévia definição, para informações à Diretoria;

16. não existe integração com o Sistema Integrado de Administração Financeira (SIAF), em mainframe. Isto também é causa de duplicidade em lançamentos.

1.3 Alternativa de Solução Escolhida

Foram arroladas 3 (três) alternativas de soluções sendo:

• aquisição de Solução Disponível no Mercado: esta solução foi descartada em função de não ter sido encontrada uma solução de mercado que atenda a todas as necessidades. Foi iniciado o trabalho de especificação do problema, visando o desenvolvimento de um sistema específico;

• licitar a Contratação de uma Empresa para Desenvolver o Projeto: a contratação específica de uma empresa para desenvolver o sistema, seja pelo DECOM, deverá ser precedida por um aprofundamento do estudo do problema e da solução esperada, visando definir uma forma de medida do projeto, cuja unidade é conhecida como "Ponto por Função". O número de Pontos de Função determina o porte do sistema e deve ser utilizado como base para a preparação do edital. A CELEPAR, pelo seu papel e experiência no processo de desenvolvimento de sistema e pela metodologia de desenvolvimento que utiliza, pode ser utilizada como fator indutor da qualidade do projeto final. Esta função também foi descartada em função de: necessitar de uma prévia especificação do produto, para permitir medir o volume de trabalho (ponto de função); depende de autorização do CRAFE; dificuldades de se estabelecer critérios de seleção de empresas fornecedoras (imaturidade do mercado fornecedor);

• desenvolvimento sob responsabilidade da CELEPAR juntamente com o auxílio do NII do DECOM: o desenvolvimento do Sistema poderá ser contratado junto à CELEPAR, correndo as despesas pelo contrato de prestação existente entre o DECOM e a CELEPAR. É uma forma de encaminhamento com garantia de qualidade e continuidade dos serviços.

Foi escolhida a terceira alternativa de solução em função de: tarefas vinculadas a prioridades da instituição; solução tende a ser mais aderente às necessidades, uma vez que há mais participação dos usuários; utilização de tecnologia gráfica, padrão Windows; solução desenvolvida segundo padrões de metodologia; garantia de continuidade; valor previsto no contrato CELEPAR-DECOM não depende de autorização do CRAFE, gerando o menor custo.

A escolha da alternativa descrita acima é a que confere maior agilidade ao processo de desenvolvimento e implantação da solução e também:

• tecnologia com um horizonte de vida maior;

• interface gráfica, padrão Windows;

• maior integração com outros produtos Microsoft;

• maior facilidade de manutenção;

• integração com a tecnologia Internet.

2.1 Concepção Preliminar

Após estudo preliminar, descrevem-se abaixo algumas funções do sistema:

• Contrato OP
  • Cadastro;
  • Cronograma;
  • Rendimento;
  • Fatura Emitida;
  • Transferência.

• Processo Obra
  • Processo;
  • Caução;
  • Comprometimento;
  • Fatura Recebida.

• Tabelas
  • Objeto;
  • Órgão Público;
  • Município;
  • Executora
    • Empreiteira;
    • Representante.

• Usuários
  • Cadastro usuários

2.2 Benefícios

Com a adoção da solução proposta o SEOP/DECOM terá os seguintes benefícios:

• Elaboração precisa e rápida das contas a receber e a pagar;
• Facilidade de recuperação das informações;
• Maior agilidade no atendimento à direção do órgão;
• Maior satisfação dos usuários do sistema;
• Melhoria na qualidade das informações;
• Modernização dos sistemas;
• Racionalização do trabalho.
• Sistemas Adequados para o ano 2.000;
• Facilidade de manutenção dos programas;
• Acesso ao sistema via Internet;

2.3 Modelo das telas do sitema SIF

Tela: Controle de Transferência

Transferência de um contrato Op para outro.

Tela: Cadastro de Processos

Cadastro e consulta de processos.

Tela: Cadastro de Caução

Cadastro e consulta das cauções referentes a um contrato Op.

A estratégia de desenvolvimento desta solução deve ser alicerçada nas telas e relatórios definidos na versão 1 – reengenharia do sistema atual.

Por mais que a versão 2 – novas funções (controle da conta corrente de obras, etc.) - esteja esboçada na versão 1, as demais versões deverão ser feitas em conjunto - CELEPAR/DECOM, tão logo as demais versões estejam implantadas.

Os serviços deverão ser desenvolvidos nas instalações do Núcleo de Informática do DECOM, que deverá disponibilizar a infra-estrutura de hardware e software necessária.

Para a implantação do sistema (versão 1) deverão ser cumpridas as seguintes diretrizes:

• a implantação do sistema será feita em paralelo com o sistema atualmente utilizado por tempo a ser definido;

• o ambiente operacional deverá estar totalmente adequado, para que o sistema seja implantado;

• será realizado o treinamento de todo o pessoal usuário do sistema;

• realizar testes exaustivos (alfa e beta teste) antes da implantação oficial do sistema;

• a versão do sistema deverá obter aprovação de aceitação pelo DECOM e CELEPAR;

• realizar a conversão das Bases de Dados Clipper - Access e Microsoft SQL-Server;

• o ambiente físico deverá estar adequadamente disponível para o funcionamento do sistema;

• a implantação oficial desta versão do sistema deverá ser feita somente após o período de treinamento e experiência prática;

A finalidade deste é descrever a forma de conversão dos dados das tabelas existentes. O sistema atual foi desenvolvido em Clipper cujo padrão é Xbase ou seja, os arquivos são tabelas .dbf.

4.1 Definição dos Dados a Serem Convertidos

As tabelas a serem convertidos são: empenhos; faturas recebidas; empreiteiros, obras; contrato OP; faturas emitidas; órgãos públicos; cronogramas; municípios e usuários.

A proposta de conversão é copiar as bases de dados padrão Xbase para modo texto, depois importar para o Access. Neste ponto serão feitos todos os testes e finalmente a importação definitiva para o SQL-Server. Caso haja necessidade, pode ser que tenhamos que digitar algumas tabelas que não se consiga, por qualquer motivo, que seja importada.

Haverá ainda a necessidade de analisar os textos para a viabilização da conversão das maiúsculas por maiúsculas/minúsculas (exemplo OBRAS PÚBLICAS por Obras Públicas).

4.2 Cronograma de Conversão

O momento de conversão será após a construção dos procedimentos definidos no projeto lógico e nos testes do sistema. Este procedimento deverá ser executado antes de sua implantação.

Este procedimento será objeto de cronograma específico definido no MS-Project e deverá seguir esta seqüência:

• programas para gerar arquivos textos a partir dos arquivos padrão Xbase;

• programas para importar os arquivos textos para o padrão Access;

• programas para importar os arquivos Access para o padrão SQL - Server.

A finalidade deste é descrever a forma de contingência ou seja como prever a recuperação dos dados e sistemas em caso de pane total ou parcial.

Em virtude do sistema não ser crítico, não é necessário procedimento de solução alternativa em caso de pane do sistema. Estima-se um prazo de 24 horas para o pronto restabelecimento do mesmo, como descrito a seguir.

5.1 Procedimento de Back-Up

O sistema deve garantir ao usuário segurança de acesso, através de níveis de autorização ou recursos similares a informações e às funções.

O sistema deve permitir ao usuário alterar a sua senha de acesso.

O sistema deverá ter duas cópias (código fonte e dados) armazenadas, uma na própria sede do DECOM e outra na CELEPAR, sendo que a periodicidade deverá ser diária em fita DAT.

5.2 Procedimento de Restore

Em caso de perda do sistema (código fonte ou dados), a agilidade e rapidez na recuperação e restabelecimento dos trabalhos normais está sendo estimado em um prazo máximo de 24 horas.

6. Conclusão

Espera-se, com a implantação deste sistema, atender as expectativas do cliente no que diz respeito à elaboração precisa e rápida das contas a receber e a pagar dos contratos OP´s; facilidade de recuperação das informações; melhoria na qualidade das informações e racionalização do trabalho.