Ejecución de conversión S/4HANA en modelo mixto – Greenfield + Brownfield

Imaginemos un ejemplo extremo, pero que hemos vivido en varios proyectos. Implantamos nuestro SAP R/3 en los años noventa, lo pasamos a SAP ERP o SAP ECC a principios de siglo, y lo hemos ido actualizando con sucesivos paquetes de mejoras (EHP’s) y parches (SP’s). Hasta ahora, SAP ha mantenido una retrocompatibilidad que nos permitía seguir funcionando con las funcionalidades antiguas.

Con la llegada de S/4HANA y su principio de simplicidad, lo primero que hacemos es evaluar nuestra situación actual. Ejecutamos la simplification list, que nos ofrece una primera visión. Analizando el documento, vemos los add-ons y las business functions que tenemos activadas y que no son compatibles con nuestra instalación. Esto se resuelve relativamente fácil, ya que cada fabricante de add-ons suele tener una estrategia de conversión o desinstalación. Además, debemos tratar aspectos técnicos como si estamos en UNICODE o si tenemos nuestra pila JAVA y ABAP en single stack.

A continuación, obtenemos nuestra simplification list personalizada, donde identificamos las funcionalidades que debemos sustituir. Entre las más comunes se incluyen:

Finalmente, consideramos si incluir mejoras en el proceso y cuándo, así como otros aspectos como archivar datos antiguos.

Primero, debemos asegurar la ejecución de los aspectos técnicos de la conversión, como la conversión a UNICODE o la separación de las pilas JAVA y ABAP. Normalmente, aprovechamos la necesidad de actualizar los sistemas operativos para hacer una reinstalación que cumpla con los requerimientos técnicos iniciales.

Dejando de lado los aspectos técnicos, nos centramos en el proceso funcional. Organizamos nuestro proyecto para ejecutarlo de manera eficiente y renovar todo de manera efectiva.

Para las actuaciones obligatorias detectadas en la simplification list, SAP nos indica cuándo hacerlas: antes, durante o después del proceso de migración, y si son obligatorias u opcionales. Tras un análisis, determinamos el orden exacto de cada una y la estrategia de ejecución. Un aspecto común a casi todos los proyectos es la activación de la sincronización de Business Partners. Nuestra recomendación es apartar estas actuaciones del proceso principal de conversión y ponerlas en productivo antes de iniciarlo.

Junto con la activación de la sincronización de Business Partners y otras mejoras obligatorias antes de la conversión a S/4HANA, podemos aprovechar este plazo para poner en productivo pequeñas mejoras identificadas (quick wins) que podamos activar en ese tiempo (de 2 a 3 meses). Así, dentro del proceso de innovación, el usuario detecta pequeños éxitos y el proyecto se convierte en uno de innovación, no solo tecnológico.

Una vez iniciado el proceso de conversión, de la simplification list tenemos procesos que se convierten durante el proceso, a través de los procesos establecidos por SAP y mediante cierto customizing. Esto incluye aspectos como una activación básica del Material Ledger o de las áreas de planificación, suficiente para tener nuestro sistema listo para funcionar con S/4HANA.

Si queremos mejorar estas activaciones básicas y establecer definiciones más complejas, o sustituir herramientas como eCAD por ECTR, entra en juego nuestro modelo “brownfield + greenfield”. Debemos hacer un pequeño proyecto de implantación de estas funcionalidades dentro del proyecto de conversión y planificarlo de forma coordinada para evitar interferencias.

En la planificación del proyecto, dado que estamos definiendo un proceso de innovación, tendremos mejoras no dependientes del proceso de conversión. La pregunta es cuándo abordarlas. La respuesta fácil es dejarlas para después de la conversión, estrategia adecuada para mejoras no urgentes.

Para mejoras urgentes, en IDOM proponemos prepararlas en un servidor adicional (SANDBOX) y, según se prueben los procesos de conversión, irlas probando y transportando en estos entornos de pruebas. Al final, una vez convertido el servidor productivo, en el servidor de integración ya estarán definidas, activadas y probadas, permitiendo un GO-LIVE rápido, por ejemplo, un mes después del lanzamiento del proyecto principal de conversión. Aquí consideramos cambios en procesos de cierta entidad, actuaciones relacionadas con costes o procesos contables, o la implantación de nuevos módulos que mejoren sustancialmente nuestros procesos.

Custom Code

Planificar un proceso de conversión a S/4HANA puede abordarse como una renovación tecnológica para adoptar nuevas innovaciones una vez implementada la versión correspondiente de S/4HANA. Alternativamente, se puede optar por un proyecto más ambicioso que aproveche el equipo disponible para mejorar e implementar nuevos procesos.

¿Cuál sería entonces la mejor estrategia? Siento deciros que no existe una estrategia única que sea la mejor para todos los casos. Cada situación debe ser analizada en función de los recursos disponibles y el grado de evolución del ERP en los últimos años. En IDOM, recomendamos no abordar proyectos demasiado ambiciosos. Es crucial medir claramente los objetivos que se desean alcanzar y asegurarse de contar con los recursos necesarios para lograrlo.