La souffrance des développements propres

Sous la version R/2, mais surtout sous R/3, les développements internes des clients faisaient encore partie de la stratégie de SAP et ont joué un rôle important dans l'histoire de son succès. SAP mettait à la disposition des clients les solutions nécessaires sous forme de modules standard. Tous les modules étaient d'une part encapsulés en eux-mêmes, mais d'autre part totalement intégrés entre eux lors de l'utilisation d'autres modules. La possibilité d'adapter les solutions modulaires standard par des modifications en cas de besoin constituait également un élément de réussite de la stratégie. En outre, le plus grand avantage pour les clients a été de pouvoir compléter les solutions standard par des développements propres répondant aux exigences spécifiques des clients. Un concept vraiment génial pour les clients ! Cette combinaison et cette intégration ont également permis à SAP d'occuper une position de leader sur le marché.

Une assistance dépassée

En raison de la croissance globale de la clientèle, SAP a peut-être rencontré un problème. La maintenance continue et la mise à disposition des modifications ainsi que la garantie de l'intégration des nombreux développements propres aux clients ont probablement surchargé le support. On peut supposer qu'avec S/4, le problème devait être résolu par une adaptation de la stratégie. Les nouvelles plates-formes d'application Cloud, Public Cloud et Private Cloud devaient remplacer les anciennes variantes sur site. C'est ainsi que les clients de SAP ont été mis sous pression par la stratégie cloud-only largement communiquée. Seulement, de nombreux clients, surtout les clients existants, ont eu un gros problème avec cela - jusqu'à ce que la DSAG vienne à leur secours.

Ainsi, SAP a certes modifié sa stratégie S/4 en passant de Cloud only à Cloud first, mais cela n'a pas résolu les problèmes des clients. Les solutions cloud et le cloud public, en tant que solutions standard, ne permettent en fait plus aucune adaptation spécifique au client. Il ne reste plus que le cloud privé pour cela, qui ne représente toutefois qu'une externalisation limitée du point de vue de l'architecture du système. En raison de cette situation, la plupart des clients existants choisissent la voie des environnements système hybrides avec la variante sur site existante, complétée par des solutions en nuage. Avec cette approche, ils se heurtent toutefois au problème de l'intégration qui fait encore souvent défaut.

Outre les défis posés par les modifications limitées, le fait d'emmener les nombreux développements internes dans la transformation S/4 représente une tâche énorme et un effort considérable. Cela commence par la sélection des développements supplémentaires en fonction de ce qui est encore nécessaire et de ce qui ne l'est pas. En particulier, de nombreux rapports ne sont plus utilisés après le départ des utilisateurs. Faire le "ménage" dans les développements propres est une bonne action, car cela permet également de réduire les charges d'exploitation. Parallèlement, il convient d'examiner attentivement quels développements internes peuvent être remplacés, en tout ou en partie, par les nouvelles applications S/4.

De préférence tout de suite

Cette analyse du fit gap est l'un des points forts de tout projet de transformation S/4. Le résultat montre également quels développements internes existants doivent être modifiés et où de nouveaux développements internes sont nécessaires. Cela peut être dû à des modifications des processus ou à la synchronisation des fonctions avec les nouvelles applications S/4. Dans de nombreux projets, des priorités sont également fixées pour la mise en œuvre, pour des raisons de temps et de coûts. En tout état de cause, la fonctionnalité technique de tous les développements internes doit être vérifiée lors du passage à S/4. Cela s'explique par les modifications massives apportées aux jeux de données existants par la simplification et par les changements technologiques dans la programmation. SAP met à disposition de très bons services et outils à cet effet. Un bon conseil, tiré de ma propre expérience et de nombreux projets, est que l'on ne commence jamais assez tôt.