Há um interesse crescente em melhorar o planeamento do investimento público e a gestão do investimento público. A gestão das despesas públicas de capital a longo prazo é vista como uma contribuição crítica para o crescimento sustentável. Este interesse crescente na gestão do investimento público inclui encontrar uma melhor automatização e gestão através da utilização de software empresarial de Planeamento de Recursos do Governo (GRP). Esta é a terceira parte de uma série que explora:
- Porque é crucial a gestão do investimento público?
- Como pode o software permitir o ciclo de vida do investimento público?
- Porque é importante a integração entre sistemas e subsistemas de software de investimento público?
- Que soluções de software estão disponíveis na FreeBalance para ajudar o governo a gerir os investimentos públicos?
Porque é importante a integração entre sistemas e subsistemas de software de investimento público?
As organizações governamentais utilizam frequentemente software autónomo para gerir o ciclo de vida da Gestão do Investimento Público (PIM). Tal como descrito no entrada anteriorUma solução abrangente de software PIM requer elementos das categorias CPM, PPM, GRP, ERP, e SCM. A nossa observação é que o software Commercial off-the-Shelf (COTS) e o software desenvolvido à medida utilizado pelos governos para investimentos públicos raramente é integrado ou interligado de forma automatizada. Muitos especialistas acreditam que o software autónomo é apropriado para o que parece ser funções autónomas, muitas vezes utilizadas exclusivamente por agências governamentais ou ministérios únicos.
Os sistemas autónomos não cumprem os conformidade, consistência, colaboração, abrangência e comunicações necessidades de investimentos públicos. Eis alguns exemplos que temos visto em implementações governamentais que carecem de integração:
- Separação do planeamento do orçamento de capital ou de aquisições das estruturas de desempenho resultando em investimentos que não estão ligados a objectivos governamentais
- Separação do software de planeamento orçamental operacional e de capital resultando na falta de orçamentos de funcionamento e manutenção quando o investimento de capital é completado resultando na desagregação de infra-estruturas ou hospitais e escolas sem abastecimento
- Separação entre o planeamento orçamental e a execução orçamental resultando na incapacidade de pagar por contratos de vários anos porque os compromissos de vários anos não foram integrados
- Separação do orçamento e planeamento de tesouraria resultando numa má previsão de tesouraria e na necessidade de mais instrumentos de dívida para financiar projectos
- Separação entre a gestão orçamental e a gestão da dívida resultando em financiamento insuficiente para investimentos públicos através de previsões deficientes, ou projectos de infra-estruturas paralisados devido à falta de fundos
- Separação do controlo das aquisições dos compromissos resultando em orçamentos excedidos ou subutilizados, infringindo leis orçamentais, e mergulhando os governos em atrasos (particularmente se utilizar a contabilidade baseada em dinheiro)
- Separação das aquisições da gestão de contratos resultando em pagamentos a fornecedores que não obedecem a requisitos contratuais ou regulamentos financeiros
- Separação da gestão de activos do planeamento orçamental resultando na utilização inadequada de bens, como frotas, e na falta de orçamentos para operações, reparações e substituição de bens quando no fim de vidas úteis
- Separação de M&A da implementação e operações do projecto onde os decisores e o público têm pouca ideia dos resultados positivos dos investimentos em infra-estruturas
- Ausência geral de segregação de funções onde os indivíduos são capazes de aprovar grande parte do ciclo PIM sem supervisão eficaz - isto permite frequentemente práticas corruptas
Qualquer grande organização com múltiplas aplicações pode beneficiar de uma forte integração. O principal risco para sistemas não integrados é o tratamento de alterações de metadados. Isto é particularmente importante no sector público com a reforma e modernização da Gestão Financeira Pública (GFP). Metadados, neste caso, refere-se a classificações de informação que precisam de ser alteradas através de múltiplas aplicações. Isto pode ser particularmente difícil quando algumas aplicações têm metadados codificados. Existem problemas de coordenação mesmo em situações em que os metadados podem ser ajustados entre muitos subsistemas PIM. Exemplos de problemas de metadados que podem tocar em muitos subsistemas PIM a partir da reforma da PFM incluem:
- Orçamentação de programas onde um segmento COA adicional é adicionado para permitir a visualização da informação por programas e não apenas através da estrutura organizacional
- Gestão de desempenho onde um segmento COA adicional é adicionado ou o segmento do programa é actualizado para apoiar estruturas de desempenho alinhadas com os objectivos governamentais
- Contabilidade de exercício onde são necessários elementos adicionais de COA de acumulação e a avaliação e depreciação dos activos são rastreados
- Reforma dos contratos públicos onde novas regras para compromissos, contratos, fornecedores e pagamentos exigem novas classificações
- Gestão de dinheiro com a Conta Única do Tesouro (TSA) que altera a natureza do planeamento da dívida e da gestão dos pagamentos
Como avaliar as necessidades de integração
Alguns observadores argumentarão que os riscos de falta de integração não são elevados em alguns casos. É difícil integrar uma carteira de COTS e software desenvolvido à medida que utilizam diferentes estruturas de programação e usam diferentes mecanismos de integração. Temos visto governos a utilizar muitas práticas tecnológicas deficientes para a integração, incluindo procedimentos armazenados e chamadas directas a bases de dados.
A FreeBalance desenvolveu uma abordagem baseada no risco para determinar o risco de integração. Esta utiliza uma matriz de risco padrão que mostra o impacto por probabilidade. A falta de risco de integração aumenta para qualquer aplicação que:
- Ciclo de vida: toca muitos elementos do ciclo de vida desde o planeamento até aos resultados
- Pontos de integração lógica: toca em muitos pontos de integração lógica com outras aplicações
- Integração de aplicações lógicas: toca muitas aplicações com os pontos de integração lógica
- Aplicações de categoria: fazem parte de um conjunto de aplicações separadas para uma função geral, tais como múltiplas aplicações de planeamento orçamental para orçamentos salariais, de capital, periódicos, de desenvolvimento e de dívida
- Ciclo de compromisso: inclui múltiplas etapas no ciclo de autorizações, desde orçamentos a pagamentos através de autorizações e obrigações em que os orçamentos podem ser excedidos
- Risco de erro: inclui grandes volumes de dados como compras ou grandes montantes monetários como contratos
O processo que utilizamos identifica os riscos dos subsistemas PIM de muito alto a muito baixo:
- Muito alto: elevada probabilidade e elevado impacto quando é necessária uma integração técnica rigorosa das boas práticas, e quando a falta de capacidades de integração combinada com qualquer falta de funcionalidade resulta na substituição da aplicação
- Alto: ou elevada probabilidade ou impacto elevado combinado com probabilidade média ou impacto médio, onde é necessário um plano de integração e podem ser necessárias actualizações da aplicação
- Médio: probabilidade média e impacto médio, onde é necessária uma visão da arquitectura empresarial de integração para todos os riscos médios a muito elevados, e as aplicações são migradas para um autocarro servidor de aplicações
- Baixo: as aplicações com menor risco podem ser interligadas utilizando ficheiros planos, chamadas a bases de dados ou outro mecanismo simples e as aplicações classificadas como de baixo e médio risco só devem ser substituídas por aplicações integradas se faltar uma funcionalidade importante
Um cenário de problemas de integração de aquisições
Descrevemos as razões pelas quais Os sistemas autónomos de E-Procurement não são uma boa ideia num posto em 2014. Foram descritos os pontos de integração entre o aprovisionamento e outros subsistemas de GFP. O posto resultou de uma reunião com uma equipa que desenvolveu um sistema personalizado de "Compras Públicas Electrónicas" (e-GP). O líder da equipa argumentou que o sistema de back-office GRP seria capaz de lidar com compromissos porque os ministérios individuais assegurariam a existência de orçamento antes de aprovarem qualquer requisição de compra ou ordem de compra. Ele também sugeriu que não existia tal coisa como "back-office procurement". A equipa demonstrou grande confiança nestas afirmações. Isto fez-me lembrar o ditado: "a confiança é aquela sensação que se tem imediatamente antes de se compreender completamente o problema". Aqui está o problema:
- A agência governamental verifica se existe orçamento suficiente para uma requisição de $10M para um investimento público e emite um compromisso (ou pré-encargos) no sistema de back-office e emite um Pedido de Proposta no sistema e-GP
- O compromisso pode não estar estritamente relacionado com a aquisição porque o controlo é manual
- Os vendedores apresentam propostas em que a proposta vencedora pode ser inferior ao orçamento que requer uma anulação manual no GRP, ou pode ser superior ao orçamento que requer a aprovação do orçamento que segue os procedimentos de disciplina fiscal utilizados pelo governo
- É provável que o contrato e a execução abranjam vários anos, daí a necessidade de mostrar compromissos de vários anos no PRG e no sistema de planeamento orçamental, e onde os montantes para os anos sejam provavelmente diferentes do plano original
- O fornecedor ou vendedores executam o contrato mas pode haver atrasos, o que significa que podem ser necessários rollovers orçamentais, assumindo que estes são válidos na lei de aquisições
- As receitas e devoluções de bens e serviços têm de ser consideradas no back-office GRP
- Sanções e pagamentos de execução poderiam fazer parte do contrato que afecta o cálculo back-office para autorizações e orçamentos
- A falta de segregação de funções no sistema e-GP, particularmente se esse sistema for responsável pela autorização de pagamentos, constitui um risco significativo