Desafíos en el diseño de los proyectos TI
Es común ver en el diseño y contratación de proyectos tecnológicos un ítem muy significativo asociado a la infraestructura TI básica, me refiero a hardware, comunicaciones y software básico (sistemas operativos, bases de datos, middleware, lenguajes de programación y frameworks de desarrollo entre otros). Pero por otro lado, se ve poco en materias de los servicios de valor agregado y la ingeniería requerida por sobre esa infraestructura base, para lograr los productos y servicios finales del proyecto.
Recuerdo un caso, de una gran institución pública, voy a omitir su nombre por razones obvias, la cual después de gastarse literalmente varios millones de dólares, en infraestructura tecnológica básica (servidores, software base, comunicaciones y otros), sus servicios desde el punto de vista de sus usuarios finales, no mejoraron en nada. Durante años tenían la suite completa de productos de software, en su última versión, de una gran marca de software base, con el obvio pago de las licencias anuales, que como comprenderán no se trataba de montos menores, los cuales no se llegaron a utilizar del todo por que las aplicaciones que debían correr en ese ambiente tardaron mucho más tiempo en estar listas.
Incluso su directivo de informática en una presentación a todo el equipo directivo de la institución dijo:
“ahora, tenemos un portaaviones de última generación, en materias de infraestructura”
Pero el problema es que a ese portaaviones, le faltaba prácticamente de todo: tripulación, aviones, pilotos, mecánicos, combustible, procedimientos, alimentación y muchos otros.
Casos como estos, no son aislados, en los cuales la parte de la infraestructura queda instalada, hoy en día es la parte más fácil del problema; pero finalmente los servicios a los ciudadanos no cambian mayormente, en términos de su calidad, nivel de servicio y tiempos de respuesta.
A futuro los proyectos tecnológicos deberán hacer un esfuerzo importante en materias de su diseño y de cómo se concentran en lo sustantivo y no en la infraestructura TI básica para soportarlo, la cual a estas alturas se ha transformado en productos y servicios bastante comoditizados.
Adicionalmente, en adelante se vienen cambios importantes en materias de diseño y ejecución de proyectos TI y esto debido fundamentalmente a nuevas características que los van a impacta, analicemos algunos de ellos:
- En primer lugar el nuevo paradigma de la contratación tecnológica, en la modalidad de servicios, esto es, infraestructura, plataforma y aplicaciones como servicios (IaaS, PaaS y SaaS)
- Por otra parte, nuevos métodos de desarrollo e implementación basado en técnicas ágiles, en sus distintos sabores.
Desde que el cloud ha irrumpido en diversas área de la provisión de tecnologías, esto es, desde la infraestructura base hasta las aplicaciones, ha llevado a poner la presión en el diseño de los proyectos en otras áreas, esto es:
- identificar los niveles de servicio requeridos;
- especificación de requerimientos en modalidades más flexibles y de más alto nivel;
- modelo contractual y sus cláusulas asociados a servicios más que a productos;
- propiedad y gestión de la data y finalmente;
- confidencialidad y acceso a la data
Estos esfuerzos no son sólo desde el punto de vista de los documentos necesarios para salir a contratarlos al mercado sino también, al momento de su posterior gestión cotidiana.
Por otra parte, nuevos paradigmas en los procesos de diseño y puesta en marcha de aplicaciones de negocios, como se mencionaba; las cuales han comenzado a adoptar métodos de diseño y desarrollo del tipo ágil, en sus diferentes sabores, los que, como ya lo he expresado anteriormente requiere de nuevas formas de aproximación.
El énfasis de muchos de los proyectos tecnológicos futuros, deberán estar en la problemática del negocio y no en los aspectos de las tecnologías. Ello pone presión para que la mirada de los tomadores de decisiones en esta área, se centre en los requerimientos funcionales, perfil de los usuarios (grupo etario, nivel de uso de tecnologías, movilidad), niveles de servicio requerido de los servicios, modelos contractuales y niveles de externalización necesarios, así como los modelos de soporte posterior.
El peor escenario es seguir desarrollado proyecto para estos nuevos escenarios, utilizando modelos que utilizan la lógica on-premises y métodos de diseño en cascada. Parece algo obvio lo que estoy planteando, pero ya me ha tocado ver proyectos diseñados en esa lógica, y lo que termina resultando en un jira-mono-canguro
Imagen: http://cazasyhelicopteros2.blogspot.cl/2014/08/portaaviones-ins-vikramaditya-de-la.html
Excelente reflexión Alejandro. es demasiado amplia la historia de proyectos no exitosos, y en el mejor caso, exitosos desde la lógica del proyecto pero no de los resultados esperables hacia el destinatario final, como para no aprender, lujo que no debiéramos permitirnos. Coincido en que la metodología de desarrollo debe aggiornarse a nuevas dinámicas de colaboración y agilidad (y rescato aquello de los «proyectos delfines» que sigue muy vigente), pero igualmente creo que hay debilidades clave:
– la mayoría de los proyectos se dispara sin un análisis previo de los problemas-objetivos, por lo que la contribución a la mejora puede no ser sustantiva, además de que se diluye el propósito del proyecto (visión estratégica y del «negocio»).
– no siempre se considera la gestión del cambio desde el punto de vista humano y los proyectos se limitan a los aspectos tecnológicos, que de por sí no solucionan y que incluso pueden desaprovecharse totalmente.
– los proyectos se cierran (con suerte se realiza cierre), sin considerar la sostenibilidad de los cambios que se procuraron y menos aún la evalución/evolución, cuestiones con menos impacto de marketing, pero que definen que lo invertido tenga sentido.
– esto ya es casi un detalle, pero la gestión de la información con visión institucional es aún muy incipiente y más aún con visión transversal al Estado, cuando debería ser considerada en en cada iniciativa..
Como siempre ha sido un gusto leer tu publicación, siempre con aportes muy valiosos.
Muchas gracias Gabriela por tu comentario, comparto lo que planteas como temas y que efectivamente tienen un alto impacto en el desempeño final de los proyectos.
Muchas gracias
Plenamente de acuerdo, como proveedor de aplicativos y servicios he visto demasiadas veces la situación de describes en distinto tipo de instituciones; mi impresión es que hay una concepción de "valor" equivocado: se le da más valor a la plataforma base y poco valor a las aplicaciones de negocio y los servicios anexos (mantención, administración), basta ver muchas bases en las cuales los requerimientos son del estilo "quiero un sistema que haga X" donde el problema a resolver no tiene una clara definición o está expresado en forma técnica y no del objetivo de negocio que se quiere lograr. La preparación de bases es una de las debilidades del mecanismo de compras públicas, no se trabaja el diseño global de la solución; si bien ahora los convenios marcos incluyen la idea de un anteproyecto todavía esa modalidad de trabajo no está asimilada. Por otro lado en esas mismas bases (o relacionadas) la plataforma está detallada al "chip", es cierto que es más simple, pero si no hay claridad de lo que va en esa plataforma resulta fácil caer en sub o sobre dimensionamiento de la plataforma (caso tambien frecuente). Basta ver la relación de presupuestos entre plataforma y aplicativos, si en USA se habla de 1:3 acá con suerte llegamos a 1:1 y muchas veces es N:1 (mayor inversión en plataforma). Las modalidades de servicios en la nube permiten mucho mayor flexibilidad en la plataforma pero si no se le da valor a los aplicativos y servicios vamos a obtener los mismos malos resultados.