La falta de aplicación de criterios técnicos en el plan de migración, tanto en gestión de procesos (BABOK, 6 Sigma) como en dirección de proyectos (PMBOK, Scrum), sumado con la ausencia de una autoridad central a nivel del estado que guíe estos procesos de migración, pone en grave riesgo la consecución exitosa de los proyectos de migración a software libre en las instituciones del Estado ecuatoriano, así como la sustentabilidad de los resultados logrados a mediano y largo plazo. Es necesario alinear las iniciativas de migración con los objetivos estratégicos del estado y sus instituciones, expresadas en el plan de gobierno electrónico, el cual por cierto debería ser la guía para estas migraciones, al ser el software libre una política de Estado. Cabe señalar que una migración solo tiene sentido si se esperan obtener una mejora en los indicadores de gestión de la institución, a un nivel que justifique el esfuerzo.

Luego de una revisión a profundidad del plan de migración publicado en la página web del Ministerio Coordinador de Conocimiento y Talento Humano (una copia se la puede obtener aquí), se puede observar el gran esfuerzo realizado por los colaboradores involucrados en la redacción de este documento.

Existen elementos muy valiosos como por ejemplo el marco normativo necesario para sustentar el plan de migración, así como un análisis FODA y análisis de impacto social y político el cual ayuda para argumentar la pertinencia de realizar la migración en una institución pública.

En este artículo se presentan observaciones que pretenden complementar este plan de migración, con el fin de lograr resultados efectivos que sean perdurables en el tiempo. Un objetivo adicional es alinear el plan de proyecto hacia las recomendaciones que ofrece el PMBOK, que contiene las mejores prácticas en dirección profesional de proyectos, generado por el Instituto de Dirección de Proyectos (PMI por sus siglas en inglés).

Mezclando conceptos

El documento en análisis presenta 8 secciones:

1. Introducción,
2. Contextualización,
3. Análisis de impacto,
4. Plan de migración,
5. Seguimiento, evaluación y control,
6. Recomendaciones y Conclusiones,
7. Anexo, y
8. Bibliografía.

Todo esto mezcla conceptos de estudios de factibilidad con la gestión de proyectos propiamente dicha, ya que la contextualización busca justificar la organización del proyecto sin justificar previamente que es la mejor solución hacia el problema que se quiere responder, lo cual se logra con un análisis de prefactibilidad. De igual manera, el análisis de impacto debe ser realizado previo a la realización del plan de proyecto, ya que es un factor a ser considerado para la toma de decisión por parte de las autoridades si el proyecto se ejecutará o no.

Sobre prefactibilidad y factibilidad

Para explicarlo simple:

• En la prefactibilidad se define con detalle el problema que se desea resolver y el contexto bajo el cual existe.
• Una vez identificado el problema, se listan varias alternativas de solución en donde se estima el esfuerzo necesario para ser ejecutada y el impacto que tendrá sobre los interesados clave.
• Con esta información, las alternativas son comparadas y finalmente se escoge a la mejor, la cual es analizada con mayor detalle para identificar su factibilidad de ejecución en varios aspectos como como son el económico, social, técnico, entre otros.
• Si se identifica la factibilidad de realizar la alternativa, se da luz verde a la realización del plan del proyecto, caso contrario se escoge la siguiente mejor alternativa y se realiza su respectivo análisis de factibilidad hasta identificar una posible solución ejecutable en la realidad.
• Algunas veces, la obtención del alcance es tan complejo que se contrata una consultoría para su sola elaboración.

De esta manera se consigue justificar un proyecto de manera técnica, habiendo analizado todas las posibles alternativas existentes y escogiendo la mejor de estas. Sin embargo, el documento de plan de migración presupone que la solución a ser implementada es la mejor alternativa existente, y trata de argumentar esta decisión con la normativa vigente, sin haber hecho el análisis anteriormente explicado. Cabe señalar que la prefactibilidad y factibilidad es un procedimiento seguido por la secretaría Nacional de planificación y desarrollo SENPLADES, es decir que se lo realiza antes de la planeación de cualquier proyecto de inversión del Estado ecuatoriano.

Plan de migración sin planeación

Las dos secciones siguientes son el Plan de Migración y el Seguimiento, Evaluación y Control, que tratan de marcar una ruta a seguir para la ejecución efectiva de la migración a software libre.

Sobre la sección «Plan de Migración»

Aquí se divide el trabajo en cuatro fases, que son:

1. Recolección,
2. Concientización y capacitación,
3. Análisis y diseño de propuesta técnica, y
4. Implantación.

El supuesto es que el alcance del proyecto es definido en su totalidad en la primera fase de recolección, en donde simplemente se realiza un inventario de software y hardware existente en la institución. Esto constituye un grave riesgo, ya que no se toma en cuenta la importancia de comprender los procesos de la institución a fin de implantar las mejores herramientas tecnológicas que permitan apoyar de la mejor manera el trabajo de la institución. Esta comprensión se logra con el levantamiento del manual de procesos de la institución, lo cual no es (o no debe ser) una tarea de la Dirección de Tecnologías sino de la Dirección de Procesos, cuyo trabajo está íntimamente relacionado con los proyectos tecnológicos.

El manual de procesos es un insumo previo indispensable para la permanencia en el tiempo de la solución lograda, ya que sólo a través de la comprensión de los procesos de una institución y el orquestamiento de los mismos es posible otorgar soluciones tecnológicas que no solo apoyen a dichos procesos sino que permita su mejora continua y en muchos casos su disrupción hacia nuevos niveles de calidad.

El solo reemplazo del software privativo por software libre, sin sustento del análisis del negocio de la institución, compromete la permanencia en el tiempo de los resultados alcanzados, dejando bajo el criterio de las autoridades del momento el regreso hacia tecnologías privativas, lo cual en cierta medida es entendible por la falta de criterio técnico que explique de forma clara la razón de haber elegido esa alternativa tecnológica, y su impacto real que tiene en la mejora de los procesos institucionales, alineado hacia el logro de los objetivos estratégicos. Por lo antes dicho, previo a la recolección debe ser realizado un estudio de los procesos en los que el software va a ser utilizado.

Definiendo un plan adecuado

Suponiendo que ya existe manual de procesos y que están optimizados, el proyecto debe empezar por un análisis de interesados, donde se los identifique, priorice y se definan mecanismos de comunicación. Este análisis permite la gestión de los «influenciadores» dentro del grupo de trabajo, que en algunos casos no corresponden con la autoridad jerárquica, como por ejemplo personas carismáticas cuya opinión es una guía para el resto del grupo. Su gestión adecuada, lo cual incluye la comprensión de sus motivaciones y deseos, ayuda a que la implantación del proyecto se la realice con el mínimo posible de resistencia al cambio.

Una vez elaborado el plan de comunicación con los interesados, es necesario levantar la definición del alcance del proyecto, lo que permitirá entender el trabajo necesario que se necesita realizar y también servirá como insumo a dos elementos importantísimos para la gestión, como son el cronograma y el plan de riesgos.

Sobre el primero, se pueden ver dos cronogramas en el documento de plan de migración,  siendo uno el tentativo y otro el de fecha reales. La sola presencia de ambos cronogramas deja marcada la falta de una técnica adecuada en la gestión, ya que sólo puede existir un cronograma con las fechas estimadas como la línea base inicial y las fechas reales como los ajustes realizados sobre esa línea base. El cronograma expuesto carece de criterios básicos de gestión, por ejemplo no incluye todo el trabajo señalado en el mismo documento como es la recolección y el análisis de laboratorio; carece de tareas vinculadas, responsables de las tareas, desagregación de tareas muy extensas con más de cinco días, entre otros muchos factores necesarios en un cronograma adecuado para la correcta gestión de un proyecto.

Sobre el plan de riesgos, no existe en el documento. Se debieron haber realizado los siguientes pasos:

1. Identificación de los riesgos, con sus causas y consecuencias.
2. Priorización de riesgos a través de su exposición, que se obtiene con la multiplicación de la probabilidad de ocurrencia por el índice de impacto estimado.
3. Medidas de mitigación, revisando las causas.
4. Planes de contingencia, atendiendo las consecuencias.

Sobre la sección «Seguimiento, Evaluación y Control»

Esta sección presenta un contenido que no se alinea con ese título. Tratándose de un plan de proyecto lo que se esperaría encontrar son indicadores de avance del proyecto y formas de medir la efectividad de los resultados obtenidos luego del fin del proyecto. En su lugar se encuentra más justificaciones para la ejecución de la migración, e ideas y propuestas para su permanencia en el tiempo mediante convenios y exhortaciones de voluntad.

Un indicador importante para justificar la pertinencia de la migración serían los indicadores de gestión obtenidos mediante la definición de los procesos institucionales, los cuales al menos deberían permanecer iguales antes y después de la migración, sin embargo la mejora de tales indicadores de gestión, junto con la reducción de gastos relacionados por licencias de software privativo, evidenciaría sin lugar a dudas que la migración fue una decisión acertada, independiente de criterios subjetivos y prejuicios.