Elementos a considerar para la formulación del portafolio de proyectos para la sustitución de sistemas y plataformas

Elementos a considerar para la formulación del portafolio de proyectos para la sustitución de sistemas y plataformas

En anteriores artículos de este Blog, he hecho referencia a los procesos relativos a ser considerados para el cambio de sistemas y plataformas tecnológicas. He comentado que no solo con sustentarlas en cifras como ROI, VAN o TIR, respaldan un cambio, sino del análisis que nos permita determinar los niveles actuales de exposición a riesgos que pudiesen ocasionar pérdidas materiales y significativas en la organización como errores de inventarios o descontrol en la cobranza, así como a pérdidas no económicas pero de alto impacto como daños reputacionales, descertificación de nuestros procesos o de nuestros productos por parte de nuestros clientes o proveedores.

Una vez evaluados y consideradas todas los argumentos y cifras que soporten la necesidad del cambio, y la misma es evaluada y aprobada por la Dirección General, da inicio la etapa más importante de todo el proceso, lo cual lo constituye la evaluación de los subproyectos que deberán conformarse para poder definir adecuadamente el reemplazo del ERP o la plataforma actual. En este sentido debemos ser igualmente responsables ante la Dirección en la metodología que utilizaremos para evaluar los posibles subproyectos que se deberán acometer para el logro del proyecto final.  

Como consultores gerenciales hemos visto como muchos proyectos de IT se incrementan sobremanera al presupuesto inicial por errores en la estimación de las adecuaciones y mejoras no planificadas y por lo tanto no presupuestadas y que en muchos casos han obligado o a la reducción de los alcances iniciales o a la desestimación de la inversión ante la imposibilidad de acometerla satisfactoriamente. Es justamente en esta fase donde hemos visto los mayores desaciertos y fracasos de los proyectos, porque la Gerencia y la Dirección desconocían el real impacto de inversión de tiempo y recursos que el proyecto requeriría. Este tipo de indefiniciones deja muy mal parada la capacidad de la gerencia de IT como planificador. Un cambio de un aplicativo de gestión empresarial o de una plataforma tecnológica, en la mayoría de los casos requerirá posiblemente de una cantidad de adecuaciones, mejoras y cambios de otras plataformas que deberán ser asociados al proyecto principal. Es por esta razón que debe conformarse un portafolio de proyectos que los agrupe a todos estos, esto quiere decir que no es solo un proyecto, sino múltiples proyectos con presupuestos y tiempos de acometida diferente.

En este sentido recomiendo definir no más de tres alternativas viables, cada alternativa conformará un portafolio de proyectos, cada portafolio tendrá asociado una serie de proyectos que pueden incluso ser comunes entre ellos, por ejemplo para el portafolio A requerirá un cambio de servidores pero el portafolio B solo una actualización y repotenciación de estos, sin embargo para ambos portafolios se requerirá actualizar las licencias de uso de las BD.

Uno de los más recientes e interesantes casos fue asistiendo a la Gerencia de IT de una importante institución de salud en la evaluación de un aplicativo de Gestión Médica Administrativa. Para este proyecto se desarrollo una herramienta multidimensional que permitía relacionar e integrar diferentes elementos de evaluación de priorización y criticidad de los portafolios versus procesos de negocio versus objetivos estratégicos.

En primer lugar se creó una tabla con los objetivos estratégicos de la institución y los objetivos tácticos de la gerencia de IT. La tabla más importante fue la matriz multifuncional de procesos conformados por unos 180 procesos médico administrativos, cada proceso se le definieron parámetros funcionales como criticidad, impacto, tipo de riesgo, y valor institucional ya que para la organización un área como Consulta Externa podía no ser tan prioritaria como Emergencia o Quirófano, adicionalmente se definieron parámetros estratégicos, donde cada proceso fue indexado a un objetivo  estratégico de la organización así como a un objetivo táctico de la gerencia de IT. Esta indexación fue crucial porque le permitió a la Dirección General poder relacionar que los objetivos por ellos definidos se estarían cubriendo adecuadamente. Para culminar se definieron parámetros operacionales donde por cada proceso se le relacionaba a los proyectos que debería acometerse para su logro todo dentro de los portafolios de proyectos definidos.

Esta matriz sirvió igualmente de base para la creación de un requerimiento de propuesta o RFP que se le envió a cada uno de los proveedores seleccionados con la finalidad que cada uno indicase si el proceso era cubierto por la aplicación que ellos representaban, adicionalmente a información de requerimientos técnicos y costos asociados a licenciamientos, consultoría de implementación y puesta en marcha  del aplicativo.

En este sentido la matriz de portafolio de proyecto  se definió y relacionaron dos portafolios de proyectos, uno el principal constituido por el cambio total de la plataforma de gestión, y un portafolio secundario constituido por la adecuación y mejora de la actual plataforma de gestión. Este aspecto fue muy interesante ya que se determino que era factible el cambio y reprogramación del sistema actual. En este sentido se definieron los diferentes subproyectos que deberían acometerse para cubrir adecuadamente ambos portafolios de proyectos, por ejemplo adecuaciones y cambios de servidores, cambio de la plataforma de comunicaciones, cambio de la plataforma de respaldos, determinándose un total de 14 proyectos.

Cargadas todas las tablas y realizadas todas las indexaciones pertinentes comenzó la etapa más interesante del proyecto que fue el análisis de la información. Los resultados fueron realmente interesantes permitiéndole a la Gerencia de IT tener una direccionalidad y claridad en la inversión, prioridad y criticidad en la forma que deberían ser desarrollados los proyectos.

El análisis de los resultados por cada portafolio de proyecto indico que lo que se había considerado como proyecto principal quedo ubicado entre el cuarto lugar de la prioridad, y que antes deberían ser ejecutados mejoras en los sistemas de redes, servidores y comunicaciones antes de poder pensar en el cambio o adecuación del ERP que fue realmente el motivo inicial del proyecto.

Era probable que la Gerencia de IT sin haber hecho este análisis detallado hubiese podido inferir la necesidad del cambio de los servidores o de la comunicación, pero de una forma intuitiva, subjetiva, más por experiencia que por objetividad y análisis detallado de la situación.

Los resultados, presentados ante la Directiva fueron aceptados y aprobados y en primera instancia el desarrollo y ejecución de los proyectos críticos y prioritarios de acuerdo a lo indicado como proyectos prioritarios a ser ejecutados para el reemplazo del sistema e Gestión Médico Administrativa.

Posteriormente la Gerencia de IT deberá dar inicio a la evaluación funcional y económica de cada proyecto, selección de proveedores, estimación de inversiones, de costos directos e indirectos relacionados a cada proyecto y a cada proveedor.