Banco de Proyectos de Inversión

I.-INTRODUCCIÓN

El desarrollo e implementación de un Banco de Proyectos (BP) se orienta a complementar el tratamiento tradicional de la inversión pública a través de un enfoque integral y dinámico. Permite normalizar el tratamiento de la misma vinculando el nivel de proyectos específicos con el presupuesto del Estado y los Objetivos y Metas de Desarrollo Social y Económico.

A través de la implementación del BP se conforma un instrumento operativo que permite complementar el análisis a nivel de proyectos específicos, con un tratamiento sistematizado
e integral del proceso de inversión pública.

Los principales objetivos del Banco de Proyectos son los siguientes:

  1. El Banco de Proyectos tiene como principal objetivo proporcionar información para mejorar
    la toma de decisiones de asignación de recursos para preinversión e inversión. Por lo tanto, la demanda de información vinculada con este propósito específico define el universo dentro del cual deben establecerse las variables pertinentes.

  2. Concebir a la inversión pública como un proceso continuo y poner de manifiesto que el nivel, la estructura y la compatibilidad entre las políticas del Gobierno y la futura inversión, dependerá de la capacidad actual de programar adecuadamente el proceso de inversión desde sus inicios y en todas sus etapas.

  3. Concebir cada proyecto como una unidad del sistema de información. El diseño y operación del sistema requiere mantener individualizado al proyecto durante su ciclo
    de vida, a fin de garantizar un eficiente manejo de la inversión.

  4. Permitir mantener un registro de la historia de cada proyecto individual (aún de los más
    pequeños) y de este modo efectuar análisis ex-post de proyectos que retroalimentan al sistema de planificación y posibiliten un mejoramiento paulatino del proceso.

  5. Normar en detalle el ciclo de vida de los proyectos y estandarizar tanto el léxico como el
    contenido conceptual de la terminología utilizada, para todas las instituciones públicas en este campo.

Para lograr una adecuada organización del proceso de inversión pública, es necesario que las normas, procedimientos, metodologías, capacitación de recursos humanos e información
sean homogéneos, coherentes y de aplicación uniforme en todas las instituciones del sector público.

En la asignación de recursos para preinversión/inversión, la demanda de información proviene de todas las instituciones, estando la misma determinada por sus funciones (decisión, asesoramiento o ejecución) y por el marco legal que fija su competencia.

El BP abarca el ciclo completo de todos y cada uno de los PROYECTOS de inversión pública, pero sólo se almacena y procesa información sistematizada y resumida a ser utilizada por los niveles de Gobierno (decisión), Planificación (asesoramiento) y Administración (ejecución). Cabe hacer notar que se entiende por "Proyectos", los programas o estudios básicos o proyectos específicos indistintamente.

II.-ARQUITECTURA LOGICA

En este marco lógico se identifican claramente las entidades, procesos y funciones correspondientes a cada etapa de un proyecto para lograr financiamiento y su posterior ejecución.

EL Modelo Conceptual es la consecuencia del trabajo grupal llevado a cabo por un equipo multidiciplinario liderado por el experto en informática, el cual debe sintetizar y concretar todo el conocimiento de los expertos de cada área en el Modelo, el cual posteriormente será la base para generar el Modelo Físico del sistema.

En general para abordar el desarrollo de sistema de la embergadura de un BP, es necesario subdividir la aplicación en módulos, ello permite concentrarse con mayor facilidad en el análisis y posterior desarrollo al estudiar los requerimientos de cada módulo en forma separada.

Podemos distinguir claramente en un primer análisis dos grandes módulos:

  • PREINVERSIÓN
  • INVERSIÓN

Dependiendo de las necesidades y requerimientos de las instituciones y usuarios del sistema a implementar, se podría detectar otros módulos y/o subdividir los anteriores.

PREINVERSION:

Las funciones básicas de la etapa de PREINVERSION son :

. REGISTRO DE PROYECTOS.

. VERIFICACION DE INFORMACION BASICA.

. RECOPILACION ANTECEDENTES EVALUACION DE PROYECTOS.

. SELECCION PROYECTOS A FINANCIAR.

Para registrar la información asociada a cada una de estas funciones, se diseña formularios apropiados, los cuales deben ser completados a medida que el proyecto avanza por las
distintas etapas.

El proceso comienza con la confección por parte del sector interesado, de la ficha de registro
de proyecto. Esta ficha es completada con los datos básicos del proyecto que postula al financiamiento, siendo condición absolutamente necesaria para iniciar el proceso de preinversión. Completada la ficha, es enviada al Departamento de Planeación, donde se verifica que la información contenida en la ficha sea consistente y se pide que se realice la evaluación del
proyecto.

El BP debe registrar las diferentes etapas por las que pasa un proyecto, siendo las más relevantes las siguientes:

  1. INGRESO FICHA
  2. RECOMENDACIÓN TECNICO ECONOMICA
  3. PRIORIDADES DE INVERSION
  4. APROBACION
  5. OBTENSION FINANCIAMIENTO
  6. PROYECTOS APROBADOS CON FINANCIAMIENTO
  7. PROGRAMACION FISICO-FINANCIERA

Las instituciones reciben los proyectos que requieren financiamiento y estudian su viabilidad e
información técnica que los acompaña. Producto de este análisis puede que se requiera completar información, la que debe ser provista por las distintas instituciones que participan en el proceso.

La nómina de proyectos aprobados con sus respectivos montos asignados, es enviada al Ministerio de Hacienda y/o Economía y Departamento de Planeación, siendo este último el encargado de informar a los sectores regionales de aquellos proyectos que fueron aprobados, con lo cual finaliza la etapa de Preinversión.

INVERSION:

Las funciones básicas de esta etapa son :

. SEGUIMIENTO PROGRAMACION FISICA-FINANCIERA

. CONTROL AVANCE FISICO-FINANCIERO PROYECTOS

. CONSOLIDACION DE INFORMACION DE AVANCE FISICO-FINANCIERO

El proceso de inversión comienza cuando ya se han asignado los fondos y los sectores conocen las resoluciones correspondientes, luego, corresponde realizar la licitación y llamado a propuesta para cada proyecto. Los sectores regionales son los encargados de llevar acabo esta tarea y paralelamente deben informar a la agencia financiera del resultado de las licitaciones de acuerdo a la normativa de éstas.

Con los montos asignados y los contratos firmados, se procede a confeccionar el calendario de desembolsos. En este calendario se estipula claramente el monto a desembolsar por proyecto
trimestralmente, el cual es enviado a la agencia financiera correspondiente.

La programación física-financiera es confeccionada por las instituciones responsables de la ejecución del proyecto, en conjunto con las empresas externas que se harán cargo de su ejecución. Esta programación se confecciona una vez que han sido analizadas y definidas las actividades más relevante del proyecto, y se envía al Ministerio de Hacienda y/o Economía para su análisis y comentarios.

Cada sector, en base a las actividades que debe controlar confecciona un programa trimestral
de avances físico-financiero, que se registra en un formulario especialmente confeccionado para tal efecto y que serán registrados en el BP. Este programa servirá de base para comparar los avances reales con los proyectados.

Finalmente en forma simultánea, se proporcionan los antecedentes de reprogramaciones trimestrales de la ejecución físico-financiera de los proyectos, las que deben practicarse
cuando se verifiquen desviaciones significativas en el avance de los mismos. El registro de esta información en el Banco de Proyecto será de capital importancia ya que será utilizada más tarde para preparar informes agregados trimestrales sobre el resultado de la ejecución física-financiera de los proyectos de inversión.

Este conocimiento es llevado a un diagrama, el cual se construye utilizando herramientas que permiten "modelar" el sistema, este diagrama esta constituído por entidades, atributos y relaciones entre ellas, a este diagrama se le llama Modelo Conceptual y refleja fielmente las reglas del negocio y dominios de cada atributo que componen el BP. Es en el Modelo Conceptual donde se concentra todo el conocimiento y la problemática del sistema, es absolutamente necesario documentar profusamente cada entidad y atributo, así como también definir las validaciones lógicas para cada una de ellas.

Un buen Modelo Conceptual evita la dependencia de las personas que participaron en la generación del sistema, permite una generación del Modelo Físico fluída, ahorra una cantidad de tiempo razonable al generar automáticamente las tablas del sistema una vez construído el Modelo Físico y finalmente permite una programación "limpia".

III.-ARQUITECTURA FISICA

Una vez elaborado el Modelo Conceptual existen herramientas que permiten generar automáticamente el Modelo Físico, generando tablas, campos, relaciones, validaciones, trigger,
procedimientos e índices. Una vez generado el Modelo Físico es necesario revisar y evaluar el impacto de la implementación de este modelo en la plataforma de hardware a seleccionar.

Una de las grandes dudas que se plantean al momento de definir el tipo de arquitectura física en
la cual se implementará el BP, es la distribución de las bases de datos, en general ello implica un análisis detallado de las necesidades de las unidades ejecutoras y la realidad de país en términos de infraestructura de comunicaciones.

Al utilizar una arquitectura distribuída inevitablemente se generan procesos adicionales para la integración de los datos, centralización de información mediante medios magnéticos y/ó vía electrónica, ello en general presenta problemas prácticos, tales como el envío de información a la unidad centralizadora, falla en los medios magnéticos que se utilizan para el traslado de la información, falla en las lineas de comunicación, validación de la información a centralizar,
la cual debe ser validada nuevamente al momento de ser centralizada.

La ventaja de una arquitectura distribuída se centra en la economía de las estaciones de trabajo y la seguridad de la información al residir en equipos locales, claramente resulta más económico utilizar PC con bases de datos distribuídas y enviar esta información a través de diskette para su centralización, ello evita la instalación y configuración de complejos sistemas de comunicaciones, los cuales son difíciles de controlar y complejos de mantener, dependen de las compañías telefónicas locales y de la infraestructura que estas tenga para cubrir el área de interés.

La arquitectura centralizada tiene la enorme ventaja de evitar procesos de centralización de datos, pero requiere de una fuerte estructura de seguridad y comunicaciones. En lo que respecta a la seguridad es necesario armar complejos perfiles de usuario de manera de evitar la manipulación de información por parte de usuarios no autorizados, por otro lado el tema de las comunicaciones tampoco resulta trivial, es necesario controlar usuarios remotos, conmutados
y dedicados, los cuales estan modificando permanentemente las bases de datos.

Felizmente con el abvenimiento de la arquitectura Cliente/Servidor, la tendencia a la utilización de
modelos relacionales a sido la tónica en los últimos años, en general los primeros BP utilizaban modelos jerárquicos, los cuales eran muy rígidos en lo respecta a las relaciones entre las distintas entidades del modelo, siendo muy seguros respecto de las validaciones de consistencia.

La evolución de los PC permitió implementar BP complejos en redes de area local utilizando sistemas operativos simples pero inseguros, en general con lenguajes como Clipper, FoxPro, Basic, etc., claramente estos BP adolecian de varios problemas tales como, fragilidad de las bases de datos, inseguridad en las transacciones, niveles de seguridad usuaria pobre. En la medida que la tecnología de programación fue en avance, se implementó BP en plataforma más sólidas, utilizando motores de bases de datos, los cuales permiten un manejo y control sobre el modelo físico más eficiente.

Una vez terminado el Modelo Físico comienza el modelamiento de objetos y la programación de la aplicación, algunas herramientas permiten generar las pantallas básicas automáticamente, como paso posterior a la generación de las tablas del sistema, pero en general es necesario modificarlas para adecuarlas al estilo y a la presentación del sistema, no siendo recomendable utilizar esta opción, al final puede consumir demasiado tiempo de programación que construirlas desde cero de una vez.

En lo respecta al modelamiento de objetos, en esta actividad se identifican los objetos base y se determina cuales de ellos serán construídos por el programador y cuales serán adquiridos y/o construídos en forma externa. Los lenguajes de arquitectura abierta permiten la inclusión de objetos del tipo OCX, ActiveX y DLL, ellos le da una potencialidad insospechada, en la actualidad existe una cantidad importante de empresas desarrollando objetos de distintas característica,
los cuales ahorran muchísimo tiempo de programación.

IV.-IMPLEMENTACIONES

Evidentemente él éxito en la implementación de un BP parte de un buen análisis del marco conceptual y las políticas y normas vigentes, en general podemos visualizar las siguientes etapas en el desarrollo de un BP:

  • Generación Modelo Conceptual
  • Generación Modelo Físico
  • Elaboración de Diccionario de Datos
  • Modelamiento de Objetos
  • Generación de Bases
    de Datos
  • Programación
  • Pruebas y Depuración
  • Marcha Blanca
  • Implementación

La planificación del desarrollo de un BP parte por asignación de responsables para cada una de las etapas anteriormente descritas, siendo necesario crear un grupo de desarrollo constituído por al menos los siguientes profesionales:

  • Experto en Sistema
    de Inversión Públicas
  • Analista de Sistema
  • Programador de Aplicaciones
  • Contraparte Técnica
    para implementación y pruebas

La cantidad de profesionales responsables para cada etapa pudiere variar dependiendo de la magnitud del BP, por ejemplo, de implementar una arquitectura distribuída como módulos operador directamente por unidades ejecutoras, será necesario mantener más de un programador y al menos dos profesionales a cargo del soporte para los usuarios externos y administración de las bases de datos.

Existen en el mercado herramienta más económicas para construir los modelos lógico y físico,
pero en general es recomendable utilizar aquellas que permitan manejar diversos motores de bases de datos.

Respecto de los plazos tenemos la siguiente tabla:

Actividad

Semanas

Generación
Modelo Conceptual

8

Generación
Modelo Físico

4

Elaboración
de Diccionario de Datos

4

Modelamiento
de Objetos

6

Generación
de Bases de Datos

2

Programación

12

Pruebas
y Depuración

4

Marcha
Blanca

2

Implementación

2

TOTAL

44

Evidentemente los plazos pueden variar dependiendo de la magnitud y el grado de complejidad del BP a construir, lo cual influirá directamente sobre los costos de desarrollo en lo que respecta a los profesionales contratados.

En las implementaciones de los BP nos encontramos con variados ambientes, partiendo de las instalaciones bajo DOS-Netware-Novell las cuales en su mayoría se encuentran desarrolladas
bajo Clipper y FoxPro.

Se trata de ambiente frágiles respecto de su seguridad y consistencia de datos, los cuales hacen necesarios generar procesos de verificación de datos. Las bases de datos que utilizan tienen relaciones y atributos que no contemplan su existencia , es decir, no es posible validar si un campo quedo vacío, a no ser de que se programe, lo mismo sucede con las relaciones, aquellas que son necesarias, como por ejemplo la existencia de un proyecto con su respectivo plan de financiamiento, es necesario programarlo.

Al utilizar este ambiente se pone demasiado esfuerzo en la programación para solventar deficiencias de las bases de datos y los lenguajes de aplicación, invirtiendo mucho tiempo y esfuerzo en ello. Todos lo que tenemos experiencia en el desarrollo de software, sabemos que el esfuerzo se debe focalizar en el Modelo Conceptual y Físico, de manera de optimizar la programación y evitar la ocurrencia de errores obvios.

En implementaciones más ambiciosas o con más recursos nos encontramos con arquitecturas del tipo MainFrame, donde la aplicación reside en un gran computador central el cual esta conectado a una serie de terminales "tontos" que reciben imágenes de los datos, los procesos y las bases de datos residen en el MainFrame, el cual asigna recurso y administra procesos.

El alto costo de mantención y la rigidez para realizar cambio, han sido razón para que este tipo de ambiente vaya en franca disminución, siendo rápidamente desplazados por arquitecturas del tipo Cliente/Servidor.

En esta arquitectura es posible determinar que procesos residirán en el Servidor y cuales serán
de responsabilidad de los clientes, en general se trata de instalaciones donde nos encontramos con redes de PC, soportadas por uno o varios servidores de archivos, trabajando sobre Windows NT, Netware Novell, Unix, Solaris, etc..

Al utilizar este tipo de arquitectura es posible descansar sobre motores de bases de datos que
provean atributos y relaciones estables y solidas sobre las tablas de datos, ello también permite utilizar programación orientada al objeto, la cual entrega enormes beneficios a la programación, tales como objetos reutilizables, utilización de servicios del sistema operativo (API), empaquetamiento de objetos comunes, etc…

Sin duda que en el futuro tendremos muchas aplicaciones corriendo sobre esta arquitectura, sobre todo porque ello permite la distribución eficiente de procesos, lo cual descongestiona las redes LAN y WAN.

En lo que se llama el "Front-End" para estas aplicaciones nos encontramos con lenguajes tales como; Visual Basic, PowerBuilder, Delphi, SQL Windows y otros nativos para algunos motores de datos. En general todos estos lenguajes permiten una buena conectividad con los motores de datos, siendo destacables la ductibilidad y la rapidez para el desarrollo de aplicaciones, Delphi 3.0 y Visual Basic 5.0, ambos cumplen sobradamente con los estándares de programación, pero además proveen al programador de una serie de herramientas, librerías OCX, PVCS que resuelven la mayoría de problemas de cualquier aplicación compleja y proveen de una arquitectura de programación abierta, lo que se traduce en la liberación de aplicaciones solidas y con bajo peso en cuanto a código contenido en la aplicación.

V.- EXPERIENCIAS

El consultor ha tenido una basta experiencia en el desarrollo e implementación de BP bajo distintas arquitecturas durante los últimos 15 años, participando en el desarrollo e implementación de los siguientes BP:

  • Chile
  • Honduras
  • Colombia
  • Aruba
  • El Salvador
  • Venezuela (seminario)

Todos estos BP se encuentran en funcionamiento, es probable que varios de ellos hayan sido migradosa arquitectura Clientes/Servidor, generando versiones mejoradas, acorde con la realidad del país y el avance de la tecnología.

Para lograr éxito en la implementación de un BP es necesario considerar los siguientes puntos:

  • Apoyo Institucionaly Unidades Ejecutoras
  • Análisis detallado de problemática de inversión pública
  • Arquitectura abierta
  • Utilización de herramientas y plataformas probadas
  • Programación orientada al objeto documentada
  • Implementación con compromiso
  • Soporte técnico orientado al cliente
  • Mucha paciencia