Gestión de la liberación bajo un nuevo signo

Los que me conocen saben que siempre he sido amigo de la gestión de versiones y que siempre lo comparto con los clientes en talleres y jornadas de consultoría. Por desgracia, no me resulta tan fácil convencer de ello a los usuarios en talleres y jornadas de consultoría.

Los contraargumentos habituales son que el departamento no puede esperar a tener los requisitos, sino que debe ponerlos en producción en cuanto estén listos.

Si profundizamos, descubrimos que el departamento especializado pudo esperar mucho tiempo durante la prueba. En definitiva, por desgracia estamos acostumbrados a importar cambios casi a diario en el entorno SAP.

A algunos usuarios de SAP les gusta hablar de "lanzamiento diario" en este contexto. Mientras que en otras aplicaciones estamos acostumbrados a esperar lanzamientos o paquetes de soporte -nadie instalaría funciones individuales en su oficina al azar-, en SAP esto suele ser un pensamiento nuevo para los usuarios y los departamentos de TI.

Esto ha llevado a que la "Corrección Normal" no sea utilizada por la mayoría de los clientes, ya que la "Corrección Urgente" es más práctica. No es necesario planificar las versiones, pero siempre se pueden poner en producción los cambios individuales, si el departamento lo desea.

Por supuesto, la transición del desarrollo continuo a una publicación no se produce de inmediato y con sólo pulsar un botón. Los cambios organizativos necesarios suelen ser mucho más profundos.

Hasta ahora, la gestión de versiones también había sido siempre muy rígida. Siempre me preguntaban qué pasaría si, durante la implantación, se decidía que determinados requisitos no debían ponerse en marcha o se posponían a la siguiente versión.

SAP ha reaccionado ante todos estos problemas. Mientras que antes había diferentes proyectos de Solution Manager a los que se asignaban cambios individuales, en 7.2 hay una verdadera liberación.

En el pasado, cada cambio que se solicitaba y aprobaba a través de un flujo de trabajo debía asignarse a un proyecto antes de su publicación. Pobre de aquel que asignara incorrectamente un cambio a un proyecto.

Cuando el cambio ya estaba en desarrollo, sólo podía rectificarse con un gran esfuerzo manual. En algunos casos, los clientes también utilizaban complementos para transferir el cambio a otro proyecto.

Afortunadamente, la formación de release tiene lugar cuando estamos hablando de un go-live real. Esto no es del todo conforme a lo que conocemos en el entorno no SAP. Pero probablemente sea una de las formas de convencer a los usuarios de la gestión de versiones en SolMan. Sigue siendo necesario un cambio organizativo.

El departamento de TI tiene que hablar con los departamentos empresariales, crear un plan de publicación y acordar una distinción real entre requisitos urgentes y cambios que deben incluirse en una publicación.

Una y otra vez tengo clientes que huyen precisamente de este conflicto y empiezan a agrupar los proyectos como una versión. Todo lo que no es un proyecto, es decir, lo que no supera una determinada cantidad de trabajo, se trata como un "cambio urgente".

A primera vista, esto parece sencillo. Sin embargo, si se tiene en cuenta el trasfondo del control del transporte, la situación es mucho más complicada.

Dado que los "cambios urgentes" también deben asignarse siempre a un proyecto, se importan de nuevo al ponerse en marcha para garantizar la sincronización. Esto significa, sin embargo, que los clientes que ejecutan varios proyectos en paralelo deben asignar siempre todos los "cambios urgentes" al siguiente proyecto que se ponga en marcha.

En la práctica, esto es más que complicado. El gestor de cambios se queda con cara de caniche ahogado cuando dos proyectos juegan al enroque con poca antelación. Entonces hay que reasignar los cambios, lo que no es posible en la versión 7.1 con sólo pulsar un botón.

Con SolMan 7.2, el cliente ahora puede desarrollar completamente de forma "urgente" y poner siempre todo en producción, o puede hacer un lanzamiento real en el momento de la puesta en marcha.

En definitiva, se trata de una ampliación real e increíblemente valiosa. El reto para los responsables de TI consiste ahora en afianzar la mentalidad de lanzamiento en el contexto de SAP en sus propias empresas.