Verificación de la caducidad de un rol como de la duplicidad del mismo

Actualización de support packages en un sistema SAP

Dentro del proceso de mejoramiento e innovación que SAP ha venido desarrollando nos encontramos con uno de ellos como es la actualización de support packages a un sistema SAP, en donde hoy por hoy y después de un uso prolongado del sistema convencional que se venía utilizando como era la transacción SPAM para el nivel abap y jspm para el nivel java, haya sido cambiada por una herramienta más sofisticada como es el SUM (software update manager).

Antes de entrar de lleno al tema quiero aclarar que una actualización de support packages no es más que una actualización del software, valga la redundancia, que se le hace al sistema para aplicarles mejoras y corregir bugs que se han encontrado con el fin de ofrecer más bondades o en su defecto quitar opciones que tal vez pudieran ya estar obsoletas o sean innecesarias para el funcionamiento a la operación. En este contexto debo aclarar que a diferencia de una nota oss, esta actividad de actualización de support packages, no se puede reversar, de ahí la importancia de conocer cuál es la mejor estrategia que va alineada o afín a una buena práctica. Como lo mencione, una aplicación de un support packages, es la actualización de un componente de SAP en un orden cronológico y que en algunos casos tendrá dependencias que deben ser aplicables o mejor deben ya estar aplicadas o implementadas antes de aplicar uno nuevo. Lo novedoso del tema con esta nueva tecnología es que se puede realizar de manera masiva, cosa que no ocurría cuando se hacía por el spam, pues la recomendación era que se aplicara un volumen determinado para un componente especifico, que estaba sujeto a una recomendación o que debía cumplir con unos requisitos necesarios para su buen éxito, aunque no faltaban los arriesgados que lo hacían en un solo envío, pero que la mayoría de las veces por alguna error protestaba y después de mucho pedalear y tratar de resolverlo,  no quedaba más que restaurar un backup, Otra ventaja es que integra la actualización del kernel.

A pesar de que este nuevo proceso toma más del tiempo, permite realizarlo por fases, manteniendo el sistema disponible para la operación y minimizando el tiempo de downtime. Una ventaja muy poderosa y porque no decirlo saludable para aquellas compañías en donde las ventanas de tiempo debido a su operación 7x24 son muy complejas y difíciles de lograr. Ahora comparado con respecto al sistema convencional como era el spam en donde a pesar de que tomaba un 50% menos del tiempo la indisponibilidad era muy grande, pues por recomendación lo mejor opción era hacerlo sin usuarios con el fin de minimizar los riesgos y errores y aquí es donde lo supera, pues el proceso es tan eficiente que lo realiza en paralelo, sin detener la operación.

Para hacer uso de esa eficiencia y garantizar que la operación se vea afectada en lo más mínimo y quitarnos de encima el factor tiempo, existe una alternativa de solución que permitirá manejar ese tiempo con una eficacia de tal manera que dicha actividad se logré de una manera muy tranquila y con un éxito asegurado.

Para empezar y aunque por lógica la actividad de actualización de los support packages a través de la SUM, se suele iniciar con el sistema desarrollo, no es una buena práctica pues hay una serie de riesgos que deben ser mitigados y que se resuelven de otra forma. ¿Aunque suene muy descabellado, esta actividad de actualización debe iniciar con el sistema productivo y bajo que lo fundamento?

En cortas palabras lo responderé porque es el sistema que tiene y sostiene toda la operación de la compañía y que resumiré con las siguientes razones, soportadas en argumentos desde el punto de vista técnico:

·         Primero, porque en una landscape de SAP, cada sistema es único.

·         Segundo, porque el sistema productivo es el que nos dará el espectro de problemas y/o inconvenientes que se pueden presentar en todos los ámbitos del negocio.

·         Tercero, porque para asegurar el éxito al menos debemos llegar al 95% de su cubertura en una de las tareas como son las pruebas unitarias e integrales después de su aplicación y que por lo general no se realizan en una semana, a lo sumo en 2 y muchas veces en 3 por cuanto requieren de tiempo y esfuerzo tanto del líder funcional como del usuario final que debe combinar con su día a día y muchas veces no es fácil pero que si o si se debe sacar adelante.

Es posible que aún no convenza, pero aquí entra el detalle de la buena práctica:

·         Lo primero a realizar es hacer una copia homogénea del sistema productivo a un sistema sandbox, en donde se tiene una copia instantánea del negocio y un espacio para que el encargado pueda proceder a realizar la actualización sin presiones y con toda la calma posible.

·         Lo segundo es realizar un buen plan de pruebas que te permitirá validar la aplicación y de manera preventiva conocer los eventos o sucesos que se pueden presentar con esa aplicación, inclusive clasificado por módulo para tener un mejor perspectiva y detalle del sistema.

Esta práctica debe venir acompañada y debe ser tratada como un proyecto y que mejor herramienta para manejarlo que  a través del sistema solman, en donde te permitirá tener el progreso, el éxito o fracaso de la ejecución de la transacción, la documentación en caso de fallo y en ultimas una identificación si es el caso que la actividad no afectó el funcionamiento en algún paso durante la ejecución de la transacción, muchas veces el error no se encuentra durante el lanzamiento de la transacción sino durante uno de los pasos que conforma la unidad lógica de trabajo. También puede ser utilizado para guardar la historia de lo que se le ha hecho a un sistema SAP.

El hacerlo de esta manera a través de un sistema sandbox, nos permite tener las siguientes ventajas:

·         Una indisponibilidad de los sistemas del landscape muy reducida ya que lo que se persigue es que se impacte en lo menos posible al negocio.

·         Unos tiempos estimados que permitirá tener claro en qué momento se pueden llevar a cabo la actividad en el landscape del sistema SAP.

·         El momento de las ventanas de downtime.

Una vez se tenga la culminación de las pruebas y resueltas, se procede a cerrar el proyecto y a obtener vía correo la aprobación de las pruebas, para preparar su aprobación y aplicación en el landscape (DEV, QAS, PRD). Que para ello debemos tener en cuenta las siguientes premisas:

·         La aplicación de transportes debe congelarse.

·         Se debe realizar después del cierre mensual.

·         Durante su aplicación lo mejor es no realizar ningún tipo de cambios.

·         Buscar las ventanas de mantenimiento, donde se debe reiniciar el sistema.

Ahora sí, ya con los problemas identificados, el orden de aplicación si debe iniciar con el sistema desarrollo, en paralelo con el sistema de calidad, con el fin de ganar tiempo para que empate con un fin de semana para aplicarlo en el sistema productivo, el tiempo total puede no ser mayor a una semana. Inclusive se puede iniciar la aplicación en el sistema productivo de tal forma que nos permita llegar un paso antes cuando se solicita el downtime.

Quiero cerrar el tema, no sin antes mencionar la forma como muchas empresas en la actualidad suelen aplicarlo, para que sirva como punto de referencia. Primero inician su aplicación en el sistema desarrollo, que puede tardar más de una semana. Luego sumarle aproximadamente de 2 a 3 semanas mientras se realizan las pruebas integrales, que son absolutamente necesarias. Aquí empieza a surgir un factor de riesgo y es que la actividad de transportes se encuentra congelada, pues se corre el riesgo de transportar objetos que tienen diferentes versiones que pueden llegar a fallar. Posteriormente, se continua con la aplicación en el sistema de calidad, que sería una semana más y así ser aplicado en el sistema productivo al que habría que sumarle una semana más. En total este proceso conlleva en el landscape aproximadamente un mes y medio en el mejor de los casos, pero no es tanto el tiempo pues además de los riesgos mencionados, muchas veces no se obtienen los resultados esperados y esto suele suceder cuando un sistema no se actualiza con frecuencia que por lo general no queda más que iniciar una restauración y seguir postergándolo lo impostergable. Todo lo anterior en ultimas desencadena en la afectación del negocio que en condiciones normales de operación una empresa no se puede dar ese lujo y más por la inversión que esto representa.