Las actualizaciones de las soluciones SAP constituyen un dolor de cabeza para la mayoría de las empresas. En primer lugar, no se ve la necesidad de hacerlo, a menos que las versiones estén quedando completamente obsoletas. Y en segundo lugar, no se cuenta con una metodología eficiente para realizar estos proyectos, por lo cual muchas veces se les enfrenta como un proyecto de upgrade “a la antigua” (por ejemplo, de ERP 5.0 a ERP 6.0), con altos costos, plazos y riesgos, aun cuando ya es poco común encontrar soluciones SAP en versiones muy antiguas.
No nos referimos aquí a las actualizaciones de plataforma (sistema operativo o motor de datos), ni a las actualizaciones de Kernel SAP, que son más técnicas y más simples, si no que a las actualizaciones conocidas como updates, o aplicaciones de SAP Enhancement Packages (EHP) y también a las aplicaciones de Support Package Stacks (SPS), ya que en la actualidad y por lo general ambas van de la mano.
Por qué actualizar SAP
En general, SAP recomienda aplicar SPS cada seis meses y EHP una vez al año, junto con los SPS. Para los jefes de TI es difícil justificar estos proyectos ante el área de negocios, por los costos y por el estrés que suponen para la organización. ¿Cuáles son las razones que justifican estos ciclos de actualizaciones?
- Nuevas funcionalidades. Cada EHP aporta un set de nuevas Business Functions que pueden ser activadas y aprovechadas por el negocio en la medida en que existe una disciplina de innovación o de mejora continua. Cada cliente paga anualmente un monto considerable a SAP para tener derecho a estas innovaciones y lo lógico es que las aproveche.
- Mayor estabilidad. Cada SPS incluye una gran cantidad de correcciones para todos los errores conocidos hasta la fecha de su liberación. Al aplicarlos, el cliente evita que se produzcan cada una de estas fallas, con el consiguiente ahorro en los costos asociados al impacto de un incidente, a su diagnóstico y a su corrección.
- Mejor rendimiento. Del mismo modo, cada SPS incluye mejoras y optimizaciones en el rendimiento de programas SAP, que son resultado de correcciones a los problemas de performance detectados.
- Mayor compatibilidad con nuevos proyectos o desarrollos = menor riesgo. En muchos casos ha ocurrido que al iniciar un proyecto, el cliente se encuentra con una incompatibilidad con la versión en uso, lo cual le obliga a hacer una actualización antes de comenzar. Esto impacta al proyecto original alargando sus plazos y aumentando sus costos en forma imprevista.
- Mejor mantenibilidad. En algunos casos, como producto de un incidente o de una mejora, es necesario aplicar una Nota SAP. Al analizar la nota, en relación con la versión (atrasada) del sistema, se encuentra que es necesario aplicar otras tres notas como prerrequisito. Al analizar esas tres notas, puede que tenga que aplicar otras 10, etc. En casos extremos, la cantidad de notas a aplicar supone un esfuerzo similar a una actualización.
Dado que con los SPS y los EHP se trata de actualizaciones masivas, en general no es una buena estrategia hacer un análisis de las nuevas funcionalidades para justificar el cambio ante el área de negocios. La mejor práctica es aplicar las actualizaciones en forma incondicional y ejecutar un plan de pruebas de regresión.
No obstante, puede ser que el negocio tenga planeada una mejora o proyecto específico, ante lo cual se justifique mejor la actualización, por existir una nueva funcionalidad que aplica al requerimiento. Para estos casos es posible utilizar la aplicación Business Function Prediction, que SAP pone a disposición de sus clientes en Innovation Discovery for SAP Products.
Cómo lograr actualizaciones eficientes
Lo anterior debería ser suficiente para justificar una actualización regular de la solución SAP. Sin embargo, siguen siendo importante los costos y esfuerzos asociados, especialmente porque se trata de una actividad regular, que debería ejecutarse al menos una vez al año. Como dijimos antes, no se trata de un proyecto de upgrade, como los que se ejecutaban tiempo atrás, una vez cada cinco años, o más (aunque algunas empresas siguen viendo estas actualizaciones de la misma forma que antes y las postergan al máximo).
Entonces, se justifica emplear una metodología que permita reutilizar los productos que genera el proyecto, tales como documentación de procesos, casos de prueba, etc., y que se base en herramientas que automaticen u optimicen las tareas del proyecto. Una metodología de este tipo permite disminuir los costos, los esfuerzos y los impactos en la organización, y así, al mismo tiempo, se convierte en una forma adicional de justificar las actualizaciones periódicas.
Una metodología optimizada
Una metodología que optimice los proyectos de actualización debe considerar los siguientes elementos:
- Uso de SAP Solution Manager (SolMan), incluyendo herramientas tales como SEA (Scope and Effort Analysis), SDA (Solution Documentation Assistant), BPCA (Business Process Change Analysis), CBTA, ChaRM (Change Request management), etc.
- Documentación reutilizable, la metodología debe incluir la generación de una documentación de procesos y de pruebas que sea reutilizable en las siguientes actualizaciones. En una etapa superior incluso es posible automatizar las pruebas, en la medida en que la organización cuenta con la capacidad de mantener esta disciplina.
- Roadmap de proyecto en SolMan. La funcionalidad de Project Roadmap permite seguir la metodología estándar de SAP para updates, controlar los avances y los entregables, etc.
- Ciclo de gestión de correcciones apoyado por SolMan. La gestión de correcciones generadas a partir de las pruebas puede ser tratada con la misma lógica de la gestión de incidentes, utilizando la funcionalidad ITSm de SolMan.
- Equipo de consultoría on demand. El equipo de consultoría para apoyar el proyecto puede, en gran parte, estar disponible on demand, especialmente los consultores más especializados y más caros. De este modo no se incurre en los altos costos de un equipo dedicado por todo el plazo del proyecto.
- ChaRM, un proyecto de este tipo es una buena oportunidad para implementar ChaRM, al menos en su versión más simple. Esta funcionalidad permite asegurar que los cambios generados durante el proyecto pasen ordenadamente al ambiente productivo. Una vez finalizado el proyecto es posible seguir utilizando las funcionalidades de gestión de cambios, agregando gradualmente una mayor sofisticación en el control del proceso.
En Novis tenemos la responsabilidad de mantener los sistemas SAP de más de 70 clientes. Como resultado, estamos permanentemente en un tren de proyectos de actualización. Esto nos ha obligado a generar un proceso repetitivo, con una metodología optimizada, aprovechando al máximo las herramientas y prácticas que SAP pone a disposición de sus clientes y partners.
Además tenemos servicios SAP certificados.
Bonus Track: El Mito del parche N-1
Muchos clientes aplican la política de actualizar al penúltimo (n-1) “parche” disponible. Si bien esta política puede ser adecuada para parches de sistema operativo o motor de datos, no resulta adecuada para el caso de SAP EHP o SAP SPS. Si el último EHP de SAP ERP ha sido liberado hace más de dos meses, no tiene sentido no aprovechar la oportunidad de actualizar hasta este último EHP. Solamente se podría justificar no hacer esta actualización, por el riesgo de un EHP o SPS demasiado reciente, en el caso de estar estos liberados hace menos de un mes.
En el caso extremo, un EHP puede tener 9 o 10 meses desde su liberación al momento de la actualización, en cuyo caso el riesgo de ir a este último EHP es prácticamente nulo, y en relación con el N-1, tiene beneficios significativamente mayores.
Links
Para más información de actualizaciones SAP y Migración a SAP HANA, preparamos este trío de vídeos :
- ¿Por qué debemos actualizar SAP?
- Upgrade y migracion a SAP HANA en un paso
- Servicios para Upgrade y Migracion SAP
Mayor información enhttp://wiki.scn.sap.com/wiki/display/EHP/Overview+SAP+Enhancement+Packages
http://service.sap.com/erp-ehp
Feedback/discusión con el autor: glen.canessa@noviscorp.com