• Modernizar Infraestructura TI: El modelo plantea como base de la pirámide, el conceptos de arquitectura basada en servicios (SOA), el que pemite contar con bases de datos, middleware y aplicaciones diseñadas y desarrolladas en base a estándares abiertos e interoperables.  Esta arquitectura permite que diversos proveedores y soluciones puedan interactuar e interoperar.

• Aumentar eficiencia y transparencia: Las organizaciones de gobierno tienen una fuerte presión frente a los servicios que debe entregar a los ciudadanos, estos deben promover aumentos significativos de la eficiencia del organismo público.  En este nivel se debe incluir servicios en la modalidad de servicios compartidos (poner URL articulo share services), automatización de procesos de negocios y contar con un esuqema de gobierno TI.  Para esto se deben implementar tableros de control en el ámbito financiero, presupuestario, recursos humanos y de adquisiciones que le permitan a los directivos públicos monitorear le entrega de servicios y aumentar el accountability.

• Transformar Entrega de Servicios:  En la punta de la pirámide se plantea como desafío transformar los servicios electrónicos y su forma de entregarlos - delivery -.  Esto debe traducirse en una plataforma común para esos servicios, en lugar de desarrollos ad-hoc para cada ventanilla.  Esta plataforma debe proveer de mecanismos para parametrizar los servicios según los requerimientos y acceso de diferentes canales, móvil, voz, internet, etc.

Me parece un modelo general interesante que da luces para establecer una arquitectura más homogénea y que de cuenta de los requerimientos actuales en la modernización del estado y en particular de su desarrollo en servicios electrónicos.

Si quieren leer el documento de Oracle, lo pueden bajar desde aquí -  IGovernment

La oficina de presupuestos del gobierno federal americano, denominada OMB, desarrolló un modelo denominado FEA Federal Enterprise Architecture, es probable que el nombre en castellano no sea muy feliz, por lo que uno mejor sería AEG, es decir Arquitectura Empresarial Gobernamental, cuyo propósito fue simplificar y unificar los procesos entre las diferentes agencias públicas. El resultado fue un enfoque metodológico de diseño centrado en el ciudadano, que maximiza las inversiones en TI y logra mejores resultados.

El Federal CIO Council adoptó principios que gobiernan y representan los criterios con los cuales se pondera toda la inversión y las decisiones arquitectónicas empresariales para las agencias federales de los Estados Unidos, este framework entrega un modelo que permite a los gobiernos desarrollar las transformaciones en forma ordenada y consistente.  El modelo se basa en los siguientes componentes:

FEA  (Federal Enterpise Architecture) es una colección de modelos de referencia correlacionados diseñados para facilitar el análisis y la identificación de inversiones duplicadas, diferencias y oportunidades para la colaboración dentro y a través de las agencias federales, como se gráfica en el siguiente diagrama:

Los modelos definidos son:

Modelo de Referencia del Negocio (BRM por sus siglas en inglés)
Es el modelo que provee de una plataforma para facilitar una perspectiva funcional (en vez de una organizacional) de las líneas de negocio del gobierno federal, incluyendo sus operaciones internas y servicios para ciudadanos, independientemente de las agencias y oficinas que las realizan. Esto promueve la colaboración entre agencias y oficinas y sirve como fundación base para la Arquitectura Empresarial Federal y la estrategia eGov.

Modelo de Referencia de Desempeño (PRM)
Es una plataforma para medir el desempeño a través de todo el Gobierno Federal de EEUU, que le permite a las agencias gestionar el negocio del gobierno a nivel estratégico, entregando formas de utilizar la EA para medir el éxito de las inversiones en TI y su impacto sobre los resultados estratégicos.  El PRM cumple estas metas estableciendo un lenguaje común, a través del cual las EA’s de las agencias describen sus resultados y métricas utilizados para alcanzar los objetivos del programa y del negocio. La estructura del PRM está diseñada para expresar claramente las relaciones causa – efecto entre entradas y salidas. Esta Línea de Visibilidad se implementa a través del uso de una estructura jerárquica: Área de Medición, Categoría de Medición, Grupo de Medición e indicador.

Modelo de Referencia de Datos (DRM por sus siglas en inglés)
El DRM ha sido diseñado con la intención de promover la identificación, uso e intercambio apropiado de los datos y la información a través del gobierno federal por medio de la estandarización de los datos en contexto, intercambio y descripción.  Uno de los problemas más frecnuentes que encontramos en el estado es la falta de estándares de interoperabilidad e intercambio de información.

Modelo de Referencia de Aplicaciones-Capacidades (ARM por sus siglas en inglés)
Es una plataforma enfocada al negocio, que clasifica los componentes de servicio de acuerdo a cómo soportan al negocio y a los objetivos de desempeño.
Sirve para identificar y clasificar componentes de servicio horizontales y verticales que soportan agencias federales y sus inversiones en TI y activos. El modelo ayuda en recomendar características de servicio que puedan soportar el re uso de los componentes de negocio y servicios a través del gobierno federal.

Modelo de Referencia Técnico (TRM por sus siglas en inglés)
El TRM es un marco que categoriza los estándares y tecnologías para soportar y habilitar la entrega de los Componentes de Servicios y capacidades. Además, unifica los modelos técnicos existentes por agencia y la propuesta del Gobierno Electrónico, entregando una fundación para avanzar en la re utilización y estandarización de la tecnología y Componentes de Servicio desde una perspectiva global del gobierno.

Si desean revisar la descricpión de la arquitectura les recomiendo este link en el cual se describo con mayor detalle cada uno de los modelos de referencia.

Es de esperar que nuestros estados evoluciones haca un esquema de arquitectura empresarial que permita diseñar y desarrollar servicios de gobierno electrónicos más confiables, consistenes y de real valor agregado para el ciudadano que es el receptor final de los servicios del Estado, destanatario que perdemos de vista al momento de implementar políticas públicas.

Proyectos TIC en el Sector Público

Algunas cifras
El estado chileno según un estudio desarrollado por la Dirección de Presupuestos con cifras presupuestarias del año 2003, gasta en tecnologías de información y comunicaciones (TIC) aproximadamente 205 millones de dólares anuales, lo cual representa un 2.3% del gasto total del estado y aproximadamente 0.2% del PIB. Lo cual si bien es un buen porcentaje comparado con el gasto promedio en TIC a nivel nacional correspondiente al 1.66% de la facturación, está muy por debajo del gasto en tecnologías de información en otras latitudes como en el caso del Reino Unido donde llega al 1% del PIB. Según el mismo informe se demuestra que el gasto se concentra mayoritariamente en el ítem servicios computacionales.

¿Qué ocurre con los proyectos?
Las cifras respecto del desarrollo y comportamiento de proyectos TIC existentes no son muy alentadoras, según estudios realizados por Standish Group en USA y la Universidad de Oxford en el Reino Unido, sólo el 16% de los proyectos TIC son exitosos (se considera exitoso, proyectos que han terminado utilizando los recursos y tiempos inicialmente planificados). Si el análisis se restringe sólo a proyectos de desarrollo de software esta cifra baja al 1%.

Otro elemento interesante de destacar de dicho estudio es que tanto el sector privado como público mantienen tasas de éxito equivalentes.

Estructura de Proyecto
El ciclo de vida de un proyecto podemos identificar básicamente tres grandes fases, diseño, ejecución y operación. Los factores de riesgo los podemos visualizar en un espacio tridimensional en el cual los ejes son: tamaño del proyecto, calidad de la definición de los requerimientos y nivel de conocimiento de la tecnología necesaria. En la medida que al momento del diseño del proyecto pueda situar mi proyecto en dicho espacio, esto me va a dar ciertas luces del riesgo asociado.

Caracterísiticas de Proyectos TIC en el Estado
Los proyectos TIC 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 se pueden segmentar en tres áreas:

Gobierno:

• Los gastos en el estado tienen el escrutinio público (accountability)
• Con mucha frecuencia se promocionan proyectos antes de su puesta en marcha, lo que pone una presión excesiva para su término
• El ámbito público tiene un marco jurídico y regulatorio bastante rígido. El derecho público regula lo que se puede hacer (sólo lo que está dicho)
• En muchos proyectos se requiere de coordinaciones interinstituciones lo que complejiza los proyectos.

Tecnológicos:

• La velocidad del cambio tecnológico es extremadamente acelerada, lo que no está de acuerdo con las velocidades de cambio en el sector público.
• En general las soluciones tecnológicas en el estado están asociadas a grandes volúmenes transaccionales y de procesamiento, lo que plantea un gran desafío al momento de definir las arquitectura tecnológicas necesarias
• El nivel de desarrollo tecnológico dentro del estado es muy heterogeneo, lo que hace muy complejo definir soluciones de carácter global.

Gestión:

• Se requieren habilidades de gestión y administración de proyectos tecnológicos complejos
• Los contratos son de alta complejidad, tanto en su diseño, como en su posterior administración.
• Existe una pobre administración de proveedores, ya sea por desconocimiento y/o por restricciones reglamentarias

Causas de Fracasos de Proyectos TIC
Entre las principales causas de fracasos de los proyectos tecnológicos puedo mencionar:

• Falta de vínculo entre el proyecto y las prioridades estratégicas de la institución
• Falta de habilidades de gestión de proyectos y administración del riesgo
• Falta de liderazgo y ownership del proyecto
• Poco conocimiento de la industria TI local y de lo que realmente puede proveer.
• Presupuestos mal definidos
• Evaluación de propuestas con mirada de corto plazo sustentado en oferta económico y no en valor del gasto
• Pocas iniciativas para segmentar los proyectos en tamaños más manejables
• Arquitectura tecnológica mal definida
• Niveles de servicio (SLA's) mal definidos y/o no administrados

• Aumentar el esfuerzo en las etapas tempranas del proyecto (diseño) considerando todas las etapas
• Conformación de los equipos de trabajo con las competencias y habilidades requeridas
• Establecer owner de los proyectos complejos al más alto nivel de la institución
• Compartir experiencias (éxitos y fracasos) a nivel de ejecutivos TI del estado
• Establecer programas de certificación y competencias en gestión de proyectos tecnológicos
• Establecer centros de competencia que puedan servir de referencia y apoyo
• Establecer relaciones adecuadas con proveedores