Transformación a S/4 y Hana: ¿Cómo gestionarla?

S/4 no es un tigre de papel

Odiseo tuvo diez años para volver a casa desde Troya y llegó a su Itaca natal como un mendigo. El cliente actual de SAP sólo dispone de unos cinco años y no quiere parecer un varado, pero con un proyecto de gestión del cambio de éxito.

Un "cambio de versión" no es una situación nueva o inusual. Desde los exitosos días del R/2, ha sido una buena práctica personalizar un sistema SAP sólo con la ayuda de consultores y expertos experimentados. Pero Hana y S/4 no son sólo personalizaciones.

Como muestra claramente el informe de Heiko Friedrichs, Hinrich Mielke y Achim Zimmermann, los requisitos son mucho mayores esta vez. Se trata de la transformación digital del mundo SAP. No se trata de un cambio de versión técnica.

En la transformación a S/4 también deben tenerse en cuenta aspectos empresariales, organizativos, técnicos y de concesión de licencias. El recurso a consultores y expertos es un procedimiento natural para ello.

En la fase de "transformación digital", el cliente SAP existente necesita mucha experiencia y conocimientos que luego ya no se necesitan a diario en el negocio operativo. Un sistema SAP correctamente configurado no es una máquina en movimiento perpetuo, pero sí una máquina bien engrasada que solo necesita un refresco de sangre ocasional.

Recurrir a consultores y expertos, como hacen los equipos de Devoteam Alegri y QPCM, es por tanto el proceso natural de personalización en la comunidad SAP. SAP lo ve de forma similar, pero el inventor de Hana y proveedor de S/4 ha cometido un error: los consultores y expertos no están disponibles a voluntad y su jornada solo tiene 24 horas.

Los grandes clientes de SAP ya han comprado miles de días-hombre a consultorías globales hace muchos meses. Aquí no hay más recursos disponibles hasta 2025.

Los socios medianos de SAP tienen el mérito de haber empezado hace tiempo a acumular a sus expensas conocimientos sobre Hana y S/4, que muchos clientes existentes necesitan urgentemente en estos momentos. Si SAP debe o tiene que dar una vuelta de tuerca al tiempo en vista de los escasos recursos de consultores, probablemente no se decidirá hasta 2022.

Sin embargo, esperar no es en absoluto una opción. Y un consejo más para la comunidad SAP. Estrictamente hablando, esta transformación digital trata de dos temas: Base de datos y ERP.

Hana puede ser una base de datos fantástica, pero también un reto. Achim Zimmermann de QPCM podría llenar libros sobre ella. S/4 es un nuevo modelo y concepto de ERP. Heiko Friedrichs y Hinrich Mielke de Devoteam Alegri pueden demostrarlo con muchos ejemplos.

En el siguiente texto, el tema se explica brevemente utilizando el ejemplo del nuevo libro mayor. Sin embargo, las áreas de FI/CO y logística se ven afectadas en cualquier caso. Por tanto, S/4 no es un tigre de papel, sino todo lo contrario: es un reto al que hay que prestar mucha atención, ¡incluso con la ayuda de expertos! (pmf)

La fecha límite oficial es 2025.

El problema: SAP ha garantizado el soporte para ECC 6.0 hasta 2025. Para el tiempo posterior, solo se ha señalado soporte para S/4 Hana a partir de hoy. Esto significa que el cambio a S/4 debe completarse en cinco años y medio.

Este periodo es más corto de lo que parece. Al igual que ocurrió con la transición al año 2000 y al euro, a medida que se acerca la fecha límite es más difícil conseguir personal cualificado. Esto es cierto tanto interna como externamente, así como a escala mundial. El reto es similar: No era una opción "no seguir adelante" con el cambio al año 2000 o al euro.

También hay que tener en cuenta que, además de la vertiente tecnológica (cambio a una nueva base de datos, posiblemente un nuevo sistema operativo), también hay que considerar los procesos empresariales y la evolución interna.

Paralelamente, deben aclararse cuestiones sobre la estrategia de front-end (Fiori), la integración de nuevos servicios basados en la nube, así como la consideración y evaluación general de las opciones de nube (IaaS, PaaS, SaaS).

Todos los procesos empresariales y desarrollos propios deben ponerse a prueba, incluidos los que antes funcionaban fuera de ECC. En el caso más sencillo, estos procesos empresariales y desarrollos propios simplemente se adaptan a las nuevas posibilidades.

Así, sin embargo, las nuevas oportunidades sólo se aprovechan de forma incompleta. Es mejor familiarizarse intensamente con las nuevas oportunidades y aprovecharlas de la mejor manera posible para los modelos de negocio existentes.

Sin embargo, estas tareas se conocen desde hace varios años: todo CIO o responsable de SAP habrá preparado las soluciones adecuadas y establecido la gestión del programa correspondiente. No hay que subestimar el esfuerzo que suponen. Están bien invertidos - y, según una regla empírica, pueden reducirse a la mitad con un socio experimentado.

Sin embargo, el principal problema suele ser el apoyo de los departamentos: Faltan usuarios clave, que carecen de tiempo y a menudo también de espacio libre disponible o concedido para "pensar de nuevo".

En algunos casos, esto lleva a que el CIO tenga que impulsar el cambio a S/4 Hana con sus clientes, los departamentos, y el proyecto se percibe como poco querido, por lo que tiende a alargarse.

La conversión a S/4 afecta directa e inmediatamente a dos áreas. En el área de FI/CO, la conversión obligatoria al nuevo libro mayor, la integración cliente-proveedor (CVI) y la fusión de FI y CO crean una considerable necesidad de actuación.

Hay que revisar los procesos empresariales establecidos, volver a probar las aplicaciones de terceros y crear informes a partir de la estructura de tablas modificada. Las mejoras se pueden experimentar, los beneficios se pueden notar... y, en consecuencia, hay que poner en marcha un proyecto de cambio.

S/4 más Ariba

En el ámbito de la logística también hay que gestionar cambios de peso. Aquí, sin embargo, el beneficio empresarial es más inmediato y, por tanto, es más fácil demostrar el retorno de la inversión. Un detalle interesante desde el punto de vista técnico es el uso del "pull" para obtener información de estado a corto plazo de sistemas de terceros, por ejemplo, la ubicación de las mercancías en el transporte.

Así, el "pull" sustituye al tradicional "push" y reduce la carga del sistema. Del mismo modo, la conexión integrada de Ariba como plataforma de aprovisionamiento reduce las interrupciones de medios y los procesos se diseñan de forma coherente en el universo SAP.

Sin embargo, es óptimo establecer procesos empresariales nuevos y completamente modificados que sean posibles debido a las nuevas circunstancias. Sin embargo, para ello es necesario conocer las posibilidades profesionales y técnicas, así como "pensar fuera de la caja".

Un socio con una visión imparcial acelerará enormemente este proceso en un primer momento y también lo renovará constantemente gracias a la visión externa. Cada cliente desarrollará y establecerá estos procesos empresariales renovados por sí mismo: es la única forma de obtener una ventaja sobre el competidor del mercado.

Todos estos cambios repercutirán en la cooperación entre el departamento especializado, TI y el socio externo. Para lograr la agilidad necesaria, se requerirán equipos interdisciplinares que también comprendan e, idealmente, también hablen el lenguaje técnico de los respectivos especialistas implicados.

Una división clásica en cliente y proveedor de servicios no es prometedora. Sólo con igualdad colegial y mucha iniciativa personal se hará realidad el cambio en un contexto orientado a objetivos.

Esto, anticipemos, seguirá siendo una receta de éxito para un enfoque ágil y creador de valor de las nuevas oportunidades incluso después del cambio. Así pues, este cambio es también un cambio en la organización, la cooperación de las distintas áreas y la percepción de las contribuciones empresariales.

Devoteam Alegri tiene un enfoque sencillo y mínimamente invasivo que utiliza la metodología S/4 Booster para demostrar los cambios y beneficios de S/4 a sus clientes en el menor tiempo posible. Y ello con los procesos, datos y flujos de trabajo del sistema ECC 6.0 existente, en un S/4 simplificado que está conectado al sistema del cliente.

Refuerzo S/4 e iHAL

De este modo, se pueden experimentar rápidamente las ventajas de S/4 y Hana, con los datos y procesos propios. Este S/4 puede, por ejemplo, proporcionarse desde la nube a corto plazo (ya se hace con Azure) y establecerse in situ si la evaluación es positiva.

El beneficio es que un departamento puede experimentar rápidamente la ventaja de S/4 con sus propios datos y procesos - y así apoyará esta transformación en términos de contenido y moral.

Otro ejemplo es la iHAL (intelligent Hana Assurance List), desarrollada por QPCM, socio de SAP: SAP Hana se está desarrollando rápidamente. Como ocurre con cualquier desarrollo de software, cada revisión también contiene errores, además de mejoras y nuevas funciones. Estos pueden afectar tanto a las revisiones antiguas como a las nuevas.

Los errores lógicos de software son graves porque no pueden ser detectados por ninguna solución de HA. Para minimizar los riesgos de errores de software durante el funcionamiento de Hana, las notas SAP necesarias deben comprobarse cíclicamente.

La comprobación de las referencias -adecuadas al propio escenario- puede llevar mucho tiempo. Con iHAL, QPCM ha creado una herramienta con la que estas comprobaciones pueden realizarse de forma rápida, eficaz y eficiente.

Nube, IaaS y gobernanza

Estos ejemplos muestran cómo la tecnología puede ayudar al cliente a pasar a S/4. Del mismo modo, el uso de la nube como IaaS es una forma probada de configurar pruebas, proyectos y sistemas de formación en horas y días en lugar de tener que lidiar con la adquisición de hardware in situ o del proveedor externo.

En la medida en que IaaS funcione en un modelo de pago por uso, los sistemas también pueden redimensionarse o desmantelarse en cuestión de horas. Como resultado, ya no hay riesgos de dimensionamiento. Lo que no encaja se hace encajar, con el tiempo de inactividad de un "boot through".

Este picking y desmantelamiento debe estar respaldado por los correspondientes procesos comerciales. De lo contrario, puede surgir rápidamente una proliferación de sistemas, con el consiguiente aumento de costes.

No se trata de un peligro teórico; las experiencias más variadas de los clientes hablan un lenguaje claro al respecto. Por supuesto, el uso de servicios en la nube debe estar respaldado por una gobernanza adecuada. Aquí, un socio con experiencia puede acortar considerablemente el tiempo de preparación para que la agilidad de la nube pueda utilizarse de forma rápida y sencilla.

La elección de un proveedor de nube para IaaS es -enfoque sistemático- uno de los anteproyectos más sencillos para la mayoría de los clientes: Debe contar con el soporte de SAP, cumplir los requisitos de conformidad y certificación, y las ubicaciones ofrecidas por el proveedor deben ajustarse a los requisitos y restricciones técnicas.

Un aspecto importante es la integración del proveedor de la nube en el entorno existente: a menudo ya se consumen servicios, por lo que aquí pueden aprovecharse los efectos sinérgicos.

Metodología y alcance del proceso

Es fácil ver que este cambio puede ser complejo y que los planteamientos tradicionales a menudo no bastan para obtener el máximo beneficio de la transición.

La fase de recopilación de información y el establecimiento del alcance son más complejos e incluso más importantes que en el cambio tradicional. Paralelamente, se requiere un enfoque ágil con determinación periódica de la ubicación y reajuste de la siguiente sección.

Devoteam Alegri ha diseñado un procedimiento basado en su experiencia y conocimientos técnicos. Se basa en las especificaciones de SAP y se ha completado con la experiencia de los consultores.

Tanto de los años de experiencia en licitaciones y funcionamiento en un entorno IaaS como de los proyectos greenfield y brownfield en S/4, se han creado ayudas y herramientas que reducen los tiempos de ejecución y los riesgos de los proyectos y minimizan los gastos para los clientes.

Administración de S/4 Hana

El desarrollo de una estrategia -incluidas las nuevas posibilidades de la nube, la arquitectura que incluye los sistemas Fiori- y la transformación propiamente dicha son una cosa. Después de una fase de hipercuidado, la operación posterior es otro tema que a menudo se considera (demasiado) tarde: con muchas conversiones, se organiza el apoyo para la configuración de los nuevos procesos, la conexión de la nube a la puesta en marcha del sistema S/4.

Pero, ¿cómo puede un cliente adaptar su actual organización administrativa a la nueva arquitectura y transformarla sin interrupciones? Tanto la base clásica de SAP como los equipos de aplicación tendrán que adaptarse a las nuevas estructuras, soluciones y tareas. Dos sencillos ejemplos lo ilustrarán:

Las tareas administrativas, como la supervisión o la seguridad, cambiarán. Las soluciones de supervisión actuales de SAP están adaptadas a los sistemas Abap y Java; por lo general, la supervisión global en las instalaciones y las soluciones en la nube solo pueden integrarse de forma indirecta. Lo mismo ocurre con la configuración de seguridad.

Si el departamento de TI de una empresa puede seguir garantizando la plena seguridad dentro de su propia red local, llega a sus límites cuando se integran soluciones en la nube. Aquí, al igual que con la supervisión, se necesitan nuevas formas para un uso y una supervisión cómodos y seguros.

2 En la actualidad, la asistencia y el desarrollo de aplicaciones se organizan sobre todo en función del sistema, ya que los procesos empresariales también tienen lugar dentro de un sistema. Esto cambiará en el futuro y los procesos se desarrollarán en todos los sistemas y en todo el mundo.

Así pues, tanto el desarrollo como el apoyo deben acumular los correspondientes conocimientos generales. Esto incluye también, por ejemplo, una gestión del cambio adaptada, ya que en el futuro los cambios tendrán que organizarse de forma coherente en muchos más sistemas y mundos de sistemas.

También habrá que establecer nuevas estructuras organizativas, ya que los equipos administrativos y técnicos trabajarán mucho más estrechamente.

La transformación del soporte clásico del sistema SAP al moderno soporte híbrido de procesos y servicios en torno al núcleo digital en forma del sistema S/4 con la integración de diversas estructuras y aplicaciones en la nube es compleja. Requiere expertos experimentados que ya hayan realizado con éxito conversiones analógicas y conozcan ya las ventajas, así como los riesgos, de las posibles estructuras.

Ni siquiera es necesario hablar de la inclusión de IoT, inteligencia artificial o blockchain; basta con echar un simple vistazo al trasvase de funcionalidades SAP a soluciones en la nube (WebIDE, funcionalidades SCM, cabinas de monitorización, integración de interfaces y datos...).

Conclusión

No hay alternativa al cambio a S/4, que debe completarse antes de 2025 y no debe subestimarse. Los beneficios potenciales del cambio justifican el esfuerzo con una planificación cuidadosa. Del mismo modo, S/4 y Hana son el requisito previo para una integración perfecta de las soluciones de la cartera de SAP, ya sea Ariba o incluso la conexión a través de SCP.

El procesamiento de datos IoT también se simplifica y se hace efectivo de forma inmediata mediante el uso de S/4. El cliente puede influir en la velocidad y el nivel de calidad del panorama futuro, pero para ello necesita tiempo y conocimientos especializados, dos recursos que hoy en día ya son limitados.

Una percepción como "cambio de versión" no hace justicia ni al proyecto ni a su impacto y es una subestimación groseramente negligente. Del mismo modo, retrasar el proyecto es inadecuado porque la escasez de consultores experimentados para el número de proyectos aumentará de forma flagrante con el tiempo.

La esperanza de que SAP amplíe el plazo de 2025 es comprensible, pero no puede ser la base para actuar. Del mismo modo, es muy probable que SAP haga que permanecer en ECC 6.0 sea cada vez menos atractivo económicamente, además de las ventajas ya claramente visibles de cambiar a S/4.

Dado que SAP tiene un gran interés en acelerar el ritmo de cambio a S/4 y Hana, esta es la única forma de colocar más productos y licencias entre los clientes. Un socio como la alianza de Devoteam Alegri y QPCM - neutral, sin intereses propios en licencias y con gran experiencia - con años de experiencia práctica puede marcar la diferencia en este caso.

Un inventario de la situación actual, un asesoramiento sobre el espacio actual de soluciones y, a continuación, un plan maestro: este cambio ya es gestionable y también puede explicarse a las propias partes interesadas de forma orientada.