Sistema de Gestão Financeira da Universidade de Aveiro

Transcrição

1 Sistema de Gestão Financeira da Universidade de Aveiro Profº Doutor José Alberto dos Santos Rafael; Engº Rui da Graça Rocha Ribeiro; Engº Filipe António Rodrigues Barreto Trancho; Engº Paulo Alexandre Génio Freire e Engº Nelson Pacheco Monteiro, da Universidade de Aveiro Índice 1. Introdução 2. Organização da Candidatura 3. Enquadramento 4. Requisitos 5. Abordagem Metodológica ao Desenvolvimento do Sistema 6. Descrição sumária do que é hoje o Sistema 7. Benefícios para a Instituição. 8. Conclusão 1. Introdução O Sistema de Gestão Financeira da Universidade de Aveiro (SiGeFUA) é um sistema de informação completamente desenvolvido na Universidade de Aveiro (UA), com o objectivo de responder a um conjunto diversificado de requisitos. Estes requisitos consideram, naturalmente, a vertente técnica da área financeira, mas também a vertente organizacional que tem em conta o modo descentralizado de organização e funcionamento da Universidade de Aveiro. Assim, o sistema inclui módulos que suportam a gestão da universidade nas áreas de planeamento orçamental, contabilidade orçamental e geral, tesouraria e património. A UA é uma instituição complexa e de considerável dimensão, com cerca de 1300 funcionários, geograficamente distribuída, que comporta cerca de duas dezenas de unidades orgânicas, com competências próprias e algum grau de autonomia nas áreas referidas. Para além disso, é uma instituição em que a fórmula organizativa não é estática, face às necessidades de adaptação a novas situações a que frequentemente tem de dar resposta. Isso implica, frequentemente, a constituição de novas unidades orgânicas ou funcionais ou a reorganização das já existentes. Para responder a estes requisitos, a universidade adoptou um modelo de organização e funcionamento descentralizado. Este modelo, e a dinâmica que ele pressupõe, teve de ser considerado pelo SiGeFUA, tendo constituído um factor de grande impacto na sua concepção, implementação e exploração. O SiGeFUA implementa uma arquitectura do tipo cliente-servidor, com um servidor de bases de dados relacional Oracle, e com clientes desenvolvidos em Delphi. Encontra-se em funcionamento há cerca de 2 anos, sendo utilizado diariamente por um universo de cerca de 120 utilizadores, pertencentes às várias unidades em que se organiza a Universidade de Aveiro. 2. Organização da candidatura

2 Esta candidatura é constituída por informação organizada em diversos documentos e por um CD, que inclui os documentos em papel, os manuais de utilização e procedimentos, que optámos por não imprimir dada a sua dimensão e a instalação da aplicação. Para que se possa ter uma panorâmica geral, apresentamos aqui os documentos e descrevemos o seu papel no contexto da candidatura. Os documentos no CD são todos armazenados em formato PDF, sendo incluído o Adobe Acrobat Reader, para possibilitar a sua leitura 3. Enquadramento A necessidade de modificar as ferramentas informáticas utilizadas para o registo das operações contabilísticas na UA tinha-se tornado uma evidência, tendo no final de 1996 sido feito o convite ao Prof. José Alberto Rafael para organizar uma equipa capaz de reformular o Sistema de Informação da Universidade de Aveiro, no que dizia respeito à componente de gestão, sendo a prioridade inicial atribuída à área financeira. Nesta área, a aplicação então utilizada, que tinha sido adquirida externamente, manifestava dificuldades a três níveis. Num primeiro nível, havia uma notória dificuldade na integração entre os diferentes módulos que a constituíam (regra geral, a integração era feita pelos utilizadores, à custa da inserção de códigos que permitiriam a relação entre as entidades representadas em cada um desses módulos, com as dificuldades e o os erros daí decorrentes). Num segundo nível, era possível constatar uma inadequação da aplicação à organização da UA. Por um lado, a aplicação não se adequava de todo à diversidade de conhecimento verificada entre os funcionários da Universidade que com ela interagiam, originando uma sobrecarga de trabalho dos serviços centrais, uma vez que toda a classificação dos documentos era lá feita, por se pensar que os funcionários das unidades, regra geral, não tinham os conhecimentos necessários para fazer a classificação contabilística dos documentos. Por outro lado era, por exemplo; impossível referenciar contabilisticamente de forma adequada a situação, frequente, de projectos partilhados entre várias unidades orgânicas da Universidade. Isto dificultava bastante o acompanhamento detalhado da execução orçamental. Finalmente, num terceiro nível, o suporte a diversas operações, por exemplo, como o planeamento orçamental ou a reconciliação bancária era deveras deficiente, dificultando de um modo particularmente gravoso a sua implementação. Face a este cenário, foi tomada pela reitoria a decisão de procurar uma solução que pudesse ser desenvolvida internamente, de modo a que a solução que viesse a ser implementada reflectisse, efectivamente, o modo de funcionamento desejado para os serviços financeiros da universidade, de acordo com a organização da UA e considerando as diferentes capacidades do universo de potenciais utilizadores de entre os funcionários das distintas unidades da UA. Em 1997, quando foi efectivamente iniciada a fase de captura de requisitos e análise, tornou-se claro que, face ao calendário da União Económica e Monetária, o sistema a desenvolver deveria incluir, já nessa altura, suporte ao Euro. Por outro lado, em 1997 foi publicado o Plano Oficial de Contabilidade Pública (POC-P), precisamente enquanto decorria a fase de captura de requisitos e análise do sistema. Referir aqui a ideia de suportar, usando a mesma aplicação, uma contabilidade orçamental e uma contabilidade geral. Isso tornou igualmente clara a variabilidade temporal dos planos de oficiais de contas a que a Universidade deveria obedecer. O suporte a essa variabilidade passou, assim, a ser uma característica fundamental do sistema a desenvolver o que se veio a revelar uma decisão de enorme impacto na adaptabilidade do SiGeFUA, como se verá adiante, quando abordarmos algumas das vantagens do sistema.

3 4. Requisitos Face ao enquadramento anteriormente exposto, podemos referenciar os seguintes requisitos genéricos para o SiGeFUA: Suporte a todas as funcionalidades que resultam da legislação em vigor para a área financeira (contabilidade e património); Suporte a todas as funcionalidades adicionais entendidas como relevantes pelos Serviços Financeiros, em termos do registo contabilístico orçamental e geral, de tesouraria e de património da Universidade de Aveiro; Consideração da organização da UA em termos da implementação das funcionalidades referidas anteriormente. Em particular, o sistema deveria permitir a afectação partilhada de projectos entre as unidades da UA, com a adequada reflexão contabilística na execução orçamental de cada uma das unidades envolvidas. Para além disso, tendo em conta o carácter dinâmico da organização da UA, o sistema deveria permitir a manutenção da informação relativa a essa organização não só num determinado momento do tempo, mas conservar a informação dessa organização em qualquer momento do tempo (mantendo uma perspectiva histórica dessa organização ao longo do tempo). Deste modo, considerando a data de qualquer operação contabilística, essa operação pode ser referenciada à organização concreta da UA nessa data. Suporte à existência de distintos planos de contas no tempo. Cada operação contabilística é referenciada ao plano de contas em vigor no momento a que a operação se refere, podendo o sistema suportar diferentes planos de contas para diferentes anos. No limite, se tal se revelasse necessário, o sistema poderia suportar um plano de contas diferente para cada ano orçamental. Por outro lado, as implicações em termos da reflexão contabilística de cada operação, deveriam tanto quanto possível ser parametrizáveis, de modo a facilitar o processo de adaptação do funcionamento do sistema, quando ocorrer uma alteração de um plano de contas, de um ano para outro. Requisitos de segurança funcional. A aplicação deve permitir que o seu administrador possa definir perfis funcionais que estabeleçam com precisão qual o relacionamento que cada utilizador é suposto ter com o sistema. Saliente-se que na definição deste relacionamento devem estar presentes a combinação das seguintes variáveis: = Operação (Operações às quais se tem acesso); = Estrutura Organizacional (Unidades às quais se tem acesso); = Área Orçamental (Fontes de Financiamento às quais se tem acesso); = Tipo Orçamento (de Planeamento ou de Execução); = Tempo (Períodos de tempo nos quais se tem acesso); de modo a ser possível acesso flexível, mas controlado e rigoroso à informação a manter pelo sistema; Suporte ao Euro; Tanto quanto possível, facilidade de uso. Adequação ao nível de conhecimento dos funcionários; Disponibilização de ajuda online quer a nível da utilização da aplicação quer a nível dos procedimentos financeiros e sua implementação na aplicação. 5. Abordagem metodológica ao desenvolvimento do sistema

4 A abordagem à concretização deste projecto assentou numa equipa constituída por 5 pessoas (2 docentes da UA colaborando em tempo parcial e 3 licenciados em tempo integral) que tiveram como princípio primeiro a criação de uma aplicação voltada para o utilizador onde toda a funcionalidade nela contida fosse apresentada de acordo com o conhecimento de que o utilizador (ex: contabilista) dispunha. Tendo em vista este princípio genérico foi utilizada uma metodologia que incluiu as fases de análise, desenho, implementação, teste e exploração. Embora estas fases apareçam listadas e sejam descritas na sequência que corresponde ao fluxo normal de avanço na execução do projecto, o seu desenrolar decorreu de forma iterativa havendo uma interpenetração entre todas elas. Assim foi frequente, em cada uma das fases mais adiantadas do projecto, ter de se regressar a tarefas de fases anteriores por forma a realizar os ajustes que se verificaram necessários. Este processo iterativo permitiu uma documentação consistente e coerente de toda a cadeia de informação do projecto essencial ao bom trabalho em equipa e à sua eficácia num projecto de grande dimensão. A Unified Modeling Language (UML) foi uma parte importante de todo este processo pelo seguinte conjunto de circunstâncias: possui característica que potenciam uma adequada capacidade de comunicação utilizando elementos gráficos de fácil leitura, até por não especialistas. Um exemplo de relevo são os Use Cases, que tiveram um papel de grande importância no diálogo com os utilizadores durante a fase de captura de requisitos; inclui mecanismos que permitem uma descrição rigorosa dos diferentes aspectos de um sistema: arquitectura, comportamento e estrutura; é um standard; usa o paradigma de orientação a objectos. Como ressalta desta secção os utilizadores desempenharam um papel central durante todo o projecto do sistema, condicionando o seu resultado final enquanto seus destinatários. A própria metodologia utilizada levou a que fossem eles também a fonte mais importante na captura daqueles requisitos. Dando cumprimento prático a este conceito foram realizadas sucessivas reuniões entre os actores (utilizadores de perfil distinto) e a equipa de informática onde foi patente que a funcionalidade pretendida pelos utilizadores para o sistema coincidia, em primeira instância, com o procedimento que eles próprios usavam. Em muitas circunstâncias o importante não era a componente procedimental para o desempenho das tarefas mas sim o objectivo a atingir, já que, o procedimento vigente era condicionado pelas ferramentas disponíveis no momento. A utilização dos Use Cases como linguagem de captura de requisitos e a capacidade da sua utilização para planeamento do comportamento de sistemas permitiu inferir da descrição procedimental feita pelos utilizadores quais os objectivos a atingir. Assim a equipa informática conseguiu, em muitas circunstâncias, confrontar os utilizadores com procedimentos mais simples para atingir os mesmos objectivos. Os utilizadores tiveram sobre esta matéria a última palavra. A secção 4 do documento Aspectos técnicos mais relevantes complementa a descrição da metodologia por nós usada na construção deste sistema. Os módulos de Planeamento, Contabilidade e Tesouraria do sistema demoraram cerca de 2 anos a ser construídos. Nos primeiros 10 meses (até Outubro de 1997) decorreu o processo de análise, os 12 meses seguintes destinaram-se à implementação de grande parte da sua funcionalidade. Os 3-4 meses seguintes destinaram-se a fase de teste por parte dos utilizadores. Em Fevereiro/ Março de 1999 o sistema entrou em funcionamento em toda a universidade (Serviços Centrais, Departamentos e restantes unidades funcionais).

5 Note-se ainda que, durante o ano de 1999, foram implementados todos os restantes mapas que se verificaram necessários. O módulo de Património foi igualmente desenvolvido tendo sido gasto cerca de 1 homem/ano para o completar. Este módulo ficou disponível em Julho de A aplicação cliente foi desenvolvida em Delphi. Tendo sido utilizada a UML como linguagem de análise e permitindo o Delphi a utilização do paradigma de programação por objectos (uma das razões da escolha desta linguagem) foi feita uma implementação do cliente que traduziu por mapeamento directo a organização da análise. Este princípio, que foi seguido de forma perseverante, permitiu e permitirá uma mais fácil manutenção do sistema, independentemente (quase) da alteração a produzir ter início a partir do código (ex: detecção de um bug) ou a partir da descrição analítica. 6. Descrição sumária do que é hoje o sistema O SiGeFUA utiliza uma arquitectura cliente/servidor de duas camadas com uma aplicação cliente a correr sobre o sistema operativo Windows e um servidor de base de dados Oracle a correr sobre SCO Unix. De uma forma resumida, pode dizer-se que o sistema cumpre os requisitos enunciados na parte inicial deste documento. Geograficamente o sistema implanta-se sobre um campus de 70 hectares em Aveiro e num campus em Águeda correspondente à Escola Superior de Tecnologia e Gestão de Águeda. O suporte lógico à comunicação entre as diferentes máquinas que participam no sistema assenta no protocolo TCP/IP (entre o campus de Aveiro e Águeda existe uma linha dedicada). O SiGeFUA organiza-se em 4 módulos funcionais: Planeamento orçamental, Contabilidade geral e orçamental, Tesouraria e Património aos quais acresce um módulo de segurança funcional que controla o tipo de interacção que os diferentes utilizadores registados podem ter com este sistema. A secção 2 do documento Aspectos técnicos mais relevantes que consta desta candidatura descreve com maior detalhe, embora resumidamente, a arquitectura e a funcionalidade de cada um destes módulos. Neste ponto queremos salientar a complexidade, a dimensão e o nivel de utilização deste sistema pela apresentação de um conjunto de dados estatísticos resultantes da sua exploração nos últimos 2 anos. Base de Dados Número de tabelas: 329 Aplicação Classes 185 Formulários 306 Relatórios 214 Utilizadores Grupos 76 Utilizadores 126 Outros dados Número de unidades/centros de custo em em Número de rubricas do plano de contas de planeamento 306

6 de execução Património Bens inventariados Edifícios 45 Localizações físicas Localizações funcionais 12 No documento Dados de sistema e estatística encontram-se estes e outros dados complementares. 7. Benefícios para a instituição Em primeiro lugar importa referir que face ao software que veio substituir o SiGeFUA trouxe uma garantia de rigor, consistência e coerência dos dados que não existia. Passou-se de uma situação em que o rigor só podia ser assegurado à custa de um enorme esforço de trabalho manual, demorado, exigente em termos de recursos humanos e, por isso, menos fiável, para uma situação em que o sistema, praticamente sem outro esforço que não a introdução dos dados contabilísticos, assegura esse rigor, libertando recursos humanos e com um tempo de resposta substancialmente reduzido. Em segundo lugar, o sistema permitiu desde muito cedo uma adaptação a um novo quadro legal, onde se destaca a exigência da introdução do euro e a utilização de diferentes planos de contabilidade. Desde o início da sua utilização o sistema esteve preparado para permitir o registo contabilístico em sucessivos planos de contas (POC-P e POC-E). A transição associada à mudança de planos de conta decorreu sempre sem qualquer sobressalto. Uma facilidade análoga existe para o registo patrimonial dos bens que já é feito de acordo com o novo código classificador (Cadastro e Inventário de Bens do Estado CIBE). Esta facilidade de adaptação rápida a um enquadramento legal em evolução permite que a UA retire daí as consequentes vantagens de gestão resultantes da capacidade de análise da execução financeira associadas a cada plano. Mesmo em relação á moeda legal, desde 1999 que a UA processa contabilisticamente documento em escudos ou euros não trazendo a adopção exclusiva do euro em 2002 qualquer problema. Em terceiro lugar o sistema possibilita um enorme grau de controlo orçamental, que se inicia na fase de planeamento e se propaga à execução. O orçamento planeado resulta, de facto, do orçamento planeado por cada das unidades orgânicas da universidade. O planeamento pode ser feito com todo o rigor resultante da utilização do plano de contas de planeamento, e tendo em consideração a execução orçamental anterior. O registo do orçamento de planeamento por parte de cada uma das unidades, possibilita a construção automática e bottom-up do orçamento de planeamento da universidade, através da utilização da hierarquia de unidades representada no sistema. O orçamento de planeamento definido por cada unidade serve também como referência para a respectiva execução orçamental, funcionando como um elemento adicional de gestão. Em quarto lugar, o sistema permite o acompanhamento da execução orçamental em tempo real, algo que não era possível até aqui. A UA tem uma organização departamental com um único Conselho Administrativo. A distribuição do orçamento pelas unidades é feita centralmente ficando cada unidade responsável pela sua execução. Desde que existam verbas disponibilizadas para a execução as unidades podem executar o seu orçamento sem necessidade de autorização prévia do Conselho Administrativo que só intervém no momento da autorização do compromisso. Este procedimento, só possível pelo grau de controlo assegurado pelo SiGeFUA flexibilizou e desburocratizou a aquisição de bens e serviços pelas unidades da universidade melhorando o tempo e a capacidade de resposta da UA face às suas necessidades.

7 Em quinto lugar, o sistema oferece, efectivamente, a capacidade de se adaptar às modificações da orgânica da UA, tal como se pretendia. Esta adaptabilidade permite que posteriormente se faça uma leitura analítica da execução do orçamento. Em sexto lugar, verificou-se uma transição bastante fácil do antigo sistema informático para o SiGeFUA. O sistema teve um impacto positivo sobre os recursos humanos da UA que se manifestou ao nível individual na apetência e facilidade com que os utilizadores passaram a usar a nova ferramenta e a nível colectivo, pela a sua adaptabilidade à formação diferenciada dos recursos humanos existentes, possibilitou e estimulou a formação formal e/ou auto-formação desses recursos promovendo uma evolução qualitativa gradual, sem a existência de rupturas de funcionamento. Em sétimo lugar, o sistema funcionou como um motor para a qualificação dos recursos humanos da área financeira. O envolvimento dos utilizadores no processo de construção desse mesmo sistema, a verificação da facilidade da sua utilização, a disponibilização de manuais da aplicação e manuais de procedimentos e de como os executar com a aplicação e a verificação da rapidez e qualidade dos resultados por ele proporcionados promoveram a aprendizagem e gosto pela realização de novas tarefas que se traduziu num aumento de competências a nível departamental com a consequente transferência de mais tarefas para estas unidades. Em oitavo lugar, verificou-se uma melhor compreensão e colaboração entre o grupo de informática e os restantes utilizadores do sistema com impacto positivo durante as fases de teste e exploração. 8. Conclusão Como resulta de todo este documento os seus autores fazem uma apreciação bastante positiva de todo o trabalho realizado na análise e desenvolvimento deste sistema informático. Esta apreciação, podendo ser considerada parcial, tem objectivamente informação de pelo menos dois anos, por parte de todos os que usufruem do sistema instalado. Por outro lado, a UA decidiu constituir um Gabinete de Gestão de Informação (GAGI) integrando nele os 3 engenheiros que tiveram grande responsabilidade no desenvolvimento deste projecto, o que de alguma forma consagra o trabalho já realizado e aposta em outros, já presentes, e futuros desenvolvimentos.