Estrategias de Desarrollo e Implantación de Sistemas Integrados de Administración Financiera: Experiencias y Lecciones para América Latina Gerardo Uña*

Presentación del tema: "Estrategias de Desarrollo e Implantación de Sistemas Integrados de Administración Financiera: Experiencias y Lecciones para América Latina Gerardo Uña*"— Transcripción de la presentación:

1 Estrategias de Desarrollo e Implantación de Sistemas Integrados de Administración Financiera: Experiencias y Lecciones para América Latina Gerardo Uña* Noviembre 2011 *Licenciado en Economía, Jefe de la Unidad Ejecutora del Proyecto Sistema de Información para la Gestión Financiera del Estado, Dirección de Presupuestos, Ministerio de Hacienda de la República de Chile. guna@dipres.gob.cl.guna@dipres.gob.cl

2 Situación Actual  En América Latina existe una creciente demanda por modernizar los SIAF´s.  La mayor parte de los SIAF ´s se encuentra en operación desde mediados de la década pasada, presentando debilidades en: 1.Limitaciones funcionales 2.Problemas a nivel de cobertura institucional 3.Baja capacidad para interoperar 4.Problemas de usabilidad 5.Debilidades en la generación de Reportes 6.Ausencia de funcionalidades destinadas a generar información para la evaluación de desempeño 7.Problemas de actualización tecnológica - 2 -

3 Módulos de un SIAF Fuente: Adaptación propia en base a Dener, C.; Watkins, J., and Dorotinsky, W. (2011) - 3 -

4 Tres generaciones de SIAF - 4 -

5 Características de un Proyecto SIAF  Los proyectos de desarrollo de un SIAF presentan gran complejidad: 1.En promedio tienen una duración de 8 años* 2.Tienen un costo promedio de USD 15 mil por usuario** 3.Implican modificaciones en forma transversal en el sector público  Por lo general una solución de tipo SIAF es de gran volumen, presentando en promedio 10.000 puntos de función.  Al año 2009, una de cada tres aplicaciones de gran escala, 10.000 puntos de función o más, será cancelada y no se culminará el proyecto. (Caper Jones, 2009) */** Fuente: Dener, C.; Watkins, J., and Dorotinsky, W. (2011) - 5 -

6 Alternativas de Desarrollo de un SIAF  Al iniciar un proceso de desarrollo de una nueva versión del SIAF los decisores públicos se enfrentan a un conjunto de opciones: 1.Desarrollo a Medida (LDSW) 2.Parametrizacion de un Aplicativo Comercial (COTS) 3.Combinación de Desarrollo a Medida + Parametrizacion de Aplicativo Comercial  La estrategia de desarrollo de la nueva versión del SIAF debe realizarse sobre la principales definiciones funcionales y la definición de una arquitectura tecnológica de base. - 6 -

7  Para la definición de los principales requerimientos funcionales es de suma utilidad el desarrollo de un Modelo Conceptual de la administración financiera pública que contenga, al menos, los siguientes aspectos: –Objetivo, alcance y cobertura del sistema –Definición de las principales reglas de negocio relativas a: Integración automática del plan de cuentas y el clasificador presupuestario Reglas de cierre y apertura presupuestario y contable mensual y anual Reglas para la elaboración de escenarios en la etapa de formulación –Nivel de aplicación del principio de centralización normativa / descentralización operativa –Implementación de la Cuenta Única del Tesoro (cuando aplique)  En esta etapa es de suma utilidad la metodología BPM para la optimización de procesos Definiciones Funcionales - 7 -

8  A su vez, es necesario definir las principales características funcionales del SIAF, en particular las relacionadas con : –Funciones de apoyo a la gestión financiera –Funciones de apoyo a la gestión administrativa –Funciones de apoyo a la tareas de auditoria –Generación de Reportes en formatos flexibles –Funciones de apoyo para el Marco de Gasto de Mediano Plazo –Funciones de apoyo para la captura y seguimiento de metas e indicadores de desempeño –Funciones de apoyo para la Evaluación de Programas Definiciones Funcionales - 8 -

9  La adopción de una arquitectura tecnológica de base común para el SIAF sirve para establecer los lineamientos generales a utilizar en todos los módulos que conforman el sistema de administración financiera  Es necesario identificar y priorizar los atributos de calidad del SIAF requeridos por los principales actores de la administración financiera pública, así como identificar las capas de software comunes a todas las aplicaciones.  Definir capas de arquitectura comunes, que permitan unificar, por ejemplo, aspectos de conectividad o seguridad.  El desarrollo de un SIAF se produce en etapas, generalmente asociadas a las fases del ciclo presupuestario. Por lo tanto, es necesario reducir al mínimo posible los problemas de integración entre sus distintos módulos.  A su esta vez situación también facilitará la operación y mantención del sistema en la etapa de producción. Definiciones Arquitectura Tecnológica de Base - 9 -

10 Estrategia de Desarrollo: Ejemplos de definiciones iniciales Atributos de calidad del SIAF: 1.Oportunidad de la información 2.Desempeño 3.Capacidad de incorporar nuevos campos de información en forma rápida (flexibilidad) 4.Capacidad de interoperar con otros sistemas de información 5.Potencialidad de conectividad que permitan cubrir tanto el gobierno central como los gobiernos locales, 6.Seguridad - 10 -

11  En base a los atributos de calidad identificados y a la definiciones funcionales será posible definir una arquitectura tecnológica de base, considerando las siguientes opciones: –Arquitectura cliente-servidor vs arquitectura web –Desarrollo bajo enfoque multicapas vs desarrollo bajo enfoque BPM+SOA  Definir el stack de software de base, por ejemplo sistemas operativos y motores de BBDD, que compondrán la arquitectura básica sobre la cual se desarrollará y operará el SIAF.  Definir si se utilizará software libre (open source) o software propietario, o la forma en que se combinarán ambos. Estrategia de Desarrollo - 11 -

12 Principales opciones para desarrollar e implementar un SIAF: i)Desarrollo a medida, o “Locally Developed Software” (LDSW), mediante dos estrategias: a)Utilización de recursos internos o recursos externos gestionados en forma directa por el sector público, alternativa denominada “in house”. b)Tercerización del desarrollo a firmas privadas. ii) Parametrización de un paquete comercial de software, o “Commercial-off-the-Shelf”(COTS) Estrategia de desarrollo: LDSW vs COTS - 12 -

13 Una actividad que debería realizarse para escoger entre estas opciones es la realización de Pruebas de Concepto con soluciones COTS. Estas POC necesariamente deben cubrir aspectos funcionales y de arquitectura tecnológica, bridando información objetiva sobre las potencialidades y restricciones de un aplicativo COTS. La solución COTS debería cubrir como mínimo el 60% de los requisitos, preferentemente el 80%. Estrategia de desarrollo: LDSW vs COTS Desarrollo a Medida (LDSW) Aplicativo Mercado (COTS) Evaluar Brecha 0%60%80%100% Cobertura Funcional - 13 -

14  En caso que se descarte la opción COTS resulta necesario evaluar las alternativas para realizar el desarrollo a medida del SIAF. Dos alternativas principales: a)Desarrollo mediante la utilización de recursos internos o recursos externos gestionados en forma directa por el sector público (in house). b)Tercerización del desarrollo a firmas privadas.  De ser posible se recomienda tecerización, ya que los requisitos para desarrollo in house son elevados: procesos de calidad implantados y maduros, sólida metodología de gestión de proyectos Número de recursos humanos variables en el tiempo, con expertises muy específicos de acuerdo a la demanda del proyecto, Estrategia de desarrollo: LDSW vs COTS - 14 -

15  Otros factores que desincentivan la opción in-house: Menor presión hacia los actores involucrados en las definiciones funcionales y en la aprobación de los artefactos de desarrollo para cumplir con el alcance, el costo y la calidad originalmente definidos, en el plazo esperado. La opción de contratación de consultores individuales o de fábricas de software, tiende a subir costos en el largo plazo debido a los costos administrativos que genera y a una inercia institucional que alarga los plazos y promueve un desarrollo extremadamente gradual. Estrategia de desarrollo: LDSW vs COTS - 15 -

16  Posibilidad de plantear la estrategia de tercerización del desarrollo como una estrategia “mixta” de carácter iterativo e incremental: El sector público, a través del Ministerio de Hacienda / Finanzas, realiza las principales definiciones funcionales y tecnológicas, El sector privado desarrolla el aplicativo, El sector público realiza el testing final para su aceptación y puesta en producción.  Estrategia de desarrollo tercerizado, implica evaluar nivel de madurez del mercado de software local y regional en: La arquitectura tecnológica de base definida Capacidad de asimilar los principales aspectos funcionales de un sistema de administración financiera Adopción de modelos de calidad (ej. CMMI) y de gestión de proyectos (ej. PMI). Estrategia de desarrollo: LDSW vs COTS - 16 -

17 Condicionantes que promueven el éxito de estos proyectos: 1.Apoyo de las máximas autoridades 2.Participación de Organismos Internacionales 3.Fortalecimiento de las capacidades institucionales del sector público. 4.Planificar resultados de corto plazo 5.Implementación de un Comité de Usuarios Estas condiciones no garantizan por sí solas una reforma exitosa de los SIAF, pero su ausencia condiciona fuertemente las posibilidades de éxito Principales Condicionantes - 17 -

18  Análisis de las mejores prácticas en desarrollo de sistemas de administración financiera en temas tales como: nivel de profundidad del enfoque BPM + SOA en un desarrollo a medida, las formas de licenciamiento en la parametrización de una aplicativo de mercado, Buenas prácticas en las actividades de testing, La definición de las estrategias de implementación (gradual o big bang).  Integración entre el Clasificador Presupuestario y el Plan de Cuentas Contables ¿Es posible la integración del clasificador presupuestario y el plan de cuentas contables en un solo catalogo? ¿Qué fortalezas y debilidades presenta esta opción? ¿Tiene impacto en la usabilidad del sistema de administración financiera? ¿y en la generación de estados y reportes? Agenda Pendiente - 18 -

19  Beneficios y riesgos de la interoperabilidad. La interoperación se plantea como una funcionalidad homogénea, pero existen diferencias significativas en las demandas funcionales y tecnológicas en su interior. Por ello es preciso analizar: Requisitos de la interoperación con sistemas transversales y operados en forma centralizada (ej sistemas de compras y contrataciones) Requisitos de la interoperación con sistemas de propios de cada institución.  Considerando que a nivel conceptual el Presupuesto por Resultados aún se encuentran en una etapa de desarrollo es necesario plantear: ¿Cuál es su nivel óptimo de integración con el SIAF? ¿Un SIAF debe contener y capturar información asociada al cumplimiento de indicadores de desempeño, metas, y resultados de las políticas públicas? ¿o esta información debe alojarse en los sistemas de los Ministerios Sectoriales? Agenda Pendiente - 19 -

20 Principales Conclusiones  Al iniciar un proceso de desarrollo de una nueva versión del SIAF los decisores públicos se enfrentan a un conjunto de opciones: Desarrollo a Medida (LDSW) vs Parametrizacion de un Aplicativo Comercial (COTS).  La estrategia de desarrollo de la nueva versión del SIAF debe realizarse sobre la principales definiciones funcionales y la definición de una arquitectura tecnológica de base.  Un proyecto SIAF dura en promedio 8 años, tienen costos que superan los USD 5 millones, y son de un tamaño superior a los 10.000 puntos de función. (1 de cada 3 aplicativos de este tamaño fracasa)  Por lo tanto, planificar el proceso de definición de la estrategia de desarrollo es una condición necesaria para el éxito de un proyecto SIAF - 20 -

21 - 21 -