4. La duración de la migración

Cuando una organización inicia un proyecto así, debe hacer una valoración del tiempo aproximado que le va a llevar. Según indica Beobide: “En el cambio de versión de 4.6 a 6.0 el tiempo de migración estimado es de una semana, pero con dos fines de semana incluidos, en realidad son nueve o diez días”. Sin embargo, no es fácil determinar este factor y muchas veces depende de lo claros que tengan sus objetivos las entidades en cuestión para que la iniciativa no se alargue hasta el infinito. Soler lo tiene claro: “Es muy importante no mirarte el ombligo y recurrir a la experiencia de otras instituciones que ya han finalizado el proceso. El intercambio de información es fundamental, al igual que lo es que tu objetivo sea conciso para que los tiempos no se disparen. Aquí la posición del partner es un punto clave, ya que si este intenta venderte más y más soluciones y tú no sabes decir que no, tu presupuesto se disparará, se dispersará el equipo encargado de hacer la migración y todo será un fracaso”.

El representante de la Comunidad de Castilla y León explicó su planning de actuación: “Hemos hablado de 10-12 meses. El problema de los tiempos es que SAP ha pasado de ser un mundo, a ser un universo. Cada vez hay más módulos y depende de los que implantes. En las organizaciones que quieran implantar Económico-Financiero, RRHH… la migración podría durar bastantes más meses. Muchas veces los propios partners, en sus ofertas, te sugieren mejoras y es difícil decir que no. Vamos a tener que desarrollar procesos de arrastre de plurianuales y esto es también migración, aunque no se implante a la vez que el resto de los módulos, lo que aumenta algo los tiempos de migración. Además la actualización también supone un proceso de estabilización que es necesario tener en cuenta”.

Como experta en la puesta en marcha de este tipo de proyectos, la gerente de Ibermática afirma: “El caso de Castilla y León es complejo. Es una iniciativa que cuenta con una dotación económica importante, es de gran envergadura y muy crítica. Por este motivo, lo primero que hemos hecho ha sido analizar los factores críticos para la organización, de manera, que los que no lo sean, no estén introducidos en la migración y no hagan tambalear el éxito del proyecto”.

Calcular los tiempos no es sencillo, así lo demuestra la experiencia del representante de Murcia: “Nosotros también tuvimos que hacer pequeños desarrollos para poder migrar. Sacamos el concurso diseñado con la participación de SAP dos años antes, tardamos en adjudicarlo algo más y desde que nos pusimos a trabajar a fondo pasaron unos 18 meses. A pesar del liderazgo, nos dijeron que si no podíamos migrar en agosto, tendríamos que hacerlo en febrero, lo que hubiera retrasado nuestros propósitos seis meses. Menos mal que nuestros objetivos estaban muy claros y eso no ocurrió”. Aún así, tal y como señala Escudero: “La clave es poder trabajar en paralelo, con dos sistemas distintos. Nosotros no paramos el sistema viejo, de hecho lo tuvimos activo muchos meses después, aunque no de cara a la explotación del usuario. Llegamos a montar un sistema de almacenamiento paralelo para poder hacer las cargas. Y tuvimos que decidir un día en el que hacer el cambio del sistema viejo al nuevo. Es una inversión importante en sistemas paralelos, pero compensa el riesgo de perder el servicio”.

Aunque esta es una opción, otras organizaciones prefieren programar muy bien los días de parada y hacer un plan B por si se produce algún retraso. Es el caso de Castilla y León y de la Universidad Complutense: “Hay servicios que no pueden parar, por lo que mantener el servicio se convierte en un requisito imprescindible. Los diez días que vamos a parar, están programados y en principio, no habrá ningún problema”, afirmó Rodríguez Villanueva. Por su parte, Soler aseguró: “Si al hacer la migración, tuviéramos que parar fuera del periodo acordado, supondría un problema, ya que no se podrían gestionar debidamente las incidencias generadas. Aunque pararas una hora, no se contabiliza como una hora, sino como una hora multiplicada por el número de usuarios que tengas y así podrían salir unas 300. Tienes que hacer un cuadrante muy específico y ver el día o los días en los que puedes parar sin generar un problema importante en los procesos funcionales de la Universidad”.