Actualización a Solution Manager 7.2 - ¡Mantenga la calma!

Para una actualización segura y satisfactoria a la versión 7.2 se requiere una estrategia de actualización específica. Ésta debe establecerse sobre la base de una sólida matriz de decisión de actualización, que puede utilizarse para derivar un planteamiento de solución personalizado para la actualización correcta y segura a 7.2. Los cinco parámetros centrales de dicha matriz son

1. Priorizar las aplicaciones 7.1 que deben migrarse: ¿Qué aplicación debe volver a ser totalmente funcional en 7.2 y en qué plazo? Porque: Un Service Desk, la Gestión de Solicitudes de Cambio (ChaRM) y la supervisión basada en la Infraestructura de Supervisión y Alertas (MAI) se migran en el menor tiempo posible, incluida la reelaboración (automatizada/manual), incluyendo Por el contrario, una actualización del conjunto de pruebas implica un laborioso desmontaje manual (en 7.1), reconstrucción y reelaboración (en 7.2). En este caso, sin embargo, la documentación de la solución/proceso supone un esfuerzo menor que la reorganización completa de los planes y paquetes de prueba, ya que sólo se migran los casos de prueba incluidos en la documentación del proceso, incluidas las incidencias asociadas a ellos. Por lo tanto, se recomienda a los clientes que sólo utilizan el Test Suite de forma intensiva que comparen detenidamente el escenario de actualización con el de la nueva instalación, pero lo que rara vez cambia al actualizar de 7.1 a 7.2 es un cambio fundamental en la documentación de procesos. Así es, ¡hay que ponerla en orden antes de una actualización!

   Sin embargo, esto suele hacerse en los proyectos 7.1 como parte de las actividades de preparación de la actualización. La mayoría de los clientes no necesitan más de un día para ello.

2. La programación concreta de las aplicaciones que se van a migrar: Siempre que sea posible, evite programar la migración del conjunto de aplicaciones de prueba poco antes o durante una prueba de integración próxima. Este no debería ser el caso del conjunto de pruebas. Esto se debe a que requiere una labor manual de preparación, reorganización y seguimiento que lleva mucho tiempo.
3. Desvincular la cuestión de "actualización frente a nueva instalación" de la intensidad de uso de las aplicaciones seleccionadas, especialmente la documentación de procesos en 7.1: Esto significa que, independientemente de la intensidad de uso de los proyectos y su contenido (procesos, objetos técnicos, etc.) en 7.1, el cambio a 7.2 nunca significa automáticamente "preferir un escenario de actualización a una nueva instalación": Puede haber buenas razones para cambiar de la antigua (7.1) a una nueva instalación 7.2, ya que los proyectos de 7.1 también pueden exportarse desde 7.1 a través de las rutas de activación de contenido proporcionadas por SAP e importarse a una nueva instalación 7.2 o (re)activarse allí.
4. La definición del paisaje de sistemas a gestionar por el 7.2 o sus características específicas en la administración de la solución 7.2: Esto requiere una conexión/configuración limpia de los sistemas a gestionar (aún con 7.2) y por favor compruebe siempre todas las conexiones RfC (aún) requeridas en este sentido, incluyendo las pruebas de conexión y autorización. De lo contrario, muy poco funcionará en cuanto a la configuración de la administración de la solución 7.2.
5. La fase creativa para desarrollar nuevos escenarios de soporte 7.2 para proyectos y operaciones: Estoy pensando aquí en particular en la cartera de TI y la gestión de proyectos, así como sus usos potenciales para la organización estructurada de los próximos planes de proyectos, etc., incluida la plena integración en la gestión de requisitos y cambios.

Conclusión:

Actualice a 7.2 a su propio ritmo. Establezca prioridades en cuanto a la base y las aplicaciones y abra el nuevo mundo de su entorno de soluciones SAP con un plan y sentido de la proporción.