Integración de sistemas como punto central de S/4
El ambiente actual es política, social y económicamente difícil. Sin embargo, esto sólo tiene que ver marginalmente con el mal humor en torno al SAP, como puede deducirse de diversos medios de comunicación. Pero el tema de la integración es probablemente parte de ello. ¿Cuáles son los antecedentes y contextos de esto?
Como ya se ha mencionado en la introducción, la estrategia empresarial de SAP para el necesario crecimiento de la empresa se caracterizó principalmente por las adquisiciones de numerosos proveedores de nube bajo el mandato del anterior jefe, Bill McDermott. De este modo, también logró sus principales objetivos: por un lado, la evolución positiva de SAP en el mercado de capitales de la bolsa y, por otro, la optimización de sus ingresos personales. Desde la perspectiva actual, sin embargo, esto fue demasiado miope. Algunas de las adquisiciones fueron malas inversiones y se echó en falta la integración técnica necesaria en la plataforma SAP para las aplicaciones estratégicamente correctas. Esto repercutió negativamente en las estrategias S/4 "cloud only" o "cloud first".
El éxito de la transformación de S/4 para los clientes está directamente relacionado con la integración, que sencillamente no existía en la forma habitual. SAP no fue consciente de esta indeseable evolución hasta que Christian Klein asumió la dirección del grupo. La necesaria integración de los productos en la nube se convirtió así en la tarea principal, lo que costó demasiado tiempo y dinero, y sigue costando. Esta importante pero tardía toma de conciencia también ha tenido un impacto muy negativo en el mercado de capitales. El tema de la integración simplemente no puede venderse como una gran visión. Con "limpieza sin visiones", Christian Klein se encuentra actualmente bajo bastante presión.
Tras los antecedentes, sin embargo, también hay algunos consejos prácticos para los numerosos proyectos de transformación en curso en lo que respecta a la integración. Para la mayoría de los clientes existentes, los proyectos S/4 se implementan con un entorno de aplicaciones híbrido, es decir, en sistemas on-premise con soluciones en la nube. La atención se centra aquí en las numerosas soluciones propias de SAP en la nube con la nueva tecnología S/4. Aquí no se trata de la integración, sino de la disponibilidad puntual de las funciones necesarias según las hojas de ruta en coordinación con el plan del proyecto.
Los problemas de integración mencionados se deben principalmente a las grandes adquisiciones como Ariba, Fieldglass, Concur y SuccessFactors. Aunque éstas tendrían sentido desde el punto de vista empresarial, cuentan con tecnologías de desarrollo diferentes. Esto hace que la integración funcional en los sistemas centrales de SAP sea una tarea colosal. De todos modos, la interfaz uniforme sigue siendo una quimera, a pesar de los sinceros esfuerzos de SAP. A la hora de introducir estas soluciones, conviene hacer previamente un inventario actualizado. Por un lado, naturalmente, con SAP directamente, pero por otro, para garantizar la calidad, también con los correspondientes clientes de referencia y los grupos de trabajo del DSAG.
Otro tema de integración extenso pero infravalorado son los desarrollos internos. Aquí hay varias cuestiones que tratar. Para empezar, hay que comprobar si todos los desarrollos internos, como informes y programas, son necesarios. Después de todo, muchos ya no se utilizan tras cambios en el sistema o en el personal. SAP Operations dispone de las herramientas de análisis adecuadas para ello. Los desarrollos internos necesarios deben convertirse a la nueva tecnología S/4 a su debido tiempo. Esta fase puede y debe iniciarse antes del comienzo del proyecto S/4, ya que la conversión implica mucho tiempo.
En un paso posterior, debe llevarse a cabo un análisis de adecuación para examinar qué desarrollos internos pueden sustituirse por las nuevas aplicaciones S/4 estándar. Por último, debe garantizarse la integración técnica de los desarrollos internos en las soluciones en la nube.
