Solution Manager va a dejar de estar disponible: la transición a Cloud ALM no es un proyecto de gran envergadura

El tenant se configura en cuestión de minutos, los clientes autorizados no pagan costes adicionales por licencias y la parte operativa se configura en unos dos días-persona. Quien empiece ahora podrá decidir con calma qué funciones de Solution Manager sigue necesitando.

Las cosas no salen como se esperaba

El mantenimiento estándar de SAP Solution Manager 7.2 finaliza el 31 de diciembre de 2027. SAP recomienda a todos los clientes que completen la transición a SAP Cloud ALM antes de esa fecha. Hasta aquí, la situación es conocida. Sin embargo, existe una idea generalizada que no se sostiene: tenemos tiempo hasta 2030. El mantenimiento ampliado hasta finales de 2030 está vinculado al mantenimiento ampliado de SAP Business Suite 7 y, por lo tanto, no está disponible para todos los clientes. Las empresas que no contraten el mantenimiento ampliado para SAP Business Suite 7 pasarán, a partir de 2027, al mantenimiento específico para el cliente (Customer-Specific Maintenance) para las funciones de SolMan que no estén cubiertas. El plazo depende, por tanto, del estado de ECC de cada empresa, y no de una indicación general de la hoja de ruta.

Para el director de sistemas de información (CIO) y la dirección de TI, se trata de una cuestión de gobernanza, no de una cuestión básica. Debería resolverse antes de que el departamento operativo reciba una respuesta. Sin embargo, rara vez se tiene en cuenta un efecto secundario. En muchas empresas medianas, Solution Manager es el último sistema que utiliza la pila AS-Java. Los equipos están encantados de deshacerse de este componente, ya que, de todos modos, carecen de los conocimientos técnicos necesarios para gestionarlo.

Tres errores que retrasan el inicio

La verdadera razón de esa reticencia no radica en la tecnología. Se trata de tres suposiciones que, en los proyectos, suelen resultar erróneas.

En primer lugar: los costes. SAP Cloud ALM está disponible para los clientes de SAP que cumplan los requisitos sin costes adicionales de licencia. En SAP for Me se puede comprobar si se cumplen dichos requisitos con solo unos clics. Una parte considerable de los clientes no lo sabe y calcula mentalmente con un presupuesto que, en realidad, no se aplica.

En segundo lugar: el límite de memoria. SAP ha aumentado la memoria base a 24 GB en el marco de la política de uso razonable. En la práctica, este límite apenas se agota. Un cliente con unas 18 entornos conectados y una amplia cartera de servicios en la nube se sitúa en unos 6 GB de memoria HANA, sin haber realizado ninguna tarea de mantenimiento. Eso supone una cuarta parte del límite de uso razonable.

En tercer lugar: el esfuerzo. El tenant se aprovisiona en cuestión de minutos, mientras que la integración de sistemas individuales lleva horas. Se elimina por completo el despliegue de agentes, como ocurre con Solution Manager. El funcionamiento actual continúa en paralelo; SAP Cloud ALM no interfiere en los procesos en curso. Un patrón recurrente demuestra lo bajo que es realmente el umbral de entrada: hay clientes que han aprovisionado el tenant y han conectado un primer sistema de prueba, pero luego se han quedado estancados porque temían tener que adquirir una gran cantidad de conocimientos. Por eso, la decisión suele tomarse a nivel de dirección de equipo, y no en el comité de inversiones.

Lo que el SolMan nunca pudo hacer

Quien considere la transición como un mero trámite, pasa por alto lo más importante. SAP Cloud ALM supervisa los servicios en la nube y los sistemas locales en una única interfaz, incluidos los certificados y las claves API, por ejemplo, para el SAP Cloud Connector y la Integration Suite. El Solution Manager no cubría esta faceta de la nube, y es precisamente ahí donde crecen los entornos. Las claves API caducadas de una subcuenta son un clásico fallo silencioso. Nada se cuelga, nada activa una alarma; la interfaz, sencillamente, deja de funcionar. Esto se hace evidente cuando llama el departamento especializado. SAP Cloud ALM envía avisos configurables, por ejemplo, 90 días antes de la caducidad, con un recordatorio crítico 30 días antes. La alerta se envía allí donde se trabaja: al canal de Teams, a Jira o a ServiceNow, en lugar de a un buzón de correo que, de todos modos, está desbordado. No se trata de una cuestión de comodidad. Hay clientes actuales que se han cambiado precisamente por esta función, ya que las claves caducadas les han supuesto un verdadero obstáculo en el día a día de su trabajo.

La segunda área es la gestión centralizada de transportes para el desarrollo local y en la nube, con interfaz Fiori y sin pasos manuales de exportación e importación. En la práctica, el punto de partida suele ser casi siempre el área de Operaciones, mientras que el área de Implementación queda en segundo plano. Esto se debe principalmente a la redacción de la documentación, no a la realidad: los técnicos tienen allí menos trabajo de procesos de lo que creen.

El camino hasta llegar ahí, sin el Big Bang

La migración a SAP Cloud ALM se lleva a cabo por etapas: primero, la comprobación de preparación en Solution Manager; después, los sistemas de desarrollo y pruebas; y, por último, el entorno de producción. Ambas herramientas pueden funcionar en paralelo y compararse entre sí en la supervisión. Hay dos escollos que requieren una preparación previa. La gestión de identidades debe estar vinculada desde el principio al tenant IAS en producción; de lo contrario, se crearán tenants paralelos sin sincronización. Además, algunas métricas, como la supervisión del sistema de archivos, generan sobre todo falsas alarmas si no se configuran previamente. Ambos aspectos se pueden corregir a posteriori, pero resultan innecesariamente costosos. Importante para la evaluación de riesgos: SAP Cloud ALM es una capa de orquestación, no un punto único de fallo. Si el servicio falla, los transportes a través del TMS siguen siendo posibles de forma manual, a diferencia de lo que ocurre con ChaRM o Focus Build. La transición es, por tanto, controlable y reversible en cualquier momento. Hasta la fecha, apenas hay clientes actuales de SAP que se hayan arrepentido de dar el paso. Las opciones van desde una sesión de capacitación, en la que el propio equipo realiza la implementación y aprende sobre la marcha, hasta la configuración completa del tenant, la conexión del sistema y los servicios en la nube por parte de Entplexit.

Conclusión: 

El plazo está en marcha, pero el esfuerzo es previsible. Quien espera no pierde tecnología, sino margen de maniobra. El error más caro a la hora de migrar a SAP Cloud ALM es esperar. Quien empieza pronto decide por sí mismo qué funciones de Solution Manager sigue necesitando, en lugar de tener que recrearlas bajo la presión del tiempo. (Fuente: Entplexit)