Hay que tener en cuenta que al principio SAP dirigía sus soluciones principalmente a la empresa privada, de manera que muchas entidades públicas encontraban escollos para implantar SAP y cumplir al mismo tiempo requerimientos legales, normativos… Pero esta situación es ahora diferente, tal y como ha afirmado Begoña Navarro, gerente de Sector Público de Ibermática: “Cuando las CCAA empezaron a trabajar con SAP, éste no cumplía todas sus necesidades legales. Por este motivo, se formó un grupo de usuarios del sector público (GUSP). Este grupo se reúne periódicamente y pide que SAP incorpore al estándar, requerimientos que para ellos son fundamentales. Así se creó el mapa de requerimientos y SAP lo que está haciendo es incorporando poco a poco esa lista de requerimientos al estándar. Sin embargo, si te quedas en la versión anterior y no migras a la 6.0, SAP no te va a cubrir todos esos requerimientos. De ahí la importancia del cambio”.

2- Los factores determinantes

Una vez tomada la decisión de migrar a la nueva versión, se deben tener en cuenta algunos factores que harán que el proceso sea un éxito. De estos puntos clave habló Manolo Fernández Beobide, consultor estratégico del Centro de Migración de Ibermática: “Es muy importante enfocar una migración, minimizando el impacto en el usuario final, dimensionarla tratando de respetar los plazos y garantizar la fiabilidad, diseñando un plan de contingencia capaz de hacer frente a posibles fallos. Importante es también transmitir el conocimiento al usuario, que conozca bien las posibilidades del nuevo sistema para enfocar la migración actual y las del futuro. Finalmente, se deben reducir al mínimo los desarrollos durante el proceso, hacerlo en un momento en el que hay desarrollos pendientes de implantar es peligroso porque las pruebas de la migración pueden ser engañosas. Hay que procurar que los sistemas estén estables en cuanto a funcionalidad en el momento de hacer el cambio de versión”.

El representante de la Complutense y el de la región de Murcia están de acuerdo con esta idea: “En tanto en cuanto se inicie el proceso de migración se acabaron los desarrollos porque si en el sistema base están cambiando funcionalidades, las pruebas no son fiables. El mantenimiento correctivo también hay que llevarlo al mínimo porque a veces lleva a adaptativos y éstos a reprogramar todo lo que se ha estado haciendo”, afirmó Soler. Por su parte, Manuel Escudero aseguró: “Hay que limitar el proyecto y no salirse de ahí porque si no tienes claro tu objetivo, al final fracasas. El responsable tiene que tener capacidad para decidir, por muy urgente que parezca, los cambios que se harán una vez hecho el paso a la nueva versión, porque si estás haciendo pruebas, cualquier modificación que introduzcas, te puede transformar el estado de la migración y al final estropearse todo”.

Aunque es fundamental reducir el número de desarrollos a la mínima expresión durante un proceso de migración, todos los presentes coincidieron en que un cambio de actualización, supone en la mayoría de los casos, un cambio de plataforma. “El paso a la versión 6.0 obliga a tener sistemas nuevos y si esta transformación no se ha hecho antes de forma independiente, hay que llevarla a cabo durante la migración. Ibermática en la Junta de Castilla y León cambiará las máquinas de 32 a 64 bits y pasará a Linux uno o dos meses antes de realizar la actualización, así todo será más sencillo. El hecho es que el cambio de plataforma va ligado a la migración”, manifiesta Beobide.

Manuel Escudero explicaba entonces su experiencia en la región de Murcia: “Nosotros en un principio trabajábamos con servidores sobre HP-UX, pero para una mayor escalabilidad del sistema migramos (antes de comenzar la migración funcional) a pequeños servidores (blades de HP) de 32 bits con Red Enterprise Linux 4 Update 3”.

En la Universidad Complutense el proceso se ha planteado en dos fases, según ha indicado Oscar Alejandro Soler: “Primero vamos a migrar la plataforma, es decir, instalaremos máquinas nuevas con sus correspondientes sistemas operativos. Esto lo haremos en unos meses y luego pasaremos a la versión 6.0”.

Otro de los puntos que se deben tener en cuenta es el momento en el que se lleva a cabo la migración, más aún si la organización es una entidad pública. Así lo ha explicado Gonzalo Rodríguez: “Buscar el momento del cambio es complicado, ya que en las AAPP existen condicionantes de tipo político, económico y presupuestario. Antes la migración traía consigo un corte de cuatro o cinco días, pero ahora son diez y hay cuestiones que no pueden dejar de funcionar como el pago de la nómina o la elaboración del presupuesto, entre otras cosas. Esta decisión debe ser estudiada a fondo por el equipo encargado de gestionar la migración, si no puede haber problemas”.

Problemático puede resultar el cambio si no se cuenta con el usuario final, es decir, con el personal que tiene que utilizar la nueva versión, ya que la migración supone, según Escudero, “un cambio cultural”. Aún así, si se hace bien, no tiene por qué haber dificultades, tal y como ha afirmado el representante de la Universidad Complutense de Madrid: “Salvando la primera resistencia al cambio que la hay en cualquier organización, sea pública o privada, una vez que los usuarios se acostumbran a esa dinámica, lo aceptan bien. Nosotros no hemos dejado de incorporar módulos nuevos desde el arranque en el 2.003 y nuestro personal recibe formación casi de manera constante. Llega un momento en que cuando se habitúan, quieren más mejoras y sacan todo adelante. Hay que aprovechar esa inercia. El problema es cuando pasa mucho tiempo y no hay cambios porque la gente se habitúa a la inactividad. Por esto creo que nuestros usuarios no van a notar mucho la migración cuando la llevemos a cabo, solo notarán las mejoras que introduzcamos”.