Que faire des développements internes sous SAP ?
![[shutterstock.com : 379587700, Brian A Jackson]](https://e3mag.com/wp-content/uploads/2020/03/shutterstock_379587700.jpg)

De nombreux responsables SAP se demandent actuellement où et sous quelle forme les développements internes et les extensions individuelles devraient être mis en œuvre de manière judicieuse.
Autrefois, avant l'apparition des applications en nuage, les adaptations et les compléments étaient en principe programmés dans le système central (espace de noms Z avec modifications Abap), on s'accommodait pour cela de la charge de travail élevée lors de la mise à niveau et souvent aussi de pertes de performance. Mais depuis quelques années, la maxime de l'entreprise de Walldorf est : "Keep the core clean".
L'application de base, S/4, doit rester libre de tout code personnalisé. Les développements propres doivent être mis en œuvre dans des scénarios côte à côte. Des plates-formes telles que SAP Cloud Platform (SCP), qui permettent une programmation rapide et agile ainsi que l'intégration d'applications et de microservices, se prêtent à cet effet.
Les mises à jour des systèmes centraux, qui sont désormais beaucoup plus fréquentes, se déroulent ainsi rapidement et sans problème. Mais toutes les adaptations et tous les compléments doivent-ils vraiment être développés en dehors du système central ?
S'il s'agit par exemple de réduire le nombre de champs de formulaire affichés pour un groupe d'utilisateurs donné, une extension dans le cloud est-elle nécessaire ?
En fait, la programmation en dehors du système central n'est pas la meilleure solution dans tous les cas. Les questions fondamentales portent sur le groupe d'utilisateurs, les données à intégrer, les scénarios d'utilisation et la durée d'utilisation.
Si les collaborateurs doivent être nouvellement formés à SAP, il convient de peser le pour et le contre. Si l'on s'adresse à des groupes d'utilisateurs externes, comme des partenaires ou des personnes intéressées, qui n'utiliseront peut-être que quelques fonctions en mobilité, l'utilisation d'une interface utilisateur simple et intuitive est prioritaire. Cela plaide en faveur d'un développement sur la plateforme cloud.

En cas de comparaison et d'accès permanents aux données de l'application principale, il est recommandé de procéder à des adaptations directement dans le système principal. Cela vaut également dans les cas où il est très important d'avoir son propre contrôle sur les données.
En revanche, les développements internes sur la plateforme sont la solution de choix lorsque les données du système central sont utilisées principalement en lecture seule via des interfaces ou lorsque les données sont disponibles de manière redondante et que des comparaisons occasionnelles des données suffisent.
La question de la fonction et du scénario d'utilisation respectif est étroitement liée aux exigences d'intégration : si l'extension est utilisée exclusivement - et avec la même intensité - dans le système SAP on-premises, sans que des services externes supplémentaires soient intégrés, les extensions devraient également être effectuées directement dans le système.
Enfin, la durée d'utilisation joue également un rôle : si l'application ou l'extension à créer n'est utilisée que temporairement, par exemple pour des actions saisonnières dans le commerce ou à des fins de test, elle ne doit pas surcharger le système propre.
Pour les tests et le prototypage, la plateforme cloud offre, avec ses outils et ses apps, un environnement optimal pour des développements flexibles et agiles. En revanche, il est préférable d'utiliser le système on-premises pour un développement interne mûr qui doit fonctionner à long terme et de manière stable avec le système principal.



