En febrero de este año SAP anunció que extenderá el soporte general para las aplicaciones de SAP Business Suite 7 hasta 2027 con un periodo de servicio más restringido hasta 2030.

Originalmente este ultimatum iba a ser en el año 2025 pero la adopción hasta ahora del nuevo ERP por parte de las empresas ha sido más lenta de lo que el gigante alemán imaginaba. En vistas a proteger la inversión de los clientes y asegurar el funcionamiento del Business As Usual mientras se preparan para el nuevo ERP, decidieron extender el periodo de soporte del sistema actual. 

Lo cierto es que SAP está poniendo el foco en S/4HANA y apostando al futuro con esta nueva plataforma que dejará obsoleto al conocido Business Suite 7. Teniendo en cuenta esto, muchas empresas están aprovechando la extensión de este deadline para revisar sus sistemas, diagnosticar su estado y progresivamente establecer el alcance del proyecto, los tiempos e inversión necesarios para llegar preparados a la fecha final.

El paso a S/4HANA tiene un nivel de complejidad alto. Es necesario tanto un asesoramiento funcional como técnico para poder diseñar un roadmap claro de implementación en el escenario particular de cada cliente. No es lo mismo si hablamos de una conversión, una nueva implementación, un landscape transformation a partir de varios ERP o si decidimos migrar a la nube.

En este artículo me gustaría enfocarme en el primer caso: una conversión de un ERP a S/4HANA on Premise. Desde mi experiencia como consultor técnico SAP he identificado algunos pre-proyectos con foco en el aspecto técnico que ayudan a las empresas en este proceso.

6 pre-proyectos de transición hacia S/4HANA

1. Recursos hardware

Un primer paso fundamental es entender la diferencia entre los requerimientos de memoria y procesamiento de datos del ERP actual y el necesario para S/4HANA. El nuevo ERP al utilizar SAP Hana como base de datos, tiene considerablemente mayores requerimientos de memoria RAM que las versiones anteriores que corrían sobre otras bases de datos. Por ejemplo, un sistema de aproximadamente 1.5 TB de datos, podría requerir al menos 1 TB de memoria RAM para funcionar correctamente, lo cual es más de un orden de magnitud superior a los 30-40 GB que podría consumir una base de datos Oracle para ese mismo volumen de datos.

Es fundamental realizar un correcto análisis del hardware que vamos a requerir para lograr los resultados que se esperan de S/4HANA. Sobre todo teniendo en cuenta que si hablamos de un servidor on premise, por ejemplo en Argentina, se podría demorar  varios meses o un año para adquirir un nuevo equipo si se comete un error en la estimación de los recursos necesarios.

La infraestructura completa de hardware para soportar SAP HANA (procesadores, almacenamiento, red, etc) debería ser cuidadosamente seleccionada para asegurarse que cuente con componentes certificados y homologados para garantizar su correcto desempeño.

Deberemos realizar un sizing aditivo teniendo en cuenta todos los módulos y funcionalidades que vamos a querer activar una vez que migremos a S/4HANA. Por ejemplo, si activamos SAP Fiori para mejorar notablemente la experiencia del usuario tenemos que tener en cuenta la cantidad de recursos que podría consumir para hacer un cálculo correcto del hardware que necesitamos. 

2. Unicode

Entre los varios aspectos a analizar, otro muy importante es que el sistema SAP ERP sea unicode antes de comenzar con la conversión. Si nuestro sistema es aún NO-Unicode entonces debemos realizar un pre-proyecto de conversión a unicode de todo el ERP.

3. Add-ons

Los add-ons se utilizan para ampliar la funcionalidad de los sistemas SAP. En general, como parte de una estrategia individual de cada empresa se pueden adquirir add-ons específicos de SAP o de terceros y podrían tener un gap de compatibilidad con la fecha de lanzamiento de cada versión de SAP S/4HANA.

Si pensamos que vamos a seguir necesitando esa funcionalidad en un escenario de co-deployment tenemos que chequear si ese add-on es compatible con la versión de S/4HANA que queremos usar. Si no lo necesitamos podemos desinstalarlo pero siempre se debe realizar este análisis previo a la conversión.

4. Data Management

Esto es importante ya sea que migremos a S/4HANA o no. Se recomienda que periódicamente corramos procesos de limpieza y archivado. Algunos tipos de datos técnicos necesitan una estrategia específica de manejo de datos para borrar sólo los que están obsoletos: comunicaciones, logueo, auditorías, administración o metadata, entre otros. Los tipos de datos de negocio, por ejemplo documentos financieros, se deberían analizar en base a la recomendación generada por el escenario Data Volume Management de SAP Solution Manager.

Un proyecto organizado y meticuloso de Data Volume Management resuelve problemas de espacio de memoria y rendimiento causados ​​por grandes volúmenes de datos y garantiza que el crecimiento sea controlado y manejable a largo plazo, lo cual es fundamental para cuando decidamos comenzar la conversión a SAP S/4HANA. A mayor reducción del volumen de datos, menor tiempo de downtime durante la conversión. 

5. Interoperabilidad 

SAP Readiness Check nos ayuda a evaluar cuan preparados estamos para la conversión pero está enfocado en el ERP. El resto de los módulos deben ser analizados manualmente para garantizar la interoperabilidad. 

Pensemos solo un ejemplo de los numerosos que existen dependiendo el ecosistema propio de cada empresa. Supongamos que tenemos un SAP ERP 6.0 que está integrado con SAP Customer Relationship Manager (SAP CRM) y otros módulos. Si este SAP CRM no es nuevo, entonces podría suceder que S/4HANA no soporte  esa versión, entonces tendríamos que previamente actualizarlo y luego planificar la conversión a S/4HANA. 

Por otro lado, hay módulos que SAP ya informó que no van a evolucionar o serán discontinuados, que van a ser reconvertidos o formar parte de otro producto y que, por lo tanto, podrían perder compatibilidad con S/4HANA o perder relevancia. Un ejemplo puede ser el módulo de logística SAP LE-TRA que ya no evoluciona más, por lo que sería necesario implementar SAP Transportation Management (SAP TM) para continuar adquiriendo los beneficios de las nuevas funcionalidades e innovaciones que SAP va liberando continuamente. 

En empresas que tengan versiones nuevas el esfuerzo total puede ser considerablemente menor, por eso puede ser una buena política comenzar a planificar un roadmap progresivo de estas actualizaciones y migraciones para comenzar a disfrutar de los beneficios cuanto antes.

6. Custom Code

Es necesario realizar un análisis de los desarrollos Z en el sistema SAP ERP de la empresa para determinar su compatibilidad con S/4 HANA.  Se recomienda comenzar con la identificación del código que se utiliza productivamente y eliminar el código que ya no se usa con la ayuda de la herramienta ABAP Call Monitor (SCMON). En una segunda etapa, con la ayuda de la herramienta ABAP Test Cockpit (ATC), se podría ajustar el código para que esté preparado para S/4HANA.

Comience hoy su propio camino hacia S/4HANA

Luego de casi 30 años SAP ha creado un ERP completamente innovador atendiendo las necesidades de análisis de grandes volúmenes de datos en tiempo real que hoy manifiestan las industrias. El camino del futuro en el ecosistema está marcado y toda innovación se realizará sobre SAP S/4HANA. Por eso, cuanto antes comience la transición mejor preparado estará su negocio para lo que se viene.

Cada empresa tiene sus necesidades técnicas y de negocio particulares porque también ha creado un ecosistema SAP y no SAP único. Por eso es fundamental realizar un análisis detallado de cada caso para comprender cuan preparados están para el nuevo paradigma, cuál es el roadmap de conversión más eficiente y cuánto tiempo e inversión será necesario. 

En GoTechy contamos con un equipo experto y podemos acompañarlo en ese camino de innovación. Contáctenos.