¿A toda velocidad hacia el futuro o atascado en el apartadero?

El inicio de un proyecto para convertir la antigua y estable SolMan 7.1 a la nueva versión 7.2 presenta obstáculos en las empresas.

Resulta difícil argumentar por qué debe emplearse un presupuesto elevado para sustituir un sistema estable del que aún se tiene poca o ninguna experiencia sobre el terreno.

No para todas las empresas las mejoras de 7.2 son motivo suficiente para implementar una actualización en esta dimensión. Un argumento importante para que Life Science implante SolMan 7.2 es la necesidad de cumplir los requisitos normativos.

Si se producen errores durante el funcionamiento de la versión 7.1 una vez finalizado el mantenimiento, las interfaces o los complementos dejan de mantenerse o los sistemas conectados dejan de ser compatibles, ya no se garantiza el funcionamiento conforme a GxP.

La conversión de los sistemas conectados a S/4 Hana que ha comenzado también puede utilizarse como argumento adicional. SAP no garantiza un funcionamiento sin problemas entre SolMan 7.1 y los sistemas que se ejecutan en S/4 Hana.

¿Campo verde o marrón?

Una vez superado el primer obstáculo, se plantea la cuestión de la estrategia. Para ello existen dos opciones. La primera alternativa (denominada greenfield) se basa en un sistema recién creado, en el que todos los procesos, tablas y datos maestros se importan de nuevo.

El sistema heredado debe cerrarse y archivarse según lo previsto. La segunda alternativa (denominada "brownfield") también contempla la creación del sistema de nuevo. Sin embargo, aquí la atención se centra en continuar la historia del sistema y no en dividirla entre dos sistemas (nuevo y antiguo).

En este caso, la migración inicial supone un gran esfuerzo. Ambas alternativas tienen sus ventajas e inconvenientes. La variante greenfield ofrece el atractivo de crear un sistema nuevo y libre de cargas, lo que conlleva menores costes de mantenimiento. Sin embargo, el sistema heredado debe seguir funcionando para garantizar el acceso al historial.

La alternativa brownfield evita el esfuerzo inicial de ordenar los datos antes de la migración, pero cartografía todo el historial incluso después de la conversión a 7.2.

Una vez acordada la gobernanza del proyecto, las interfaces plantean dudas. En SolMan 7.2, SAP proporciona su propio editor BPML, lo que plantea la cuestión de cuánto tiempo se mantendrá la interfaz con herramientas de terceros.

El nuevo paquete de pruebas también plantea la cuestión de si la interfaz con otros programas de pruebas seguirá siendo utilizable y durante cuánto tiempo. La interfaz con HP QC ya no está incluida en la norma y debe adquirirse por separado.

El requisito crítico de Life Science de poder proporcionar firmas legalmente vinculantes también es un problema en 7.2. Esta funcionalidad adicional proporcionada por SAP para 7.1 ya no existirá en 7.2.

Esto significa que ya no se cumplen los requisitos para un proceso de firma conforme a la normativa. En este caso, es necesario encontrar soluciones individuales para colmar las lagunas de GxP, idealmente con un socio experimentado.

La estructura de 7.2 sobre métodos ágiles de proyecto también plantea una cuestión especial. La conciliación de los métodos de proyecto ágiles y la documentación sistemática conforme a GxP es una empresa difícil, para la que faltan valores empíricos de inspecciones anteriores. En este caso, hay que desarrollar nuevos enfoques o prescindir de funcionalidades para superar una inspección.

En resumen, la introducción de SolMan 7.2 supone un gran reto para sus responsables.

Si las empresas asumirán el riesgo de operar sistemas SAP (en Hana) con SolMan 7.1, que se ha quedado sin mantenimiento, o si aceptarán el reto de la actualización: Sigue siendo apasionante. Sin embargo, tarde o temprano tendrán que tomar una decisión.