Lima, Peru (proyecto cerrado / project closed) :: www.gama-peru.org :: Dom 20 de Aug del 2017 [11:35 UTC] :: tw.o 1.9.11

Sistematizacion: El Monitor de Subproyectos

navegador 3d imprimir
regresar a Publicaciones


Indice






1. Antecedentes


Desde el inicio del Proyecto GAMA en el año 2000, la estrategia de su intervención se basa en la articulación de una oferta de conocimientos de instituciones y profesionales nacionales y la demanda de asesoría de los mineros artesanales. Para tal efecto el Proyecto GAMA cuenta con una estructura delgada de pocos profesionales de planilla pero una amplia base de consultores e instituciones interlocutores para la ejecución de actividades en forma de Subproyectos.

Durante la primera fase del proyecto (2000-2002) contraparte nacional de GAMA ha sido el Ministerio de Energía y Minas (MEM). La estructura directiva del proyecto era conformada por una co-jefatura compuesta por un profesional del MEM y un profesional de parte de COSUDE (Agencia Suiza para el Desarrollo), lo cual permitió decisiones ágiles y transparentes en la aprobación, ejecución y el monitoreo de Subproyectos, involucrando todas (ambas) contrapartes.

2. Retos para la implementación de la fase 2 de GAMA


La ejecución de la segunda fase del Proyecto GAMA contempló una ampliación de contrapartes, incluyendo los Gobiernos Regionales de la zona de intervención del proyecto, insertándose el proyecto en el proceso de descentralización y a la vez anticipando el proceso de transferencia de competencias sobre minería artesanal y pequeña minería a los Gobiernos Regionales. Como instrumento principal de implementación de las actividades del proyecto se mantuvo los "Subproyectos", modalidad de implementación considerada como exitosa en la evaluación de externa de la primera fase del proyecto.

2.1 Setup institucional de "GAMA 2"


Las instituciones contrapartes de GAMA 2, de tres años de duración (2003-2005), han sido:
  • Gobierno Regional de Ica (contraparte operativa)
  • Gobierno Regional de Ayacucho (contraparte operativa)
  • Gobierno Regional de Arequipa (contraparte operativa)
  • Gobierno Regional de Puno (contraparte operativa)
  • Ministerio de Energía y Minas (ente rector del sector)
  • Agencia Suiza para el Desarrollo y la Cooperación (ente cooperante)

A nivel operativo era previsto, que los Gobiernos Regionales de Ica, Arequipa y Puno participen en el proyecto con sus Gerencias de Recursos Naturales y Medio Ambiente (como miembros del Comité Directivo y entidad de enlace y coordinación con la oficina de GAMA). Con las mismas funciones, el Gobierno Regional de Ayacucho delegó su representación a su Oficina de Enlace en Lima. Complementariamente se consideró que los cuatro Gobiernos Regionales participen a nivel operativo mediante las respectivas Direcciones Regionales de Energía y Minas (DREM), quienes además crearan un enlace operativo con el MEM como ente rector del Sector, debido a su dependencia operativa del MEM.

Asimismo, el Convenio subsidiario para la ejecución del proyecto incluyó otras instituciones, tales como la Agencia Peruana de Cooperación (APCI), el Consejo Nacional del Medio Ambiente (CONAM) y representantes de las organizaciones gremiales de los mineros artesanales de ambas zonas del proyecto (2 de Sur-Medio y 1 de Puno). La ilustración 1 indica la sede de las oficinas de cada una de las instituciones participantes en el proyecto GAMA.

Ilustración 1


2.2 Opciones para la ejecución de Subproyectos en un entorno "multi-actores" (multistakeholder)


Con un número de 17 entidades involucrados en el proyecto, el cambio del setup institucional de la fase 2 de GAMA significaba que el procedimiento sencillo de manejo (aprobación, y monitoreo) de subproyectos de la fase 1 del proyecto -que consistía en la conformidad de opiniones de los 2 co-directores del proyecto en representación de las 2 contrapartes- ya no era oportuno.

Dentro de la estrategia de empoderamiento del proyecto, el lineamiento principal para subproyectos era la estricta orientación en la demanda, es decir, en solicitudes que originan exclusivamente en propuestas de grupos de mineros artesanales organizados o comunidades mineras, y cuya aprobación se enmarca en los objetivos y en el portafolio de actividades acordado en el Plan Operativo de Fase (POF) del proyecto GAMA.

a) Opción: Decisión formal del Comité Directivo

Se había acordado, que el Comité Directivo (CD) se reune 2 veces al año, en forma rotativa en las diferentes sedes de las instituciones contrapartes. La frecuencia de 2 reuniones anuales significaba para una aprobación de subproyectos significaba una seria disminución de la agilidad del proyecto, causando plazos de varios meses para poder responder (positiva o negativamente) a una solicitud, e inclusive hasta el próximo año en caso de una reformulación. Además, siendo los subproyectos la forma operativa de implementar las actividades del proyecto, el avance del mismo hubiera sufrido graves consecuencias.

b) Opción: Decisión centralizada de la Jefatura

Considerando que la puesta en marcha de los Subproyectos es la tarea operativa de implementar las actividades del proyecto, una opción viable y ágil hubiera sido, centralizar en proceso entero de recepción y aprobación de solicitudes y el monitoreo de los subproyectos en manos de la Jefatura de GAMA, similar a la fase 1. No obstante, la finalidad de la base institucional amplia de la fase 2 era fortalecer capacidades en las contrapartes, construir relaciones entre los Gobiernos Regionales y sus ciudadanos minero-artesananales, y construir apropiación ("ownership") del proyecto entre los múltiples actores peruanos. Mediante un mecanismo de decisión centralizada entre los Co-directores del proyecto sobre subproyectos no hubiera sido posible alcanzar ninguna de estas metas.

c) Opción: Coordinación tradicional entre miembros del Comité Directivo y Jefatura

Una opción compatible con la exigencia de agilidad en la conducción del proyecto y una participación de las contrapartes hubiera sido la circulación de solicitudes entre las instituciones participantes, lo cual, debido a su gran número hubiera sido viable solamente mediante envío simultáneo de copias físicas de cada expediente, en sus diferentes etapas a todos los actores, y consolidando opiniones en la Jefatura en base a las respuestas. Un análisis de los requerimientos logísticos de este procedimiento, sobre todo referente a la coordinación y retroalimentación entre los actores, y aspirando que no solamente la oficina de GAMA sino las contrapartes podrán actuar como entidades receptoras de propuestas, condujeron rápidamente a la conclusión de no-viabilidad de esta opción, ya que un solo expediente de una propuesta inter-regional pudiera facilmente alcanzar números inmanejables de comunicaciones.

Ilustración 2

d) Opción: Plataforma virtual de Coordinación

Consideraciones de dinamizar y facilitar un mecanismo participativo con las ventajas de la opción c) mediante correo electrónico tenían en el año 2003 la limitación que varios actores no contaban con cuentas de correo institucional, aparte de requerir un protocolo minucioso para garantizar que todas comunicaciones sean recibidas por todas partes involucradas, y la dificultad de dar seguimiento a cientos de correos electrónicos. En consecuencia GAMA consideró la implementación de un sistema de seguimiento que permitiera a cada parte interesada, informarse en tiempo real sobre todos los expedientes, y poder opinar oportunamente. Este sistema, "Monitor de Subproyectos" es descrito a continuación.

3. El Monitor de Subproyectos


3.1 Conceptualización y diseño del sistema


Analizando las características de un sistema informático que pudiera servir de plataforma para el proceso de recepción de solicitudes, análisis de aprobación y seguimineto, se consideró los siguientes elementos:

a) Aplicación Web: El sistema debe permitir acceso desde las oficinas de las contrapartes en caso de contar con acceso internet, o en su defecto desde cualquier cábina pública o cyber-café. Por lo tanto se descartan todas aplicaciones que requieren una instalación en el PC del usuario, por lo que debe ser necesariamente una aplicación web.

b) Software estándar de fuente abierta: Por razones de costo, independencia, flexibilidad y futuras actualizaciones es necesaria una solución en software de fuente abierta (Open Source); es decir no solamente software producido con herramientas de código abierto, sino toda una aplicación estándar en fuente abierta, con una comunidad de desarrolladores ("developers") activa. En este aspecto, la mejor fuente de información es http://www.sourceforge.net.external link

c) Tipo de software: Si bien existe una gran variedad de aplicaciones para Trabajo Colaborativo ("Groupware"), manejo de proyectos ("Project Management"), o para organizar flujos de trabajo entre multiples colaboradores ("Workflow Engines"), un análisis desde el punto de un "escenario zero" (¿cómo lo haríamos sin una aplicación web?) llevó a la conclusión, que el proceso del manejo de los subproyectos consiste principalmente en comunicación entre los participantes, la discusión de propuestas, informacion sobre decisiones a tomar y decisiones tomadas, y el intercambio de opiniones en el transcurso del monitoreo y la evaluación. Además es un proceso que requiere mucha flexibilidad y no se deja facilmente encasillar en un flujo de trabajo rígido. En resumidas cuentas: es una discusión sobre diferentes temas, siendo cada subproyecto un tema. Producto de esta conclusión era, que el mejor tipo de software será un software para un "Foro de Discusión".

d) Requerimientos para la Aplicación software de un Foro como expediente electrónico: Para su uso como expediente electrónico, el software debe cumplir sobre todo los siguientes requisitos:
  • registro de usuarios y contraseña con Nombre y Apellido que garantiza la autenticidad de los participantes en la discusión
  • sistema diferenciado de permisos de acceso, que garantiza la autenticidad de un mensaje u opinión, y a la vez permite asignar los permisos de cada usuario de acuerdo a su función
  • registro de tiempo que demuestra la secuencia lógica de las decisiones
  • aplicación debe tener calificación "5 - Production - Stable" en Sourceforge
Además:
  • el sistema debe ser intuitivo y fácil para aprender; con suficientes, pero sin demasiadas opciones.
  • debe haber un satisfactorio historial de versiones de actualización, con rápida respuesta ante nuevas brechas de seguridad. (comunidad numerosa de desarrolladores activos)
  • debe existir versión en Español del interfase de usuario (Frontend) y preferiblemente tambien del interfase de administración (Backend)
La aplicación que a criterio y para los fines específicos del Proyecto GAMA mejor cumplió estos requisitos al momento de la decisión sobre su introducción, a finales del año 2003 (comienzo operativo de la fase 2 de GAMA) ha sido el software phpBB (http://www.phpbb.comexternal link).

3.2 Instalación y configuración


La aplicación phpBB, programado en lenguaje PHP y usando una base de datos MySQL (u otras) es independiente del sistema operativo del servidor Web; en el caso de GAMA la instalación de la versión 2.0.6 en Español en un servidor bajo BSDUnix funcionó sin problemas. Posteriormente, luego de una serie de pruebas de seguridad para afinar el sistema de grupos de usuarios y permisos, se amplió la funcionalidad de la instalación base con varios modulos opcionales, que permitían una mejor organización jerarquica del contenido, y menores modificaciones en la presentación.

Siendo esta instalación la primera prueba de GAMA con este tipo de aplicaciones, las pruebas de usabilidad y seguridad, incluyendo varias modificaciones de la estructura del contenido tomaron en tiempo calendario un més y medio; en tiempo de dedicación exclusiva probablemente no más de una semana del administrador del sistema y unos días de usuarios "a prueba".

La unica funcionalidad que la aplicación no provee, es relacionada con seguridad contra pérdida y daño de la base de datos. Si bien el software contiene funciones de respaldo y restauración manual de la base de datos, para mayor seguridad se implementó adicionalmente una tarea automática ("Unix: Cron Job"), que realiza diariamente un respaldo de la base de datos y lo envia a una cuenta de correo electrónico de GAMA.

Al crear grupos de usuarios, se consideró pertinente la cconfiguración de 6 niveles de usuarios (aparte del nivel de administrador de sistema) con ascendiente asignación de permisos de acceso:
  1. No registrado: Puede ver y leer todos los mensajes del foro
  2. Registrados: Lo anterior y puede solicitar ser incorporado a un grupo de usuarios
  3. Interesados: Una vez aprobada la membresía pueden ver y leer los mensajes, y publicar sus preguntas y comentarios en los Foros Públicos
  4. Funcionarios Contrapartes: Lo anterior, y pueden publicar comentarios en el expediente de subproyectos y temas ya aperturados
  5. Representantes Regiones: Lo anterior, y pueden ingresar nuevos subproyectos (propuestas recibidas en sus oficinas), así como re-editar sus mensajes
  6. Personal GAMA: Lo anterior, y pueden moderar los foros de los cuales son moderadores
Los grupos 4 a 6 comprenden los funcionarios de las diferentes instituciones participantes en el proyecto GAMA en base a su nombramiento. La incorporación a los grupos de usuarios se realiza por parte del administrador del sistema en base a las comunicaciones respectivas.

3.3 Puesta en operación y capacitación de usuarios


Al haber terminado la primera serie de pruebas, se constató que se podía lograr una satisfactoria seguridad contra intrusos (usuarios no autorizados) dejando el permiso de lectura publicamente abierto . Esta afirmación y conclusión permitió ganar del sistema una nueva dimensión: la de Transparencia de la gestión del Proyecto GAMA. Por parte de la Jefatura del proyecto se decidió aprovechar esta oportunidad y proponer al Comité Directivo de GAMA la implementación del sistema en forma publicamente legible e visible; cuñando para tal efecto su nombre "Monitor de Subproyectos", en alusión al Monitor de un PC a través del cual se puede "monitorear" (dar seguimiento) a los subproyectos solicitados y en ejecución.

El funcionamiento y los objetivos del "Monitor", al momento de su lanzamiento, eran descritas de la siguiente manera:

El sistema MONITOR tiene como objetivo, proporcionar una herramienta transparente y agil para la administración y el seguimiento de los Subproyectos del proyecto GAMA.

El sistema MONITOR es manejado principalmente por el personal del Proyecto GAMA y de las contrapartes operativas del mismo (Gobiernos Regionales de Ica, Ayacucho, Arequipa y Puno). Para tal efecto los funcionarios respectivos forman parte de los grupos de usuarios "Personal GAMA" y "Contrapartes", que cuentan con derechos de acceso especiales para el manejo del MONITOR

El sistema se dirige a la vez a las demás contrapartes e integrantes del proyecto, permitiendo a los interesados expresar sus opiniones y recomendaciones acerca de los subproyectos u otros temas tratados; Asimismo otros actores con intereses legítimos en el avance del proyecto pueden solicitar formar parte del grupo de usuarios "Interesados" a fin de obtener derecho de acceso especial para opinar (responder) sobre subproyectos.

Todos los demás usuarios tienen acceso libre al sistema del MONITOR, pudiendo informarse acerca de la situación actual de todos los subproyectos en planificación o ejecución.

La asignación de membresías a los grupos "Personal GAMA" y "Contrapartes" se realiza en base a las acreditaciones respectivas. Estos grupos por lo tanto son "cerrados". A cambio el grupo de "Interesados" es "abierto", es decir usuarios registrados pueden solicitar membresía en este grupo. Por lo general se aceptará esta solicitud en caso de usuarios pertenecientes a instituciones miembros del comité directivo, ejecutores o socios de subproyectos, u otros usuarios afines al proyecto. En el caso de "otros usuarios afines" el Proyecto GAMA se reserva el derecho de verificar la identidad y la legitimitad de intereses del/a solicitante.

En febrero del 2003, en la oportunidad de una reunión del Comité Directivo del Proyecto realizada en la ciudad de Arequipa, se presentó el sistema, y se aprovechó la presencia de todos los representantes para realizar una capacitación práctica y explicación de detalles del uso del "Monitor". Con la finalidad de tener disponible una computadora para cada participante, se realizó la capacitación en una cabina internet alquilada para tal efecto. Este taller resultó de gran utilidad porque permitió a la vez evaluar el grado de amigabilidad del sistema para usuarios nuevos, así como su aptitud de ser utilizado fuera del espacio de la oficina propia desde cabinas públicas de internet. Concluyendo la autoevaluación positiva en ambos aspectos, el sistema Monitor entró en "producción" y es utilizado desde inicios de marzo del 2004 para las gestiones diarias de los subproyectos de GAMA.

Ilustración 3

4. Experiencias con el "Monitor de Subproyectos"


4.1 Funcionalidad del sistema


4.1.1 Requerimientos logísticos complementarios


A pocas semanas de su introducción algunas instituciones participantes en la gestión de subproyectos comenzaron a indicar sus requerimientos de infraestructura, es decir solicitaron computadoras, lineras telefónicas, suscripciones con ISPs, etc. Siendo estas solicitudes de "upgrading" de sus oficinas fuera del alcance del proyecto GAMA, por no tratarse de un proyecto de fortalecimiento institucional a través de donación de equipos, se optó por ofrecer como alternativa la instalación de un módulo de registro de tiempo en linea de cada usuario en el "Monitor", y asumiendo sobre esta base el reembolso en efectivo del costo de accesos públicos a internet (cabinas, cyber-cafés). A fin de mantener la privacidad de datos de usuarios, esta información no es públicamente visible sino para el administrador del sistema y el área contable de GAMA.

Esta solución ayudó a superar temporalmente el impase de carencia de acceso a internet en las diferentes oficinas de los Gobiernos Reionales. No obstane, dentro del proceso de informatización del Estado Peruano las diferentes oficinas recibieron progresivamente de equipos de oficina actualizados, con lo cual dejó de existir este impase.

4.1.2 Limitaciones de funcionalidad


Si bien existe en principio un "Mod" (una ampliación de funcionalidad) del phpBB que podría permitir adjuntar archivos a las opiniones, se optó por no instalarlo con la finalidad de obtener un expediente electrónico único en vez de una colección de enlaces. La desventaja de la necesidad de "transcripción" de comunicaciones, era -a opinión del administrador- compensada por la ventaja de obtener un expediente uniforme, imprimible y buscable.

No obstante a largo plazo esta decisión resultó poco práctica, en cuanto a la publicación de Términos de Referencias para convocatorias de prestación de servicios, que por su naturaleza son documentos que deben poder distribuirse independientemente del expediente y en lo posible en formato PDF. Durante la segunda fase se optó subir estos documentos manualmente al servidor (mediante FTP), y a partir de la tercera fase del proyecto GAMA se optó por subir estos documentos al CMS (sistema de manejo de contenido) de la página web de GAMA con su respectivo enlace en el Monitor.

Asimismo hubiera sido de utilidad poder subir los informes y productos de los subproyectos al "Monitor" en forma de archivos adjuntos (attachments). No obstante, el software diseñado especificamente para Foros de discusión no posee funcionalidades que hubieran permitido una adecuada sistematización y catalogización de estos informes, quedando accesibles únicamente a traves del expediente respectivo. De tal manera la posterior decisión de publicación de los productos de los subproyectos en una plataforma de Gestión de Conocimientos (el GECO - ver más abajo) ha sido probablemente la mejor opción.

4.1.3 Incidentes


En febrero del año 2006 -es decir después de 2 años de operación in-interrumpidos en línea- el "Monitor" ha sido sujeto a un ataque de hackers, causado por una vulnerabilidad del software recién dedectada, y provocando una desfiguración de su menú y página de portada. Simultáneamente al ataque al "Monitor", miles de otros foros phpBB a nivel mundial han sido atacados. Gracias a una llamada telefónica de urgencia de parte de un usuario leal, el proyecto GAMA ha podido cerrar el acceso al "Monitor" en menos de dos horas después del ataque y tomar las medidas correctivas.

La comunidad de desarrolladores del software había actuado igualmente en forma rápida; al momento de descubrir el ataque a la página del Monitor, ya se había identificado la vulnerabilidad y puesto a disposición el "patch" respectivo. Mediante el respaldo diario automático de la base de datos, el "Monitor" volvió en linea dentro de menos de un día, sin pérdida de datos. Este incidente ha sido el único observado hasta la fecha.

A partir del segundo semestre del 2006 surgió el fenómeno de los "Spambots", computadoras dedicadas a registrarse en forma automatizada en foros con la finalidad de crear en el perfil de usuarios enlaces a páginas web de dudoso contenido. Mientras este fenómeno era inicialmente controlable mediante una depuración semanal de la lista de usuarios registrados, en noviembre del 2006 se optó por la instalación de un "Mod" (ampliación de funcionalidad del software) que permite con razonable certeza distinguir entre usuarios humanos y usuarios robots, y de tal manera frenar estos ataques.

4.2 Repercusión sobre la conducción del proyecto y comportamiento de los usuarios


4.2.1 Adecuación del Reglamento de Subproyectos


La modalidad transparente y públicamente visible de administración de subproyectos ocasionó la propuesta y el requerimiento de varias contrapartes de contar con un reglamento de subproyectos más detallada, que estipula paso por paso las diferentes etapas de gestión de los subproyectos, desde la recepción de su solicitud hasta su cierre, con los respectivos plazos para cada paso.

En la siguiente reunión del Comité Directivo se elaboró y aprobó el respectivo flujo de trabajo y se lo incorporó en el reglamento. A fin de agilizar el trámite de aprobación y ejecución del subproyectos, se incluyó el concepto del "silencio administrativo positivo", en el sentido de "contraparte que no opina dentro del plazo, co-valida la opinión y decisión de aquellos que opinaron".

4.2.2 Participación activa y pasiva - derecho u obligación?


La introducción del sistema del Monitor tenía un efecto importante sobre los mecanismos de participación, en el sentido de diferenciar claramente entre participación activa y pasiva.

Los tradicionales mecanismos de participación de contrapartes en la ejecución de proyectos se caracterizan de ser en la mayoría de los casos "pasivos", es decir: consisten en momentos fuertes en los cuales se invita a los participantes a participar. Sin importar, si la iniciativa de un "momento participativo" surge de una de las contrapartes o de la dirección del proyecto, siempre existe la interacción entre una parte activa (que toma la iniciativa) y las demás partes pasivas (que reciben la invitación a participar). Estos "momenos participativos" pueden consistir en:
  • Talleres y reuniones de trabajo
  • Informes a ser presentados o analizados
  • Coordinación de acciones conjuntas
  • etc.

Mediante el Monitor se creó una nueva modalidad de participación activa y descentralizada, dentro de la cual:
  • Cualquier contraparte es agente del proyecto, y no importa en qué oficina se presenta una solicitud para un subproyecto
  • Cualquier contraparte puede -y debe!- opinar sobre las solicitudes de subproyectos por iniciativa propia, es decir que no recibe una comunicación mediante la cual se solicita explícitamente su participación (opinión), sino debe por iniciativa propia informarse sobre expedientes pendientes en su jurisdicción y tomar las acciones correspondientes (opinar).
  • Mediante el sistema transparente y público de los expedientes electrónicos en tiempo real en Internet, nadie tiene la excusa de no haber sido informado, ya que el proceso pasivo del "derecho de ser informado" es reemplazado por el proceso activo de una "obligación de informarse".

4.2.3 Transparencia como insumo en un proceso de empoderamiento


Uno de los efectos más significativos ha sido probablemente la transparencia de las decisiones en el proceso de aprobación de los subproyectos, fortaleciendo la estrategia de empoderamiento trazada por el Proyecto GAMA.

a) Inclusión y participación
  • Parte de los aspectos participativos -con respecto a las contrapartes- estan descritos en el parrafo anterior.
  • Con la finalidad de que el Monitor no sea exclusivamente un "medio de comunicación" del Proyecto, informando sobre sus decisiones acerca de solicitudes de subproyectos, se creó un Sub-foro de "Comentarios y opiniones sobre Subproyectos específicos" como foro abierto para todos usuarios registrados y afiliados al grupo "Interesados". Este Sub-foro es abierto para que partes interesadas puedan pronunciarse en forma directa en caso de inconformidad con las decisiones, presentar argumentos complementarios o expresar puntos de vista diferentes.
b) Acceso a información
  • Prácticamente en todo grupo de beneficiarios (agrupaciones de mineros artesanales) existen miembros que cuentan con experiencia en el uso de Cabinas Internet, a través de quienes los solicitantes pueden informarse sobre los avances en la aprobación de su solicitud, sin necesidad de incurrir en gastos de viajes para visitas a funcionarios, o llamadas telefónicas frecuantes para mantenerse al tanto.
  • Siendo publicamente accesible cada expediente, un potencial grupo solicitante puede informarse de antemano sobre decisiones en caso de solicitudes similares, y de esta forma evitar la presentación de solicitudes con contenidos fuera del portafolio de servicios del proyecto.
c) Rendición de cuentas
  • Dando públicamente constancia de las gestiones realizadas, los expedientes en el Monitor sustentan las acciones de los dirigentes de los grupos mineros ante sus bases.
  • Consistiendo un expediente de la secuencia de opiniones profesionales de los diferentes funcionarios involucrados en el subproyecto, deja constancia de sus gestiones y rinde cuentas sobre su grado de imparcialidad.
  • Documentando el Monitor todos los subproyectos del Proyecto GAMA, rinde cuentas de sus actividades y permite una evaluación objetiva de su avance y a la vez de las gestiones de sus colaboradores.
d) Capacidad de organización local
  • La visibilidad de logros de grupos organizados que presentaron su solicitud de subproyectos y que en consecuencia han logrado acceso a los servicios del proyecto GAMA, Puede constituirse en un incentivo para otros grupos para organizarse y presentar propuestas similares.

Además de estos elementos, la transparencia de las gestión de subproyectos mediante el Monitor también aportó para una mayor conceptualización del mecanismo de ejecución de subproyectos entre las contrapartes y beneficiarios. Los Subproyectos de GAMA -dentro de su estrategia de empoderamiento y apoyo a la demanda- tienen su origen exclusivamente en una solicitud de un grupo de beneficiarios. De tal manera el mecanismo de los Subpproyectos de GAMA se distingue claramente de otros proyectos de los Gobiernos Regionales, donde la iniciativa nace de la gestión de las Autoridades en base a necesidades identificadas. A travéz del Monitor quedó transparente para todos, qué tipos de (sub)proyectos califican para ser financiados por GAMA, y que propuestas de proyectos no pueden conseguir financiamiento suizo ya que sustituyeran responsabilidades y obligaciones institucionales de las contrapartes o de los propios beneficiarios.

4.2.4 Datos cuantitativos y efectos del uso del Monitor


A finales de la Fase 2, en los años 2004 y 2005, se habían ejecutado 46 Subproyectos:

Ilustración 4

Otras 38 solicitudes han sido denegadas o abandonadas. La transparencia en todos lo 84 expedientes ha tenido como resultado, que en ninguno de estos casos una respuesta negativa (45%) del proyecto GAMA ha sido motivo de un reclamo o queja. Más al contrario, la evaluación externa del proyecto expresó: "El monitor es una herramienta que ayuda a las decisiones compartidas y genera una buena coordinación y comunicación."

A la vez, la participación de los diferentes funcionarios de los Gobiernos Regionales lleva una sorprendente corelación con la cantidad de subproyectos ejecutados en su Región. El orden del numero de opiniones emitidas, con Arequipa en el primer puesto, seguido por Puno, Ayacucho e Ica, refleja exactamente el orden en cantidad de subproyectos ejecutados por Región. Si bien en el caso de los subproyectos de GAMA los Gobiernos Regionales no son las entidades que presentan propuestas para subproyectos, queda claro su rol de facilitador e impulsor para iniciativas de desarrollo de sus ciudadanos.

El Monitor ha demostrado además de ser un sistema muy eficiente para la gestión de subproyectos. Permitiendo a todos a estar informados y participar, su "costo" es mínimo. Por ejemplo, el representante de Arequipa, quien ha contribuido en la fase 2 de GAMA con aproximadamente 70 opiniones y aportes en el Monitor, lleva un registro de alrededor de 15 horas "en linea". Considerando que este tiempo puede triplicarse con tiempo dedicado pero no registrado (revisión de expedientes impresos), el consumo de tiempo para la administración de los subproyectos en el Monitor durante 2 años ha sido un poco más de 1 semanas para 19 subproyectos ejecutados (sin contar visitas de campo).

5. Conclusión (al cierre de la fase 3, 2008)


El sistema del "Monitor" fue desarrollado e implementado con cierto carácter "experimental" en la fase 2 del proyecto GAMA. Habiéndose comprobado la viabilidad de conducir los subproyectos a través de esta herramienta virtual, el Monitor pasó a ser una herramienta indispensable y de uso rutinario en la fase 3 de GAMA.

El reto de la Fase 3 del proyecto era de integrar a través de tecnologías ICT4D la ejecución de subproyectos con la difusión de sus resultados y productos (materiales de capacitación). Para tal efecto se diseñó la Plataforma de Gestión de Conocimientos de la Minería Artesanal (GECO): http://geco.mineroartesanal.comexternal link bajo el software TikiWiki, integrando ambos sistemas mediante enlaces vice-versa.

El conjunto "Monitor - Geco" a finales del 2008 se ha convertido en una de las más visitadas plataformas Internet sobre minería artesanal, con conjuntamente más de 250,000 páginas al més consultadas por visitantes; dando al proyecto GAMA una visibilidad excepcional entre todos proyectos de cooperación en el sector de minería artesanal y contribuyendo a la difusión de sus resultados.





Contribuyentes a esta página: hruschka .
Página última modificacion en Martes 30 de Diciembre del 2008 [06:25:51 UTC] por hruschka.


Lista de archivos adjuntos
  nombre descripción subida tamaño >
1 : 75 icon ilustr_4-small.jpg Lun 06 de Nov del 2006 [18:27 UTC] por hruschka 83.19 Kb 1056
2 : 74 icon ilustr_4.jpg Lun 06 de Nov del 2006 [18:26 UTC] por hruschka 219.04 Kb 401
3 : 73 icon ilustr_3-small.jpg Vie 03 de Nov del 2006 [19:38 UTC] por hruschka 48.80 Kb 1187
4 : 72 icon ilustr_3.jpg Vie 03 de Nov del 2006 [19:38 UTC] por hruschka 181.27 Kb 427
5 : 71 icon ilustr_2-small.jpg Jue 02 de Nov del 2006 [18:53 UTC] por hruschka 52.08 Kb 1071
6 : 70 icon ilustr_2.jpg Jue 02 de Nov del 2006 [18:53 UTC] por hruschka 150.45 Kb 406
7 : 69 icon ilustr_1-small.jpg Jue 02 de Nov del 2006 [17:18 UTC] por hruschka 50.94 Kb 1325
8 : 66 icon ilustr_1.jpg Jue 02 de Nov del 2006 [17:07 UTC] por hruschka 147.55 Kb 422
Menú [ocultar]
Monitor Subproyectos [ocultar]
Gestión Conocimientos [ocultar]
RSS Wiki
Un proyecto de: COSUDE