Proyectos de alto riesgo

Uno de los problemas más frecuentes vinculados a fracasos en proyectos TIC, particularmente dentro del Estado, es cuando estos se abordan utilizando algún esquema de externalización; es un mal diseño del proyecto y fundamentalmente de los procesos licitatorios que lo acompañan.

Es muy frecuente en esos casos encontrarse con bases y términos de referencia mal diseñados, en los cuales los problemas más habituales son:

• Objetivos y alcances poco claros, esta área de las bases es fundamental y la que entrega el marco referencial de lo requerido, su ámbito y áreas que se espera cubra el proyecto.

• Producto y entregables no especificados del todo. Cuando existen productos claros el proveedor puede dimensionar esfuerzo y validar su oferta, esto es particularmente cierto en el caso de servicios (implantaciones, consultorías y asesorías, desarrollos de software, etc.). Es importante que el comprador no se entusiasme pidiendo más de lo razonable por el presupuesto asignado.

• Tiempos, con mucha frecuencia se observan bases en las cuales se expresa la urgencia del comprador de tener terminado el proyecto pero se olvida que el desarrollo de un proyecto TIC como cualquier otro requiere de sus tiempos. Creo que un dicho que aplica en estos casos es nueve mujeres no gestan una guagua en un mes y el problema no se resuelven poniendo equipos de trabajo más grandes como lo esperan algunos compradores.

• Presupuestos que no dicen relación con los productos/servicios requeridos, ya sea por desconocimiento o bien por no realizar un estudio acabado de costos.

Como una manera de graficar esto, quiero mencionar sólo dos ejemplos de procesos licitatorios recientes en los cuales se produce algunas de las situaciones señaladas anteriormente.

Ejemplo Nº 1: Evaluación diagnóstica del soporte tecnológico para la gestión de recursos humanos en Servicios Públicos.

Presupuesto asignado: $ 30.000.000 (aproximadamente 1.634 UF o 55.587 dólares)

Realizando una estimación rápida de recursos sobre la base de los objetivos y alcances y considerando unos 180 servicios públicos potenciales para la evalución, los recursos destinados para la referida evaluación es de 9 UF's por servicio, si consideramos el siguiente esfuerzo por actividad a realizar

(a) Preparación de entrevista/pauta = 30 minutos
(b) Realización de entrevista de levantamiento = 2 horas
(c) Evaluación de antecedentes = 2 horas
(d) Informe final = 2 horas

Lo que corresponde a 6.5 horas-hombre por institución, lo que algunos de ustedes me dirán es un número ridículamente bajo, el valor de la hora-hombre estimada por el servicio público para realizar el diagnóstico es de 1.38 UF/hora-hombre, esto sin considerar ningún otro costo, recordemos que muchos de los servicios públicos están en regiones por lo que al valor anteriomente estimado hay que restarle costos de traslado y estadía.

Ejemplo Nº 2: Desarrollo de un sistema en ambiente web con múltiples usuarios de gran transaccionalidad, los objetivos específicos son: "Diseñar e implementar un sistema de información basado en servicios de Internet, que permita rescatar, almacenar y gestionar los documentos electrónicos, de forma tal que permita al Servicio Público cumplir con su rol" (se han omitido los nombre de instituciones y aquellos detalles que permitan identificarla pero la idea central del objetivo se mantiene)

Presupuesto asignado: $ 12.000.000 (aproximadamente 654 UF o 22.195 dólares)
Tiempo: 16 semanas

Considerando los valores de obtenido en una reciente licitación de desarrollo de software realizada por la Dirección de Compras Públicas, los valores jornada de un equipo de desarrollo estándar compuesto por (0.3 jefe de proyecto, 1 analista, 3 programadores y 1 especialista en QA) los valores obtenidos es de 11 UF/día por equipo de desarrollo, lo anterior significa que el sistema en cuestión para desarrollarse debiera hacerse en 59,4 jornadas.

Si el proyecto tiene asignada 16 semanas esto equivale a 80 jornadas (16*5) el presupuesto es insuficiente.

Por otro lado las bases son absolutamente elementales para describir el problema y claramente llevarán a confusión a quien quiera analizar el requerimiento.

Lo peor de todo es que muy probablemente para ambos casos existirán proveedores que se presenten y finalmente lo que tendremos son dos proyectos en que expectativas y resultados no coincidirán, presentando un potencial de fracaso al menos utilizando la definición de proyecto exitoso (cumplimiento de plazos, recursos y los productos requeridos originalmente) y la probabilidad de tener al final del camino dos proyectos fracasados es alta

Es de esperar que algún día aprendamos la lección!!

Arquitectura Tecnológica Empresarial

Una pregunta frecuente que se escucha de los ejecutivos de tecnologías de información, al menos los que tienen la inquietud, porque conozco bastantes casos en los cuales la pregunta ni siquiera existe. Volviendo al primer grupo la inquietud que surge es: ¿cuál es la arquitectura tecnológica adecuada para mi organización? creo que un buen punto de partida para analizar esto es un estudio realizado por el MIT, el cual me parece muy atingente y que permite caracterizar adecuadamente los diferentes niveles de madurez de las organizaciones en esta área.

El estudio al que nos referimos fue realizado por el Sloan Center for Information Systems Research del MIT en el año 2005, en el cual se pudo tipificar la evolución de las organizaciones respecto del estado de sus arquitecturas tecnológicas empresariales en cuatro niveles de madurez, lo cual se ve reflejado no sólo en las características de su arquitectura sino también en sus prácticas de gestión asociadas. Cabe señalar que los niveles de madurez tienen asociadas buenas y malas prácticas y no nencesariamiente hay que mirarlos con un análisis peyorativo para los primeros, ya que este es un proceso por el que deben transitar todas las organizaciones.

Nivel I: Silos (Departamentales)
Las organizaciones buscan maximizar el aporte a requerimientos y funcionalidades específicas del negocio. Focalizan sus inversiones en tecnologías para resolver problemáticas puntuales y acotadas. No se miran los estándares como un aporte. El rol de las tecnologías (TIC's) es automatizar procesos específicos. Habitualmente las inversiones se justifican en base a reducción de costos. Una buena gestión en esta fase se caracteriza por diseñar procesos de negocio y la tecnología específica requerida para soportarlo.

Nivel II: Estandarización
Las organizaciones buscan mejorar la eficiencia de las TIC's, vía su estandarización y centralización. En esta etapa se mueven arquitecturas basadas en modelo locales a modelos compartidos. Se reduce la cantidad de plataformas diferentes existentes. La definición y administración de estándares corporativos es lo central. Se producen procesos de centralización y consolidación de infraestructura.

Nivel III: Optimización del Nucleo
Se transita a una arquitectura empresarial que da cuenta de procesos y datos estandarizados. Las organizaciones se mueven desde una mirada local de los datos y aplicaciones a un enfoque global (corporativo) y que abarca a toda la organización. El área informática elimina la redundancia de datos y desarrolla aplicativos con un mirada corporativa. Las inversiones en TIC buscan mover la infraestructura con un carácter local y funcional específico a uno global buscando soluciones empresariales. El desafío de gestión informática en esta etapa es construir plataformas reusables que reutilicen los datos y procesos de negocio existentes

Nivel IV: Modularización
En esta etapa se busca modularizar y flexibilizar la etapa la etapa anterior permitiendo un mayor grado de adaptabilidad de la arquitectura con los cambio del negocio.

Los niveles anteriores corresponde a un proceso evolutivo y de madurez normal de las organizaciones y es muy difícil que una organización se salte alguna de estas etapas.

A partir de esa segmentación la misma institución realizó un análisis de la inversión en tecnologías muy sugerente, el cual refleja claramente donde se ponen los acentos



Adicionalmente realiza una análisis de basado en la misma segmentación de madurez del rol que debe jugar el máximo ejecutivo de tecnologías dentro de la organización, cuales deben ser sus competencias y habilidades.

Silos:

• Conocimientos técnicos que permitan tomar decisiones basadas en estándares.
• Habilidad para estructurar proyectos tecnológicos de alcance acotado y local con el uso de metodologías probadas.
• Habilidad para trabajar en equipo con altos directivos de la organización.
• Desarrollar casos de negocios.

Estandarización

• Conocimiento detallado del negocio.
• Administrar proceso de cambio importantes.
• Credibilidad por parte de áreas usuarias y sus directivos.
• Entender la arquitectura como un habilitante del negocio.

Optimización y Madurez

• Capacidad para facilitar la innovación
• Conocimiento detallado del negocio y como las TIC's lo promueven
• Entender y promover los beneficios estratégicos de una arquitectura bien definida

En todas las etapas salvo la primera (Silos) la dependencia del ejecutivo de tecnologías es directa Gerente General, en el caso de la primera etapa su depedencia generalmente es del área de administración y finanzas.

Creo necesario que las organizaciones de todo tipo puedan evaluar donde se encuentra y a partir de allí iniciar un proceso de diseño y/o formalización de su arquitectura.


Me pregunto que ocurrirá en Chile y creo que sin estar muy lejos de equivocarme nuestras empresas y me refiero a las con mejores prácticas se concentran el primer nivel y segundo nivel. Adicionalmente se ve poco que nuestros gerentes de tecnología les preocupe el diseño de una arquitectura empresarial, salvo cuando el mercado o influencias de casas matrices obligan a ello.

En el mundo público, si consideramos al estado como una gran corporación uno podría realizar un análisis similar y el resultado es aún peor que en el caso privado, el comportamiento de Silos está más presente y son muy pocas las iniciativas con una mirada de estandarización y menos aún de optimización del núcleo. Algunos países de la OCDE han visualizado esta situación y se encuentran en un proceso serio de pasar del nivel I a II, buscando fuertemente la estandarización, tal es el caso de Finlandia, Canadá y Dinamarca entre otros.

Es de esperar que luego de una año perdido en el desarrollo de iniciativas de mejoramiento y modernización del estado podamos retomar la senda definiendo un modelo de arquitectura con una mirada corporativa.

¿Gula Tecnológica?

"Nikesh Arora, vicepresidente de Google para Europa predice: Dentro de cinco años un Ipod podría almacenar el contenido emitido por una cadena de televisión durante todo un año. Dentro de diez, toda la música creada por la humanidad a lo largo de la historia; y dentro de solo doce años todo el contenido audiovisual de nuestra especie, incluidas las películas, programas y videos domésticos" (Que Pasa, 1 Diciembre 2006).

Hoy en día estos disposittivos mp3 de 80 gbytes pueden almacenar 20.000 canciones, a un promedio de 3 minutos por canción, se puede almacenar música para 60.000 minutos, el equivalente a 1.000 horas, es decir, más de 41 días (con sus noches incluidas) de música initerrumpida, ¿no será mucho?

Esto me lleva a otra reflexión que tiene más relación con los artículos de esta columna, ¿no estaremos sufriendo de gula tecnológica?, es decir, entendemos muchas veces el soporte tecnológico como compra de tecnología y no como servicios de valor agregado al negocio.

En nuestro país tenemos ejemplos paradigmáticos de como algunas instituciones, tanto públicas como privadas, que privilegian la compra de infraestructura (servidores, discos, software básico, computadores de escritorios y hasta salas de procesamiento) por sobre los servicios.

Recuerdo el caso de una institución pública que luego de gastar varios millones de dólares en infraestructura, finalmente el servicio al ciudadano siguió siendo el mismo (malo y lento!). Para colmo algunos gerentes/directivos muestran ese tipo de gasto como un gran logro de la organización.

Por otra parte son pocas las ocasiones en las que realiza un análisis de la arquitectura tecnológica requerida para un determinado negocio y la adquisición de tecnología se transforma en una lista de supermercado. No son pocos los administradores de tecnología que piensan que renovando la infraestructura tienen la pega hecha, ¿será por que es mucho más facil comprar hardware que desarrollar proyecto TI exitosos?

Todas las instituciones deben pasar por un proceso de diseño arquitectónico detallado que de cuenta de los requerimientos del negocio tanto actuales como futuros y estos los lleve al mapa tecnológico: sistemas, equipamiento y servicios necesarios para soportar el negocio con adecuados niveles de servicio para los clientes o usuarios.

El proceso es una cadena que parte en los requerimientos del negocio, para luego modelar el soporte tecnológico necesario expresado en una arquitectura, para finalmente traducir dicho mapa en una estrategia de implementación compuesta de todos los elementos que plasmarán esa arquitectura en el soporte tecnológico requerido. Revisando este proceso en forma más detallada:


Negocio: Se debe evaluar el estado actual del negocio, su entorno (mercado, comptencia, clientes, proveedores, regulaciones), para luego definir un estado deseado u objetivo. Con estos análisis se debe evaluar la brecha y como cubrirla (mecanismos y procesos).

Arquitectura: Con una visión clara del estado actual y futuro del negocio, esto permite definir los criiterios de diseño de la arquitectura, luego hay que realizar un inventario de todas las componentes de la arquitectura actual (plataforma, sistemas, organización, proyectos), para proceder al modelamiento de la nueva arquitectura tomando como telón de fondo la evaluación del negocio y el estado de desarrollo actual de su soporte tecnológico.

Proyectos: Producto de la nueva arquitectura esto se refleja en una cartera de proyectos, los que deben priorizarse y calendarizarse. Como una activiadad posterior cada una de los proyectos deben definirse en destalles, esto es, sus alcances, objetivos, enfoques metodológicos, WBS, costos y métricas asociadas.

Organización: Como una actividad complementaria se debe evaluar la organización informática, su estructura, roles y las capacidades (competencias) necesarios para abordar la ejecución de los proyectos que instancian la nueva arquitectura.


Factores Críticos de Éxito
Como antecedente complementario me parece relevante tener presentes algunos de los factores críticos de éxito para diseñar un arquitectura tecnológica:

• Claro entendimiento del negocio, donde se encuentra hoy y hacia donde se dirige.
• Cubrir todos los elementos en forma simple y efectiva
  
• La arquitectura debe permitir transformar su diseño en un conjunto acotado de proyectos adecuadamente definido (objetivos, alcances y resultados claros)
• La arquitectura debe contar con un administrador

Principios Rectores
Algunos de los principios que deben regir a una arquitectura son:

• El negocio y su entorno
• Entendimiento de la información y los sistemas como un activo de la organización
• Contar con un modelo de desarrollo de sistema y del ciclo de vida del software
• Uso de estándares comunmente aceptados
• Decisiones de compra deben estar alineadas con la arquitectura en sus diferentes componentes.
• Consolidación de infraestructura (hardware y software) esto permitirá reducir costos y mejorar el servicio
• Capacitación y actualización al personal de informática con las nuevas tecnologías
• Adoptar prácticas de aseguramiento de la calidad y metodologías que permiten su desarrollo (ITIL, ISO, CMM entre otras)

Mientras más se incrusta la tecnología en el corazón del negocio (core business) de una organización más imprescindible se hace contar con un mapeo de la arquitectura tecnológica y su vinculación con los procesos de negocios. Es de esperar que la gula tecnológica no nos atrape sobre todo en período navideños y de fin de año.

Gobierno Electrónico: Una herramienta para transparentar el accionar del Estado

Durante los últimos días hemos visto un conjunto importante de denuncias asociadas a actos de poca transparencia, incluso algunas personas hablan directamente de corrupción, lo que tendrá que analizado en su justo mérito por los tribunales de justicia.

Sin perjuicio de las acciones que se emprendan desde el ámbito administrativo, judicial o político, creo se debe abordar el tema tomando lo ocurrido como un punto de inflexión para volver con fuerza al desarrollo del gobierno electrónico.

En los últimos meses un tema que ha estado totalmente fuera de la agenda gubernamental es este, si se analizan los avances reportados en esta área en los últimos meses son bastante pocos o nulos.

Al mirar al pasado el desarrollo en este ámbito fue bastante fuerte, llegando Chile a estar ranqueado entre los primeros lugares a nivel mundial, lugar 22 para ser preciso, por sobre países como Bélgica o Israel (para más información ver Informe Completo); baste recordar los roles que han tenido diversas instituciones en el desarrollo del gobierno electrónico, Comité de Modernización del Estado, SII, Registro Civil, Chilecompra y PRyME en los últimos años. Pero con una mano en el corazón los últimos meses dejan mucho que desear en este tema y hemos perdido el rumbo y norte de este impulso modernizador.

Si a lo anterior se le suma que no ha existido una institucionalidad clara de impulso de estos temas al interior del estado la situación es más precaria aún, lo que contrasta claramente con anteriores administraciones.

Los gobiernos modernos para desarrollar su quehacer tanto desde el punto de vista de las políticas públicas como de la entrega de sus servicios a los ciudadanos, requieren contar con información confiable y oportuna de las interacciones que esos ciudadanos (sean estos en forma de personas naturales o jurídicas) tienen con el estado, una forma relevante de lograr es desarrollando iniciativas de gobierno electrónico.

El gobierno británico en el año 2005 propuso un proyecto de trasnformación del estado utilizando las TIC's, llamado Transformational Government - Enabled by Technology, en el cual se plantea el potencial de las TIC's en el quehacer del estado apuntando fundamentalmente a las siquientes áreas:

• Ciudadanos e instituciones tienen la posibilidad de personalizar su interacción con el estado.
• Ganancias de eficiencia y mejor uso de los recursos del estado
• Los servidores públicos cuentan con mejores herramientas para desarrollar su función
• Directivos públicos cuentan con mejor información para su proceso de definición de políticas y de toma de decisiones
• Los ciudadanos se sienten más participe de la gestión del estado.

El mismo estudio definió una estrategia de transformación de los servicios públicos utilizando las TIC's sobre la base de tres pilares:

• Los servicios de gobierno electrónico deben estar diseñados entorno a los ciudadanos y las empresas, por lo tanto hay que mejorar la experiencia usuario, reducir la burocracia mejorando la eficiencia del proceso.
• El estado debe moverse hacia una cultura de los servicios compartidos, buscando la estandarización, simplificación y la interoperabilidad.
• Mejorar las prácticas de los profesionales del ámbito tecnológico del estado, incorporando mayores niveles de planificación, ejecución y control de los proyectos (ver debilidades de los proyectos TIC en el estado en este mismo blog).

Me parece que hoy se nos presenta el desafío de retomar el desarrollo del gobierno electrónico como una herramienta poderosa para mejorar aspectos de transparencia, eficiencia y democracia.

Al momento de realizar el diseño de política pública en este tema, me parece que los elementos centrales que se deben tener como telón de fondo son:

• Transparencia: En la medida que se utilizan las TIC como una herramienta de apoyo al quehacer del estado, éstas permiten que la información se transparente, hoy en día no existe ningún tipo de impedimento para que los servicios públicos transparenten su accionar a través de sus portales institucionales.

• Eficiencia: Esto parece de perogrullo, pero en la medida que el estado utilice las TIC's como una herramienta para potenciar sus procesos, éstos serán más eficientes y obtendremos un mejor valor del gasto. Un tema central para lograrlo es tener una mirada de procesos más que de funciones (ver artículo Modernización del Estado - Avanzando hacia el eGobierno en este blog). Por otra parte se requiere contar con una infraestructura tecnológica del estado, en este punto aparecen otros proyectos emblemáticos como una plataforma de interoperabilidad y sistema integrado de protección social, servicios compartidos (ver Interoperabilidad: Siguiente paso al gobierno electrónico en este blog).

• Contacto con ciudadano: El gobierno electrónico permite comprimir el tiempo y el espacio, esto es acercar las autoridades a sus ciudadanos, lo cual sin estas tecnologías sería impensable. Algunos ejemplos incipientes de esto son por ejemplo algunas votaciones para proyectos en municipios (un caso que se me viene a la memoria es la Municipalidad de Providencia). Otros proyecto emblemáticos en esta zona son el escritorio ciudadano (ver www.mi_escritorio.cl: Puente de contacto con el ciudadano en este blog)

Aprovechemos este momento para retomar el camino del desarrollo de un proceso modernizador con un enfoque en gobierno electrónico, que tenemos mucho que ganar y muy poco que perder.

Actualización: Proyectos TIC en el Sector Público

Esfuerzo temporal emprendido para proveer un producto o servicio únicos - Project Management Institute

He actualizado un artículo anterior (agosto del 2005) respecto del desarrollo de proyecto TIC dentro del Sector Público, el documento fue presentado como una ponencia en el Primer Congreso Iberoamericano de Gobierno Electrónico desarrollado en Santiago hace pocos días. En el paper se presentan las principales características y factores de éxito y fracaso de los proyectos de Tecnologías de Información y Comunicaciones en el sector público. El documento es un archivo pdf y se puede bajar desde aquí.