miércoles, julio 13, 2005

Sistemas Computacionales y Bancos de Proyectos

I.-INTRODUCCION

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:

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.

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.

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.

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.

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 DE UN BANCO DE PROYECTOS

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:

INGRESO FICHA
RECOMENDACIÓN TECNICO ECONOMICA
PRIORIDADES DE INVERSION
APROBACION
OBTENSION FINANCIAMIENTO
PROYECTOS APROBADOS CON FINANCIAMIENTO
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 DE UN BANCO DE PROYECTOS

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.

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.

Es en esta arquitectura Cliente/Servidor donde encontramos más facilidades para la implementación de aplicaciones como los BP.

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
Bolivia

Todos estos BP se encuentran en funcionamiento, es probable que varios de ellos hayan sido migrados a 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 Institucional y 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