Los primeros criterios de decisión son el estado actual del sistema, la release en la que nos encontramos (Sea 6.0, Unicode – no Unicode…etc), los add-ons SAP y no SAP instalados y las funciones empresariales activadas…
Vamos a considerar las siguientes preguntas.
¿Podemos convertir nuestro actual sistema a SAP S/4HANA en un solo salto?
Si nuestro sistema está ejecutando una versión inferior a SAP ERP 6.0 o si nuestro sistema es no-Unicode, tendremos que realizar la conversión en varios fases o saltos.
Primero, deberemos actualizar a una versión que permita la conversión del sistema y después convertirlo a Unicode.
Para los sistemas SAP muy antiguos, (Hablamos anteriores a la 6.0) que ya no tienen soporte, el enfoque o estrategia de nueva implementación podría ser una solución más idónea ya que minimizaremos tiempo, costo y riesgo.
¿Contamos con algún complemento (add-on) que aún no esté soportado por SAP S/4HANA?
Desgraciadamente no todos los add-ons para SAP ERP están ya migrados para SAP S/4HANA.
Aunque muchos de ellos ya están disponibles y otros muchos están en proceso puede que justo el que usamos nosotros no esté disponible .
Antes esta dura tesitura, si nuestra empresa está utilizando un add-on que aún no está disponible o que ya no existe, la única opción será una nueva implementación.
(Deberemos cubrir la funcionalidad de este add-on mediante procesos estándar, otros productos, etc).
¿Cuál es el impacto de la conversión a SAP S/4HANA en los procesos de negocio que usamos?
Vamos a considerar las siguientes preguntas:
¿Están nuestros procesos de negocio soportados por S/4HANA?
Si nuestros procesos de negocio actuales son compatibles con SAP S/4HANA o si bien los nuevos procesos de negocios S/4HANA cumplen con nuestras necesidades, una conversión del sistema es la opción recomendada.
Recordemos que tal y como acabamos de mencionar con los add-ons, no todos los procesos de negocio estarán disponibles en SAP S/4HANA.
Si en nuestra empresa utilizamos de estos, uno de los que no será migrados, deberemos adaptar nuestra forma de trabajar a los nuevos procesos que existen en SAP S/4HANA.
En caso de que muchos de estos procesos necesiten ser rediseñados, de nuevo una nueva implementación podría ser la opción más adecuada ya que podemos aprovechar e implantar las Best Practices de SAP para acelerar la implementación. Posteriormente podremos migrar la información de nuestro sistema legado al nuevo sistema utilizando la SAP S/4HANA Migration Cockpit SAP S/4HANA.
Los sistemas SAP sin ningún desarrollo ABAP son rara avis.
La cantidad de desarrollo ABAP en nuestro sistema impacta directamente en la complejidad de nuestra conversión.
Consideremos las siguientes preguntas:
¿Sus estos desarrollos ABAP todavía necesarios?
En caso afirmativo, es decir, en caso de que el desarrollo ABAP necesite ser preservado, la conversión del sistema es probablemente la mejor opción.
Contamos con herramientas que nos ayudarán a analizar y adaptar código.
En un escenario ideal, lo idóneo sería combinar una revisión de la funcionalidad de los desarrollos ABAP con la migración a SAP HANA.
Es muy recomendable utilizar la funcionalidad de Custom code management de SAP Solution Manager para eliminar o limpiar el código obsoleto.
Muchísimos sistemas SAP cuentan con una gran cantidad de código personalizado que ya no se utiliza.
Como acabamos de mencionar e insistimos en ello, la migración a SAP S/4HANA podría ser nuestra oportunidad para una limpieza.
¿Podemos reemplazar nuestros desarrollos por funcionalidad estándar de SAP?
Repetimos que siempre es muy buena idea volver al estándar SAP.
Tiempo de implementación.
El costo y tiempo necesario para la migración a SAP S/4HANA dependerá de muchísimos factores.
Aunque por norma general, la conversión del sistema suele ser más rápida que una nueva implementación ya que una nueva implementación siempre implicará un rediseño completo de nuestros procesos de negocio y de nuestros blueprinting. Para intentar paliar al máximo esta situación siempre podremos utilizar las best practices de SAP para acelerar la implementación.
SAP S/4HANA no es sólo el sucesor de SAP ERP.
Es un producto completamente nuevo construido sobre SAP HANA y que incluye una de capa de experiencia de usuario a través de SAP Fiori.
Aunque a simple vista podremos reconocer muchas transacciones y programas de SAP ERP, a nivel interno se ha rediseñado casi desde 0.
El modelo de datos o el diccionario de datos ha sido revisado y rediseñado por completo.
Desde el lanzamiento de SAP R/3 hace ya 25 años, se han agregado características en todos estos años, el modelo de datos no había cambiado cambiado mucho.
Es decir, aunque se añadían tablas y estructuras a medida que pasaba el tiempo, el núcleo seguía siendo el mismo.
La principal innovación quizás ha sido la simplificación del modelo de datos en SAP S/4HANA, esto ha sido posible gracias a la velocidad que proporciona SAP HANA.
La base de datos de SAP HANA ha sido específicamente diseñada para rendir al máximo.
Todos los datos se comprimen y se guardan en memoria, lo que permite realizar operaciones de lectura masivas sin necesidad de acceder al disco, evitando los temidos problemas de rendimiento (cuellos de botella)
Debemos tener en cuenta que aun hoy en día, los discos (Incluso los nuevos de estado sólido (SSD, NMVe..) siguen siendo un componente relativamente lento en comparación con la memoria.
SAP HANA además de ser una base de datos en memoria, se combina con la arquitectura basada en columnas.
Una base de datos columnar necesita menos operaciones que una base de datos tradicional basada en filas.
Aquí y como nos sucedió en el tema de los Add-ons no tenemos una estrategia ganadora ya que escojamos la que escojamos, Nueva implementación, conversión o transformación nos beneficiaremos de todo este potencial en materia de innovaciones