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. 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 de Kernel SAP, que son más técnicas y simples, si no a aquellas 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 validan 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 produzca 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 e incrementando 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 hay que aplicar otras tres notas como prerrequisito. Cuando se examinan esas tres notas, puede que tenga que aplicar otras 10, etc. En casos extremos, la cantidad de notas supone un esfuerzo similar al de una actualización.
Dado que los SPS y los EHP son 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 SAP Innovation and Optimization Pathfinder, que SAP pone a disposición de sus clientes. (ver en https://bpi-discovery-proxy.cfapps.eu10.hana.ondemand.com/request/PAF/).
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 es un proyecto de upgrade como los que se realizaban tiempo atrás, por ejemplo, una vez cada cinco años o incluso 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 asociadas a este. 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, es posible incluso automatizar las pruebas, en la medida en que la organización cuente 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.
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.
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 hacerlo cuando existe el riesgo de un EHP o SPS demasiado reciente, es decir, liberados hace menos de un mes.
En el otro 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.
Bonus Track 2: Migración a HANA y a S/4HANA
Muchos clientes plantean una migración a HANA, eventualmente en el contexto de una actualización, como un paso previo a la migración a S/4HANA.
Es importante aclarar que el tener un ERP en HANA o en otro motor de datos, no implica prácticamente ninguna diferencia en lo que respecta a un posterior proyecto de migración a S/4HANA, ya sea que se trate de una conversión o de una reimplementación (migración Greenfield, Brownfield, Greenfield, u otra).
La migración a S/4HANA es un proyecto mayor, donde las dificultades y los esfuerzos van por otro lado. Por lo tanto, a menos que realmente se quiera explotar alguno de los beneficios de un ERP (u otro sistema de la SAP Business Suite) sobre HANA, esta no es una justificación válida.
En resumen, no recomendamos migrar a HANA si el único beneficio (aparente) es avanzar hacia la migración a S/4HANA. No se gana nada. Solo se debe migrar a HANA si esto de por sí entrega beneficios.
Para más información de actualizaciones SAP y migración a SAP HANA, preparamos este trío de vídeos:
Nos encantaría poder asesorarle, contáctenos.
Feedback/discusión con el autor: Glen Canessa, Director de Preventa de Novis.
Artículos relacionados:
