Desde el año 2016 Novis ocupa un lugar destacado en los resultados del “Estudio Nacional de Tecnologías de Información” (ENTI) ...
Los clientes en SAP RISE necesitan servicios SAP AMS técnicos (Basis) y funcionales, aquí les contamos por qué.
La decisión estratégica que deben tomar los clientes para tener SAP en Cloud.
NOTICIAS
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.
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?
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/).
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 que optimice los proyectos de actualización debe considerar los siguientes elementos:
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.
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.
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:
LO MÁS DESTACADO
Suscríbete a nuestro boletín mensual para que estés enterado de todas nuestras noticias y nuevas tecnologías.