Modelo de Análisis Costos-Beneficio para Sistemas Integrados de Administración Financiera

Transcripción

1 Banco Interamericano de Desarrollo Sector de Capacidad Institucional y Finanzas Modelo de Análisis Costos-Beneficio para Sistemas Integrados de Administración Financiera DOCUMENTO DE DEBATE # IDB-DP-194 Alejandro Barros Revisión: Jorge von Horoch Enero 2012

2 Modelo de Análisis Costos-Beneficio para Sistemas Integrados de Administración Financiera Alejandro Barros Revisión: Jorge von Horoch Banco Interamericano de Desarrollo 2012

3 Los Documentos de debate y las presentaciones son preparados por funcionarios del Banco y otros profesionales como material de apoyo para eventos. Suelen producirse en plazos muy breves de publicación y no se someten a una edición o revisión formal. La información y las opiniones que se presentan en estas publicaciones son exclusivamente de los autores y no expresan ni implican el aval del Banco Interamericano de Desarrollo, de su Directorio Ejecutivo ni de los países que representan. Este documento puede reproducirse libremente. Banco Interamericano de Desarrollo New York Ave. N.W. Washington D.C Alejandro Barros (abc@alejandrobarros.com), autor; Jorge von Horoch, revisor.

4 Abreviaturas AFP BI CMMI CMMI-ACQ COTS CRM FLOSS ERP GRP KLOC LDSW LOC PF PMI PMO POC RUP SCG SIAF SIAPER SIGFE SIL SLA SLOC SOA TCO TI TIC TIER UFP Puntos de función ajustados Business Inteligence Capability Maturity Model Integration CMMI for Adquisition Commercial off-the-shelf (COTS) Customer Relationship Management (sistemas informáticos destinados a gestión de la relación con clientes) Free and open source software Enterprise Resource Planning (Sistema informáticos integrados de gestión financiera-operacional de organización de diverso tamaño) Government Resource Planning, derivación del concepto ERP para el sector gobierno Miles de líneas de código 1 KLOC = LOC Locally Developed Software (LDSW) Line of Code (líneas de código) Punto de Función Project Management Institute Project Management Office (oficina de gestión de proyectos) Proof off concept (prueba de concepto) Rational Unified Process Sistemas de Control de Gestión Sistemas Integrados de Administración Financiera Sistema Integrado de Administración de Personal, Ministerio de Hacienda, Chile Sistema Integrado de Gestión Financiera del Estado, Ministerio de Hacienda, Chile Specific Investment Loan (préstamo de inversión específica) Services Level Agreement (niveles de servicio) Statment Line of Code (lineas de código de instrucción) Service Oriented Architectura (arquitectura orientada a servicios) Total Cost of Ownership (costo total de propiedad) Tecnologías de Información Tecnologías de Información y Comunicaciones Capa, concepto tecnológico que identifica niveles o capas de una solución tecnológica Puntos de función no ajustados i

5 Indice RESUMEN EJECUTIVO... 1 I. INTRODUCCIÓN... 5 II. PROYECTOS TECNOLÓGICOS EN EL SECTOR PÚBLICO - MARCO CONCEPTUAL... 7 CARACTERÍSTICAS DE PROYECTOS TECNOLÓGICOS EN EL ESTADO... 9 PROCESO DE ADQUISICIÓN SECTOR PÚBLICO CAUSAS DE FRACASOS DE PROYECTOS TIC III. VISIÓN DE LOS GRP S IV. FUNDAMENTOS BÁSICOS DEL ANÁLISIS COSTOS-BENEFICIO COSTOS INICIALES IMPLEMENTACIÓN Y PUESTA EN MARCHA MANTENCIÓN Y SOPORTE CONSIDERACIONES GENERALES V. VARIABLES DE ANÁLISIS COSTOS CONSIDERACIONES CUALITATIVAS VI. MODELO DE EVALUACIÓN MODELO DE EVALUACIÓN - COTS MODELO DE EVALUACIÓN DESARROLLO A LA MEDIDA (LDSW) DIMENSIONAMIENTO FUNCIÓN DE COSTOS VII. ESTUDIOS DE CASOS: NICARAGUA, PERÚ Y CHILE NICARAGUA PERÚ CHILE VIII. CONCLUSIONES IX. BIBLIOGRAFÍA X. ANEXOS EVALUACIÓN DE PROYECTOS TIC PARLIAMENTARY OFFICE UK PRODUCTIVIDAD DESARROLLO DE SOFTWARE - SECTOR PÚBLICO ii

6 Lista de Ilustraciones Ilustración 1: Distribución gasto TIC - Sector Público... 7 Ilustración 3: Elementos de Proyectos TIC - Sector Público... 9 Ilustración 4: Proceso de Adquisición CMMi-ACQ Ilustración 5: Cobertura Funcional SIAF Ilustración 6: Ruta Adopción de ERP Ilustración 7: Elementos de Costo - SIAF Ilustración 8: Estructura Técnica de los SIAF Ilustración 9: Razones para la adopción de un ERP Ilustración 10: Ciclo de Análisis de Costo Ilustración 11: Proceso de Implementación de ERP Ilustración 12: Distribución de costos para ERP Ilustración 13: Dsitribución de costos - Desarrollo de Software Ilustración 14: Cantidad de Proyectos SIAF según duración Ilustración 15: Costos Proyecto SIAF Ilustración 16: Modelo de Costos - Pocos Usuarios Ilustración 18: Modelo de Costos - Gran cantidad de Usuarios Ilustración 19: Programa de Desarrollo SIAF - Perú Ilustración 20: Volumen Transaccional - Perú iii

7 Lista de Tablas Tabla 1: Item de Costos Software Comercial - FLOSS Tabla 2: COTS versus LDSW Tabla 3: Evaluación POC - SIGFE Tabla 4: Escala de Evaluación POC Tabla 5: Resultado de la Evaliación POC - SIGFE Tabla 6: Peso en el esfuerzo total por actividades del proyecto Tabla 7: Diferencial de Impacto de costos - COTS versus LDSW Tabla 9: Costo promedio por usuario - Banco Mundial Tabla 10: Costos de Implantación de ERP Tabla 11: Relación de Costos de ERP's Tabla 12: Diferencial de costos según tipo de ERP Tabla 13: Distribución de costos - SIAF Tabla 14: Cálculo de Complejidad de Puntos de Función Tabla 15: Productiviad de Equipo de Desarrollo en función de tamaño y método Tabla 16: Dimensionamiento de costo desarrollo Tabla 17: Elementos de Costo - Proyecto SIAF Tabla 18: Fuentes de Información - Países en Evaluación Tabla 19: Costos proyecto SIAF - Perú Tabla 20: Costos Componentes iv

8 Resumen Ejecutivo El presente análisis está centrado en identificar las componentes de costos para el diseño, desarrollo y puesta en marcha de Sistemas Integrados de Administración Financiera SIAF. A la interrogante que muchas autoridades públicas de nuestros países enfrentan, al momento de diseñar una estrategia de implantación de un SIAF, nos referimos al modelo de externalización a usar y en particular al enfoque de puesta en marcha, esto es, desarrollo a la medida o producto comercial?, se puede argumentar que hoy existe suficiente evidencia empírica, bibliográfica y modelos teóricos que permiten dimensionar, al menos estimativamente ambos escenarios. El análisis parte de la premisa que la decisión de implementar un SIAF ya está definida y nos encontramos en la segunda etapa del proceso de decisión, esto es, seleccionar entre los escenarios de desarrollo a la medida o implementación de un producto comercial del tipo ERP 1. Para ello se analizan las principales características y especificidades de los proyectos tecnológicos en el sector público, los cuales tienen atributos que les son propios y que impactan directamente en el dimensionamiento del mismo y por ende en sus costos. Como parte del análisis se revisa el estado del arte de las soluciones empaquetadas, las cuales en los últimos años han experimentado importantes mejorías funcionales y de cobertura para dar respuesta a los requerimientos del sector público. El análisis de costos desarrollado, se basa en bibliografía existente y experiencias internacionales en esta materia, las cuales entregan algunos elementos que deben tomarse como base para establecer un enfoque metodológico adecuado para embos escenarios. Desarrollo a la medida (diseño, desarrollo, puesta en marcha y mantención), se deben identificar los potenciales modelos de externalización factibles, nos referimos a desarrollos in-house o bien a contratación de empresas de desarrollo externa. Implementación de productos comerciales (comercial off-the-shelf COTS), se debe considerar costos asociados a licenciamientos, implantación y posterior mantención de estas plataformas, lo cual conlleva un adecuado nivel de cobertura funcional necesaria. Existen algunos elementos que van afectar la decisión, entre las que podemos mencionar, uso de software libre open-source, madurez de la industria y cobertura de las funcionalidades. 1

9 Para responder la pregunta anteriormente planteada desarrollo a la medida o producto comercial?, que se hacen muchas autoridades en materia de diseño y puesta en marcha de sistemas integrados de administración financiera SIAF, su respuesta o al menos una aproximación a ella, de establecer un proceso de análisis de los elementos que permitan una adecuado dimensionamiento del problema, algunos de ellos son: Cobertura y alcance: los SIAFs son de gran complejidad y sus requerimientos funcionales muy amplios, por lo que dependerá de las áreas que se quiera cubrir. La factibilidad de abordarlos con una solución llave en mano y de carácter genérico. Por otra parte el alcance, entendido como las áreas de gobierno (central, estatal y municipal) que se quiere incluir en el proyecto, ya que los requerimientos funcionales, el esfuerzo logístico y de adopción varía según las esferas de gobierno incluidas en el proceso. Mercado proveedor: Un elemento fundamental a la hora de evaluar la mejor alternativa, es la profundidad y calidad del mercado de soluciones tecnológicas ya que esta tiene impacto directo en los costos asociados. En algunos países de la región este mercado no es del todo competitivo, lo cual puede forzar una vía de solución e incrementar los costos de la misma. Experiencia en externalización: Este tipo de proyectos son de gran envergadura y por lo tanto el modelo de externalización es fundamental a la hora de su diseño, ya que la gestión de una firma externa versus consultores individuales requiere de competencias diferentes y de esfuerzos de gestión diferentes. Un mal diseño del proceso de externalización y en particular del proceso de adquisición va a redundar en mayores costos del proyecto. En todo caso, el proceso de toma de decisión por un camino u otro debe sustentarse en datos objetivos, ya que ambas alternativas hoy son viables. El desarrollo de software cuenta con herramientas que permiten dimensionar los proyectos en forma bastante precisa. Los productos comerciales por su parte se ajustan cada vez más a los requerimientos funcionales del sector público y por lo tanto la brecha a cubrir se ha reducido en forma sustantiva los últimos años. Como lo muestra el estudio Financial Management Information Systems del Banco Mundial, la región es bastante más proclive a los desarrollos a la medida que otras regiones, como es el caso de Europa del este, en la cual las alternativas están bastante equilibradas. Producto del análisis realizado, existe potencial de mejora en el proceso de evaluación de las estrategias de implementación de SIAF s en la región, identificando con mayor profundidad las condiciones 2

10 objetivas y métricas específicas de ambos modelos LDSW y COTS, optando por alguno de los enfoques según las condiciones del país. Algunos países de la región, en particular en el área de Centroamérica están avanzando en procesos de evaluaciones de productos envasados, lo cual entregará una mayor claridad de este enfoque, al menos en el contexto regional. Por lo pronto, los países que se encuentran en su fase de evaluación del modelo deben avanzar identificando en forma más precisa algunas métricas funcionales y técnicas que permitan dimensionar mejor el proyecto, nos referimos a: Cantidad de usuarios, idealmente tipificados por funcionalidad y acciones en cada módulo y etapa del proceso (consulta, modificación, otro), Volumen transaccional por tipo de transacción de negocios y periodicidad, Requerimientos de almacenamiento y archiving, Cantidad de puntos de función y/o casos de uso de las funcionalidades necesarias, sean estas en caso de su desarrollo desde cero o bien de la brecha existente en el caso de un programa producto, Costos de infraestructura tecnológica en el país, tanto en términos de inversión de hardware y software básico como de sus costos de mantención por un periodo de 5 años, Niveles de productividad de equipos de desarrolladores de software. En caso de no contar con estos antecedentes, es recomendable realizar algunos supuestos, utilizando métricas internacionales, y así poder mejor estimar estos costos, en todo caso según los antecedentes aportados por diferentes fuentes podemos considerar que un proyecto SIAF, se trata de un proceso de desarrollo e implementación de 24 a 36 meses de duración, con un costo que fluctúa entre 8 y 20 millones de dólares, dependiendo de la cobertura y funcionalidad que se requiere para el sistema. El documento se complementa con algunos estudios de caso, nos referimos a los proyectos de diseño e implantación de sistemas integrados de administración financiera en Nicaragua, Perú y Chile. Cabe señalar que la información existente no aborda totalmente la evaluación entre múltiples escenarios (desarrollo a la medida versus implementación de productos comerciales), ya que más bien se centra en el análisis costo-beneficio de contar o no con un SIAF. Sin perjuicio de ello entregan algunos elementos que permiten al menos contar con antecedentes de dimensionamiento global del proceso que estos países están siguiendo. 3

11 Por otra parte sería razonable que a partir de los antecedentes planteados en el presente discussion paper se realizara un levantamiento más específico y detallado de las métricas de los sistemas hoy en funcionamiento, ya que esos antecedentes pueden servir para un análisis de mayor profundidad al resto de los países. Idealmente contar con métricas de dimensionamiento por área funcional del sistema. 4

12 I. Introducción El presente análisis está centrado en identificar las componentes y la función de costos para el diseño, desarrollo y puesta en marcha de Sistemas Integrados de Administración Financiera SIAF. Como se planteará más adelante, el análisis parte de la premisa que la decisión de implementar un SIAF ya está definida y nos encontramos en la segunda etapa del proceso de decisión, esto es, seleccionar desarrollo a la medida - LDSW 2 o implementación de un producto comercial - COTS 3 del tipo ERP 4. Para ello se analizan en primer lugar las características de los proyectos tecnológicos en el sector público, los cuales tienen atributos que les son propios y que impactan directamente en el dimensionamiento del mismo y por ende en sus costos. Luego se analizarán los SIAF como plataformas integradas que buscan entregar una solución global a la problemática de la gestión financiero-contable del sector público, este tipo de sistemas en el sector privado son conocidos como ERP, con su equivalente en el mundo público denominados habitualmente como GRP 5. Analizaremos las tendencias en este tipo de soluciones empaquetadas y como ellas han abordado en los últimos años con bastante velocidad la problemática pública y sus particularidades. El análisis de costos desarrollado en el punto tercero, revisa la bibliografía y experiencias internacionales en esta materia las cuales entregan algunos elementos que deben tomarse como base para el análisis y que el foco debe centrarse en los siguientes aspectos: Desarrollo a la medida (diseño, desarrollo, puesta en marcha y mantención), identificando los modelos potenciales de externalización, nos referimos a desarrollos in-house o bien a contratación de empresas de desarrollo externa. Implementación de productos comerciales (comercial off-the-shelf COTS), costos asociados a licenciamientos, implantación y posterior mantención de estas plataformas Impacto del uso de software libre en las diferentes modalidades. 2 Conocido comúnmente como: Locally Developed Software (LDSW) 3 Conocido comúnmente como: Commercial off-the-shelf (COTS) 4 Enterprise Resource Planning (ERP), Sistema informáticos integrados de gestión financiera-operacional de organización de diverso tamaño Government Resource Planning 5

13 Para luego abordar las variables de costos y los posibles modelos de análisis, tanto en forma cuantitativa como las variables de carácter cualitativo que deben estar presentes en el análisis. Finalmente se presenta una función de costos con sus componentes y elementos que deben ser considerados al momento de desarrollar un análisis para una realidad específica, que dicho sea de paso varían de un país a otro en función del mercado local, experiencias de la unidad ejecutora y del propio plan de modernización del estado que tenga el país. El documento se complementa con algunos estudios de caso, nos referimos a los proyectos de diseño e implantación de sistemas integrados de administración financiera en Nicaragua, Perú y Chile. Cabe señalar que la información existente no aborda totalmente la evaluación entre múltiples escenarios (desarrollo a la medida versus implementación de productos comerciales), ya que más bien se centran en el análisis costo-beneficio de contar o no con un SIAF. Sin perjuicio de ello entregan algunos elementos que permiten al menos contar con antecedentes de dimensionamiento global del proceso que estos países están siguiendo. El documento cierra con conclusiones emanadas del análisis de la información de costos, los posibles modelos de análisis y criterios que deben ser tenidos en cuenta a la hora de realizar una evaluación de costo específica incorporando las particularidades de cada país, las cuales deben verse reflejadas en la parametrización de los modelos de costeo. 6

14 II. Proyectos Tecnológicos en el Sector Público - Marco conceptual Al momento de evaluar las diferentes alternativas que el Estado tiene para abordar proyectos tecnológicos es importante contar con algunos antecedentes de forma de mejorar el entendimiento de contexto y los elementos que pueden afectar el desempeño de estos. Nuestros Estados son un cliente relevante de la industria tecnológica local. El gasto en TI 6 es muy dependiente del nivel de madurez en la adopción y uso de estas herramientas por parte del Estado, pero en forma complementaria del nivel de la industria local y su capacidad para entregar soluciones que cumplan con las exigencias planteadas (delivery). El nivel de gasto en tecnologías de información en la región bordea el 1% del gasto público, en tanto que en países desarrollados esta cifra llega a cerca del 5%. La consultora Gartner desarrolló un estudio el año 2009 para el gobierno Inglés, con el objeto de identificar la distribución del gasto público en tecnologías de información (TI), del gasto total en TI, el cual representa 4.6% del gasto público, este se distribuye: Ilustración 1: Distribución gasto TIC - Sector Público 7 Gestión y Administración, 11 Datacenter, 19 Mantención- Soporte Aplicaciones, 18 Desktop y preféricos, 11 Desarrollo de aplicaciones, 18 Helpdesk, 7 Redes de datos, 10 Redes de voz, 6 Fuente: Gartner, El gasto TI al igual que la contratación pública en general representan volúmenes muy signficativos

15 En el ciclo de vida de un proyecto podemos identificar básicamente tres grandes fases: diseño, ejecución y operación. Según Feeny (Feeny, 2003) los principales factores (ejes) de riesgo asociados al desempeño de un proyecto tienen relación con tres grandes elementos, esto es: i. tamaño del proyecto, ii. calidad de la definición de los requerimientos y iii. nivel de conocimiento de la tecnología que se quiere emplear. Uno de los elementos que debe evaluarse al momento de una decisión entre desarrollo a la medida y adopción de un producto comercial para abordar la problemática financiero contable del Estado corresponde a los factores de riesgo mencionados y el comportamiento anterior de proyectos similares 8 lo cual es un buen predictor del nivel de riesgo del proyecto en sus dos modalidades. En el gráfico siguiente se muestra el referido espacio tridimensional anteriormente descrito. Ilustración 2: Evaluación de Riesgo - Proyecto TIC Fuente: Adaptación propia a partir de Feeny, Esto puede ser un problema ya que no existen muchos proyectos de la envergadura de un SIAF, lo cual en general no permite contar con antecedentes en esta área. 8

16 En la medida que al momento del diseño del proyecto se pueda situar la posición de este en dicho espacio tridimensional, se podrá tener una buena aproximación del riesgo asociado. Cabe señalar que este ejercicio es sólo una aproximación y no representa un modelo cuantitativo de riesgo, pero resulta un proxy adecuado 9. Características de Proyectos tecnológicos en el Estado Algunos de los problemas que presentan los proyectos tecnológicos dentro del Estado corresponden en general a problemas asociados a su diseño inicial. Es fundamental identificar adecuadamente los elementos que caracterizan a los proyectos tecnológicos en el sector público, más aún cuando un proyecto SIAF corresponde a uno de los proyectos de mayor envergadura de dicho sector. Ilustración 3: Elementos de Proyectos TIC - Sector Público Atributos y Características Proceso Adquisición Mercado Proyectos TIC 9 Para establecer un modelo más preciso de riesgo se recomienda utilizar los enfoque metodológicos del PMI o Prince2 9

17 Los proyectos tecnológicos tienen singularidades propias dentro del sector público, las cuales deben ser atendidas y analizadas al momento del diseño y análisis del mismo. Estas características se han agrupado en tres áreas, gobierno, tecnología y gestión. Gobierno Rendición de cuentas (accountability), el quehacer y los gastos tienen el escrutinio público, por lo que en muchos casos se requiere de una componente importante de difusión del proyecto, actividad que no necesariamente se encuentran evaluada ni dimensionada, ni menos costeada en muchos casos. Tiempos políticos, con frecuencia los proyectos se promocionan antes de su puesta en marcha, lo que afecta desde el punto de vista de la promesa y las expectativas asociadas al resultado, por lo que los proyectos deben identificar entregables intermedios. Cambios en prioridades de gobierno, lo que implica en ciertas circunstancias merma o reducciones de recursos asignados a proyectos. Marco regulatorio más rígido, esto afecta en situaciones en las cuales el proyecto debe rediseñarse y no es posible producto del marco jurídico. Coordinación inter-institucional, En muchos casos se requiere de coordinación interinstituciones, esto incorpora nuevas complejidades ya que se requiere de una visión y compromiso que va más allá de una única institución. Tecnología El cambio tecnológico es en general de gran velocidad, el Estado se mueve lento, lo cual en ciertas ocasiones le produce que las soluciones se tornen obsoletas. En general los proyectos tecnológicos dentro del estado tienen alta complejidad debido a los niveles de integración y volúmenes asociados (gran cantidad de transacciones, usuarios y/o volúmenes de datos). El nivel de desarrollo tecnológico de los servicios público es muy heterogéneo. Se pueden apreciar instituciones con un gran desarrollo, habitualmente cercanas al gobierno central 10, otras con un bajo nivel de desarrollo, tal es el caso de algunos municipios y/o servicios públicos pequeños. Gestión Falta de habilidades de gestión y administración de proyectos tecnológicos 10 Las áreas del gobierno central donde se aprecia el mayor nivel de desarrollo tecnológicos y mayores niveles de madurez para enfrentar este tipo de proyectos se encuentran en el gobierno central asociadas al ministerio de hacienda y/o finanzas 10

18 Contratos de alta complejidad en su diseño y posterior administración Niveles de servicio (SLA's) mal definidos y/o no administrados Pobre gestión de proveedores, con un enfoque en algunos casos no cuidan la relación comprador-proveedor Esto elementos deben ser considerados al momento del diseño y ejecución del proyecto. Proceso de Adquisición Sector Público Una de las etapas del ciclo que pueden tener un impacto importante sobre los proyectos tecnológicos son los procesos de adquisición asociados, en particular cuando se refiere a procesos licitatorios extremadamente rígidos. En esta etapa podemos mencionar algunos factores identificados por el sector privado (grandes proveedores tecnológicos) y sector público nacional (grandes servicios públicos) 11, que afectan el desempeño final de un proyecto tecnológico, entre estos se puede mencionar: Sector Público Las principales dificultades que enfrentan compradores del sector público al momento de adquirir soluciones y proyectos tecnológicos corresponden a: Ausencia de mecanismos que permitan negociar con el mejor calificado de los oferentes. Adopción de metodologías de desarrollo/diseño no probadas y con poca experiencia local. La falta de una oferta de calidad en el mercado local Sector Privado Las principales dificultades que enfrentan proveedores tecnológicos al momento de ofertar soluciones y proyectos tecnológicos corresponden a: Presupuestos no acordes con los costos reales de la solución; Modelo contractual excesivamente rígido; Proceso licitatorio mal definido y/o con tiempos inadecuados. 11 Encuesta desarrollada por la Dirección de Compras Públicas Ministerio de Hacienda, Chile, durante el año 2005, la cual se ha tomado como base para implementar instructivos a los servicios públicos para en procesos licitatorios de Tecnología de Información. 11

19 En cualquier proyecto tecnológico de relevancia y en particular un proceso de adquisición de una plataforma SIAF para el Estado, sea esto en modalidad de desarrollo a la medida o de adquisición de productos, en ambos casos el proceso de adquisición es fundamental. El proceso de adquisición debe estar estructurado y seguir algún modelo estándar que le permita monitorear el proceso y reducir los riesgos que este plantea. Un modelo que resulta especialmente adecuado para estos procesos es el planteado por el Software Engineering Institute de la Universidad Carnegie Mellon, bajo el paragua metodológico CMMI 12, nos referimos al marco metodológico CMMI for Adquisition (CMMI-ACQ) versión Lo primero que un proceso de contratación debe reconocer, es que algunas actividades del proceso están bajo el control directo del mandante y otras, si bien el mandante puede tener algún tipo de supervisión su nivel de influencia es menor, nos referimos a aquellas actividades que deben ejecutar los proveedores. Por otra parte, los líderes del proceso de contratación, y dadas las características de los SIAF, deben establecer procesos flexibles y ágiles, que permitan la generación de productos adaptables y con entregas parciales en periodos relativamente cortos de tiempos. Es fundamental que el proceso de contratación se inserte como parte del proceso completo y no como un apéndice, tal como lo plantea CMMI el proceso de contratación debe estar relacionado directamente con elementos que anteceden y que son posteriores al proceso de adquisiciones

20 Ilustración 4: Proceso de Adquisición CMMi-ACQ Gestión de Proyectos Adquisición Soporte En cada una de estas actividades se plantean prácticas que definen un proceso estructurado para la adquisición. Gestión de Proyecto: Fase inicial del proyecto en la cual se definen los aspectos centrales de su diseño y posterior administración, como parte de esta etapa del proceso se deben considerar, planificación, monitoreo y control, gestión integrada, gestión de requerimientos y administración del riesgo. Adquisición: En la etapa de contratación se contemplan una serie de prácticas que dicen relación con dicho proceso, estos es, desarrollo y solicitud de proveedores, gestión de cambios, desarrollo de requerimientos, gestión técnica de adquisición, verificación de adquisición y proceso de validación de adquisición. Soporte: En esta etapa del proceso se definen las prácticas asociadas a etapas tardías del mismo, nos referimos a, gestión de la configuración, toma de decisiones y resolución de conflictos, análisis y métricas y aseguramiento de calidad. Durante la etapa de adquisiciones, las buenas prácticas identificadas por el estándar CMMI-ACQ permiten que se establezca un circuito ordenado y que se cuenten con elementos centrales de un proceso de adquisición que reduzca los riesgos inherentes a la complejidad que plantean este tipo de actividades. 13

21 Causas de Fracasos de Proyectos TIC Al mirar el comportamiento de los proyectos tecnológicos 14, aparecen algunos elementos que se repiten y que en general pueden asociarse al fracaso de los mismos. Estos elementos van a estar presentes en mayor o menor medida dependiendo de la madurez de la institución y de los equipos de proyecto que pueda conformar, en el caso de los SIAF y producto de la envergadura de estos proyectos algunas de estas causales deben monitorearse con mayor frecuencia y profundidad. Entre las principales causas de fracasos de los proyectos se pueden mencionar: Falta de vínculo entre el proyecto y las prioridades estratégicas de la institución; Falta de liderazgo y ownership del proyecto; Falta de habilidades de gestión de proyectos y administración del riesgo; Poco conocimiento de la industria tecnológica y de los proveedores; Evaluación de propuestas con mirada de corto plazo sustentado en oferta económica y no en función del valor del gasto; Pocas iniciativas para segmentar los proyectos en tamaños más manejables; Arquitectura tecnológica mal definida. Una herramienta que puede ayudar en esta etapa es la pauta de evaluación desarrollada por la Parliamentary Office of Science and Technology (Government IT Projects) en el Reino Unido 15, cuya finalidad es evaluar un proyecto en particular sobre la base de factores de éxito y fracaso para 16 áreas, las cuales pueden determinar la evolución de un determinado proyecto, se adjunta como anexo al presente documento. Es fundamental que a la hora de diseñar el proyecto se tomen en consideración estos elementos ya que independientemente de si la solución que se adoptará es un enfoque de desarrollo a la medida o de implantación de un producto comercial o un mix de ambos, estos tendrán un impacto significativo en el proceso. Cualquiera sea el caso, los elementos señalados van a afectar de diversa forma, por lo que tomarlos en cuenta a la hora del diseño contribuirá a reducir riesgos y sobre costos. 14 Algunos análisis recientes como el desarrollado por Bent Flyvbjerg y Alexander Budzier de la Universidade de Oxford han mostrado que 1 de cada 6 proyesctos e transforma en lo que se denomina proyecto Cisne Negro, en el cual los sobrecostos superan el 200% y los sobretiempos el 70%, mas información en: