Justificar el cambio a SAP S/4HANA

IDR, inspección, diagnóstico y recomendaciones

16366
Justificar el cambio a SAP S/4HANA

Todo evoluciona: los sistemas, las metodologías y también los procedimientos para ejecutar de forma exitosa cualquier transformación. En el camino, fruto de la experiencia y el conocimiento, aparecen nuevas formas de actuar, que se encargan de cambiar paradigmas y de dar un salto cualitativo.

David Arias García

Una de las preocupaciones más comunes que acosan a las empresas cuando se enfrentan a un proyecto de transformación de SAP S/4HANA es conocer con detalle el impacto, tanto funcional como técnico, que el cambio de versión del producto SAP va a suponer en sus sistemas. Es decir, qué funcionalidades se ven afectadas y en qué grado, cómo van a funcionar las integraciones, qué sucede con los desarrollos a medida, etc.

Por otra parte, además de lo anterior, aparece una necesidad recurrente en los departamentos TI de estas empresas: la de justificar y argumentar de forma adecuada el cambio hacia SAP S/4HANA, más allá de la finalización del mantenimiento de SAP Business Suite 7. De hecho, si pensamos en la necesidad de actualizar (upgrade) los sistemas SAP, veremos que es una situación frecuente que los responsables de TI están acostumbrados a manejar.

Un punto importante en este tipo de proyectos de transformación es que hay que tener claro que SAP S/4HANA es un nuevo producto, no una evolución de SAP Business Suite. Esto significa que adoptarlo requerirá abordar una serie de cambios (funcionales, técnicos, etc.) y tomar decisiones que obligan a efectuar un análisis previo, algo que no se puede relegar en la ejecución del proyecto.

Por esta razón, es importante utilizar herramientas como IDR SAP S/4HANA (Inspección, Diagnóstico y Recomendaciones). Básicamente, consiste en efectuar un análisis que permite identificar con precisión los impactos técnicos y funcionales que conlleva la transformación hacia S/4HANA. Además, también ayuda a determinar posibles mejoras de esta evolución, que permitan conformar un business case atractivo para el negocio, con argumentos que vayan más allá del fin del mantenimiento del producto.

Análisis IDR

El enfoque es muy claro: hay que ver el sistema como si fuera un paciente y tratarlo como tal: se debe realizar un chequeo completo, auscultando, radiografiando y aplicando todas las técnicas a nuestro alcance para obtener, de forma rigurosa, toda la información necesaria para aplicar el tratamiento que garantice el éxito de la transformación.

El análisis permite identificar con precisión los impactos técnicos y funcionales que conlleva la transformación hacia S/4HANA

El análisis tiene un enfoque factual, es decir, todo diagnóstico o recomendación tiene que fundamentarse en una evidencia, obtenida del conjunto del conocimiento que proviene de un equipo humano experto en SAP y del uso de herramientas de diagnóstico avanzado, como euKaria o CVWM de NovisEuforia.

El estudio contempla diferentes dominios o ámbitos de actuación. Debemos analizar cada uno de forma pormenorizada, ya que pueden tener sus propios beneficios o estar relacionados entre sí.

Dominios IDR S/4HANA​

Definimos un dominio como una materia de estudio relevante para el análisis SAP S/4HANA. Cada dominio puede tener diferentes fuentes de información, es decir, diferentes aplicaciones que proporcionan datos relevantes sobre la materia analizada.

Simplificaciones. Este dominio es el responsable de identificar, clasificar y priorizar las simplificaciones funcionales y técnicas relevantes de cada sistema, así como de identificar potenciales conflictos a escala de base de datos, analizando los impactos presentes y futuros (compatibility packs), y valorando las alternativas disponibles.​

Business Partner​. Proporciona información sobre la calidad de los datos de clientes y proveedores, como un paso previo a la sincronización CVI (customer vendor interface). También analiza la posibilidad de que existan duplicados en clientes y proveedores, con el objetivo de seleccionar un registro gold para su conversión a BP (business partner).​

Add-on, BW, IDOC, BF. Se trata de identificar y categorizar cómo se ven afectados esos objetos por SAP S/4HANA, lo que permite conocer con antelación el posible impacto en los sistemas.​

Interfaces. Busca identificar, clasificar y determinar el mapa de integraciones de SAP con los sistemas satélites a los que esté conectado. En un primer término, se utilizará la información sobre los siguientes tipos de interfaces: IDOCS, Webservices, RFC/BAPI, extractores BW, Odatas, integraciones SLT. Además, será necesario identificar y categorizar las interfaces, con la posibilidad de integración con SAP Solution Manager Interface Library (Process Management).​

Roles y autorizaciones. En este caso, se trata de identificar y clasificar el impacto de SAP S/4HANA en roles y autorizaciones, así como de establecer el modo en el que afecta a los usuarios o las alternativas disponibles. Además, detalla aquellas aplicaciones Fiori que son apropiadas en función del uso transaccional productivo, y qué transacciones —actualmente empleadas por el usuario— desaparecen.

Migrar a SAP S/4HANACódigo ABAP. En este dominio se busca identificar, clasificar y priorizar los impactos que tendrá SAP S/4HANA en el código ABAP, estableciendo medidas de remediación (manuales o automáticas) o incluso la retirada de código obsoleto/no usado.​ En caso de no disponer de un SAP S/4HANA o Netweaver 751 o 752, se podría utilizar una conexión con nuestros sistemas para llevar a cabo el estudio del dominio.

Estrategia. Destinado a determinar la mejor estrategia de adopción de SAP S/4HANA en función del análisis de la información del resto de los dominios, a lo que hay que sumar los requisitos y necesidades de cada compañía.​

Infraestructura. Además, es importante analizar y definir las diferentes opciones de arquitectura de sistemas para la adopción exitosa de SAP S/4HANA, considerando el sizing estimado y garantizando la interoperabilidad entre sistemas SAP.​

Datos. Analiza, evalúa y cuantifica los datos en los sistemas SAP, y establece su relación tanto con los módulos SAP como con las estructuras organizativas de la empresa que les dan soporte (sociedades, organizaciones de compra, centros, área de ventas, etc.). El objetivo es que se puedan tomar decisiones basadas en hechos sobre la idoneidad de mover determinadas entidades a S/4HANA.​

Consolidación. Este dominio analiza la posibilidad de consolidar, en un solo sistema SAP, sociedades que pertenecen a otro sistema o grupo de sistemas, teniendo en cuenta que, en ocasiones, se aprovecha el paso a S/4HANA para simplificar el landscape de los sistemas SAP ERP. Este dominio analizará los conflictos reales o potenciales en relación con las entidades organizativas (sociedad, centro, etc.), módulos SAP en uso, comparación de tablas, transacciones y programas custom, comparación de customizing, y datos maestros y transaccionales.

Funcional. Con el input del IDR S/4HANA se podrán revisar con el AM (application manager), que es quien mejor conoce la funcionalidad y configuración instalada, todas aquellas modificaciones derivadas de SAP S/4HANA y las opciones disponibles, así como valorar qué funcionalidades encajan mejor con sus necesidades, entre otras cosas.

Después de varios años explicando la necesidad de esta evolución, el sector ya interiorizado la necesidad de dotarse de S/4HANA. De hecho, se está adoptando de forma realmente acelerada, ya que, como sucede con todos los cambios de paradigma, cuando se producen no hay vuelta a los métodos anteriores. Por ejemplo, en Novis Euforia hemos ejecutado un total de siete IDR SAP S/4 HANA solo en el primer semestre de 2023.

Artículo anteriorAutomatización basada en eventos
Artículo siguienteEstrategias data-centric
Novis Euforia
En Novis Euforia, SAP Certified, creemos que el movimiento al Cloud unido a la mejora y automatización de la operativa es un pilar esencial en la transformación de las empresas.