El sufrimiento de los desarrollos propios

En la versión R/2, pero sobre todo en R/3, los desarrollos propios de los clientes seguían formando parte de la estrategia de SAP y desempeñaban un papel importante en la historia de éxitos. SAP proporcionaba a los clientes las soluciones necesarias como soluciones estándar en forma de módulos. Todos los módulos estaban, por un lado, encapsulados en sí mismos, pero, por otro, totalmente integrados entre sí cuando se utilizaban módulos adicionales. Una parte satisfactoria de la estrategia fue también la posibilidad de adaptar las soluciones estándar modulares mediante modificaciones en caso necesario. Además, la mayor ventaja para los clientes fue poder complementar las soluciones estándar con sus propios desarrollos de requisitos específicos del cliente. ¡Un concepto realmente genial para los clientes! Esta combinación e integración también llevó a SAP a su posición de liderazgo en el mercado.

Apoyo sobrecargado

Sin embargo, debido al crecimiento global de clientes, SAP puede haber tenido problemas con esto. El mantenimiento continuo y la provisión de las modificaciones, así como garantizar la integración de los numerosos desarrollos propios específicos de los clientes, probablemente desbordaron el soporte. Parece razonable suponer que el problema debería resolverse con S/4 ajustando la estrategia. Las nuevas plataformas de aplicaciones cloud, public cloud y private cloud debían sustituir a las anteriores variantes on-prem. De este modo, los clientes de SAP se vieron sometidos a la presión de la estrategia "sólo en la nube", ampliamente difundida. Lo único es que muchos clientes, especialmente los existentes, tenían un gran problema con esto - hasta que DSAG vino al rescate.

SAP cambió su estrategia S/4 de cloud only a cloud first, pero esto no resolvió los problemas de los clientes. Como soluciones estándar, las soluciones en la nube y la nube pública ya no permiten ninguna adaptación específica del cliente. Para ello sólo queda la nube privada, que, sin embargo, también representa una externalización limitada desde el punto de vista de la arquitectura del sistema. Debido a esta situación, la mayoría de los clientes actuales siguen el camino de los entornos de sistemas híbridos con la variante on-prem existente, complementada con soluciones en la nube. Con este enfoque, sin embargo, se encuentran con el problema de la integración que a menudo sigue faltando.

Además de los retos que plantean las modificaciones limitadas, la incorporación de los numerosos desarrollos internos a la transformación de S/4 supone una tarea y un esfuerzo enormes. Esto comienza con la selección de los desarrollos adicionales en función de lo que sigue siendo necesario y lo que no. Sobre todo, muchos informes dejan de utilizarse cuando los usuarios se marchan. Sacar" los desarrollos internos es una buena acción, porque también puede reducir los costes operativos. Al mismo tiempo, hay que examinar detenidamente qué desarrollos internos pueden sustituirse total o parcialmente por las nuevas aplicaciones S/4.

Este análisis de las diferencias de ajuste es uno de los puntos centrales de todo proyecto de transformación de S/4. El resultado también muestra qué desarrollos internos existentes deben modificarse y dónde son necesarios nuevos desarrollos internos. Las razones para ello son los cambios en los procesos o la alineación funcional con las nuevas aplicaciones S/4. En muchos proyectos también se da prioridad a la implantación por razones de tiempo y coste.

En cualquier caso, durante la conversión a S/4 debe comprobarse la funcionalidad técnica de todos los desarrollos propios. Las razones para ello son los cambios masivos en los registros de datos existentes debido a la simplificación, así como los cambios tecnológicos en la programación. SAP ofrece muy buenos servicios y herramientas para ello. Un buen consejo basado en mi propia experiencia y en la de muchos proyectos es que nunca se empieza lo suficientemente pronto.