Plateforme technologique d'entreprise

En outre, la Business Technology Platform, BTP, offre de nouvelles possibilités qui n'existent pas dans le système sur site. Les entreprises doivent toutefois planifier stratégiquement si et comment elles veulent utiliser la plate-forme. Les objectifs que les entreprises veulent atteindre en migrant leurs systèmes ERP vers S/4 sont multiples : des processus allégés, la possibilité d'innover davantage et d'être plus réactif face aux changements, de meilleures possibilités d'optimisation ainsi que de nouveaux scénarios d'intégration étendus avec les clients et les fournisseurs, et bien d'autres encore. Souvent, le passage à S/4 doit aussi permettre de rapprocher son propre paysage SAP du standard SAP, de sorte que les futures mises à niveau et les changements de version puissent être effectués plus facilement et plus rapidement. 

Certaines entreprises ont la possibilité de réduire leurs propres développements et peut-être même leurs modifications de systèmes. En effet, il semble que ce soit une bonne occasion de se débarrasser des anciens développements individuels et des modifications, parfois obsolètes et inutiles, lors d'un saut logiciel aussi important. Cela vaut en particulier pour les introductions "greenfield", lors desquelles la mise en place du nouveau système S/4 Hana commence métaphoriquement sur un terrain vierge, c'est-à-dire qu'il ne s'agit pas d'une simple mise à niveau technique (conversion brownfield) du système ERP actuel vers S/4.

D'autres entreprises ont toutefois besoin de nombreux développements et modifications internes, même après le passage à S/4. Les transférer dans le nouveau système est une idée évidente. Mais tout resterait comme avant et le standard SAP resterait lointain. Pour eux, la BTP peut être une solution.

Avec la BTP, connue jusqu'à l'automne 2020 sous le nom de SCP, SAP Cloud Platform, SAP propose une plateforme cloud qui, outre de nombreuses autres fonctions, met à disposition de nombreux modules et services pour des projets de développement, d'extension et d'intégration. Il en résulte de nouvelles manières de poursuivre l'approche "Keep the Core clean" - c'est-à-dire de maintenir ses propres systèmes SAP aussi proches que possible du standard. En effet, les développements qui, jusqu'à présent, n'étaient pas possibles faute d'alternatives au sein de l'environnement SAP, sont désormais possibles.
Les clients existants peuvent à la place mettre en œuvre et exécuter les systèmes sur site dans la BTP.

Ainsi, outre un développement rapide grâce à de nombreux services et bonnes pratiques, un couplage lâche entre les extensions propres et le standard SAP est possible. Cela soutient l'objectif déjà mentionné de pouvoir effectuer plus facilement et plus rapidement les futures mises à niveau et les changements de version. Mais quand l'utilisation de la BTP est-elle judicieuse et comment les entreprises doivent-elles procéder lors de la mise en œuvre ?

Pouvoir mettre en œuvre des extensions sur la BTP, utiliser des services commerciaux proposés par la BTP ou intégrer des partenaires ou des systèmes par la BTP ouvre de nombreuses possibilités : Si l'on se concentre sur les développements dans le BTP, il est toutefois nécessaire, malgré tous les avantages, de procéder à des évaluations fondamentales. En effet, toutes les entreprises ne miseront pas entièrement sur S/4 Hana Cloud (public) et ne développeront donc pas exclusivement via la BTP. En outre, il existera toujours des systèmes S/4 sur site. Pour prendre une décision qualifiée, les critères suivants sont pertinents : Coûts, infrastructure et intégration.

Coûts d'entrée à la BTP

Les coûts se répartissent en trois domaines : Coûts de développement, coûts d'exploitation, frais de cloud. En particulier lors des premiers essais, un développement sur la BTP entraînera dans un premier temps plutôt plus de dépenses, car les développeurs évoluent la plupart du temps en terrain inconnu. Il est alors essentiel de créer une courbe d'apprentissage rapide grâce à des mesures de formation appropriées et à une composition habile de l'équipe. Les développements futurs en profiteront et tous les développeurs sauront apprécier les accélérateurs connus de SAP. 

Les coûts d'exploitation internes d'une application BTP peuvent être considérés comme moindres, étant donné que la plateforme est entièrement fournie en tant que service. En contrepartie, l'utilisation des services entraîne des frais. Un outil Estimator peut très bien les prévoir. Ensuite, il faut encore trouver un savant mélange d'abonnement, de paiement à l'utilisation et de CPEA (Cloud Platform Enterprise Agreement) pour optimiser les coûts.

En revanche, les coûts économisés lors des futures mises à jour du système sur site sont importants. Tout développement individuel qui n'y est pas présent peut alors ne pas entraîner de dépenses. D'autres avantages en termes de coûts, par exemple dans le cas de processus de bout en bout avec des partenaires externes impliqués, peuvent également apparaître selon le cas d'application.

Une infrastructure plus légère

Les applications utilisées en externe profitent particulièrement d'une représentation sur la BTP. Dans ce cas, les questions de l'accès sécurisé à l'application, de la connexion aux systèmes sur site et de la connexion des données sont déjà résolues par les services correspondants. Pour les applications qui traitent une grande quantité de données provenant de systèmes sur site, les entreprises doivent prendre des décisions architecturales judicieuses. Il existe divers moyens de répliquer de grandes quantités de données - même en temps quasi-réel - dans la BTP. Mais cela doit être bien pensé pour parvenir réellement à un couplage lâche et ne pas faire passer les données dans un autre silo.

Les services disponibles peuvent rendre certains cas d'utilisation possibles et en accélérer considérablement d'autres. Ainsi, les possibilités d'utiliser des modèles d'IA pour faire des prévisions ne sont possibles dans les systèmes sur site qu'avec une version récente de S/4. Grâce à la BTP, ils peuvent également être utilisés pour des systèmes ERP plus anciens. Un autre exemple est le développement d'un chat bot, pour lequel la BTP apporte un service à développer en conséquence.

Efficacité de l'intégration

Enfin, il faut considérer l'ensemble du processus et l'architecture globale. Si une nouvelle application doit raisonnablement faire appel à de nombreuses fonctions existantes dans le système SAP sur site (modules fonctionnels, classes et méthodes, etc.), cela plaide peut-être davantage en faveur d'une mise en œuvre dans le système sur site que dans la BTP. Il en va de même si la nouvelle fonction n'est qu'un petit module dans un traitement de masse dans le système on-prem. Un "ping" (appel de fonction) constant du système sur site vers la BTP, répété pour plusieurs milliers d'enregistrements, ne devrait pas non plus constituer une solution particulièrement performante. Toutes ces considérations sont utiles et nécessaires pour une décision bien réfléchie. L'évaluation peut également être conservée dans des arbres de décision ou des documents de stratégie pour les cas suivants, de sorte qu'une certaine routine s'installe lors de la décision de développer sur site ou dans la BTP dans un cas particulier. Si la balance penche en faveur du BTP, il faut d'abord réfléchir à la bonne architecture au sein du BTP ainsi qu'à la structure du cloud ou à l'architecture globale avant d'entamer les premières activités de développement.

Cloud Foundry, Kyma, Abap 

Outre les critères qui distinguent généralement un développement sur la BTP d'un développement sur site, les entreprises doivent également trouver l'architecture qui leur convient au sein de la BTP. Trois environnements sont disponibles à cet effet : Cloud Foundry, Kyma et Abap. Ce choix dépend des exigences à mettre en œuvre et des compétences disponibles des architectes et des développeurs. Cloud Foundry permet par exemple de mettre à disposition des applications Fiori en interne et en externe de manière très légère et en peu de temps. L'environnement Abap dans la BTP est relativement lourd et impose entre autres une BD Hana dédiée dans le cloud. En revanche, il offre la possibilité de travailler dans le langage de programmation bien connu de SAP et de mettre en œuvre une intégration très étroite avec les fonctions sur site. Dans l'environnement Kyma, des applications conteneurisées peuvent être développées et utilisées. Tous les environnements ont en commun une bonne intégration dans l'environnement SAP.

SAP met un Global Account à la disposition de chaque client qui a opté pour le BTP. Celui-ci forme une parenthèse autour de ce que l'on appelle les sous-comptes, en tant que domaines fermés, par exemple pour séparer des projets ou des étapes. Les sous-comptes sont l'élément structurel le plus important au sein du BTP, car ils contiennent des paramètres définis une fois pour toutes lors de leur création. Un Global Account peut contenir un ou plusieurs sous-comptes, pour lesquels on définit individuellement dans quelle région géographique, par exemple l'Amérique du Nord, l'Europe de l'Ouest ou d'autres, et chez quel fournisseur d'infrastructure le sous-compte est physiquement implémenté.

Actuellement, il s'agit de : AWS, Microsoft Azure, Google Cloud Platform, Alibaba Cloud et l'infrastructure cloud de SAP. SAP laisse certes au client le choix de l'hypercalculateur, mais la relation contractuelle se fait exclusivement avec SAP. En outre, les entreprises doivent déterminer si elles souhaitent utiliser le sous-compte pour des développements dans le standard Cloud-Foundry, pour des architectures de microservices conteneurisés basés sur Kyma ou pour des développements Abap.

Il est conseillé de concevoir un modèle de sous-compte dès le début de l'utilisation de la BTP, afin de permettre des effets de synergie et de pouvoir réutiliser les services et les données. Il va de soi qu'une structure ordonnée, transparente et compréhensible est absolument nécessaire pour les plates-formes en expansion. Il convient d'examiner quelles applications similaires peuvent éventuellement partager un sous-compte (par étape) et avec quelle rigueur la séparation doit être effectuée. Certaines applications ne peuvent pas, ou pas facilement, "voir" et utiliser les ressources telles que les services ou les données d'un autre sous-compte. Les questions suivantes jouent donc un rôle central dans le choix du modèle de sous-compte approprié :

Un environnement de développement échelonné - Dev, Cons, Prod - est-il nécessaire dans la BTP ? Les données doivent-elles être stockées de manière centralisée dans un seul compte ou réparties dans plusieurs sous-comptes dans la BTP ?

Les applications qui utilisent des architectures comparables - CF, Kyma, Abap - doivent-elles toutes fonctionner dans un seul sous-compte, dans le moins de sous-comptes possible ou dans un sous-compte séparé ? Les interfaces ou les API doivent-elles être conservées dans un compte central ou dans chaque sous-compte individuel ? 

Est-il nécessaire, pour des raisons organisationnelles (par exemple, protection de l'accès), de séparer certaines applications et/ou données des autres via des sous-comptes dédiés ?

Sécurité

Ensuite, le modèle de sécurité doit être défini en accord avec le modèle de sous-compte. Les aspects relatifs à l'authentification et à l'autorisation des utilisateurs sont ici particulièrement importants.

Lors du développement d'une application, il faut alors considérer quelles couches (interface utilisateur, logique commerciale, persistance) sont concernées ou mises en œuvre sur la BTP. Plus l'entreprise reproduit de couches sur la BTP, plus le choix du modèle de programmation est important. Pour une application UI5 qui utilise des données d'un système SAP sur site, cette décision est très simple. Pour une application plus complexe, qui peut nécessiter de nombreuses données, les exigences en matière de modèle de programmation augmentent également. Pour le choix du langage et des outils de programmation, on a le choix entre les trois approches mentionnées précédemment : Cloud Foundry, Kyma et Abap.

Alors que les environnements Cloud-Foundry et Kyma permettent d'utiliser divers langages de programmation, tels que Java, Node.js ou Python, les environnements Abap dans le BTP sont naturellement prévus pour le développement de code Abap. Faire le bon choix dépend donc de plusieurs facteurs. Il faut tenir compte des possibilités techniques des différentes plates-formes ainsi que des connaissances techniques disponibles dans l'organisation, par exemple celles des développeurs.

Ainsi, alors que les développeurs SAP classiques se retrouveront encore le plus souvent dans des environnements Abap dans le BTP, des approches techniques sont désormais disponibles avec Cloud Foundry et Kyma, qui permettent aux "développeurs non SAP" de construire des applications dans le contexte SAP.

Dans les deux cas, les responsables devraient prévoir des activités de formation supplémentaires afin de maîtriser les nouveautés techniques de la plateforme cloud. De solides connaissances sur OData, SAPUI5, Fiori Elements, Abap CDS et, de manière générale, une bonne compréhension du modèle Abap RESTful Application Programming Model sont indispensables pour la création de développements fullstack (avec le modèle RAP). 

Dans le cas de développements cloud foundry, les collaborateurs chargés du BTP doivent apprendre à utiliser OData, SAPUI5 et, le cas échéant, Fiori Elements pour le développement d'applications Fiori. En outre, pour les applications fullstack, SQLscript, Node.js et bien sûr le modèle CAP sont également pertinents. Pour de nombreux développeurs d'aujourd'hui, il s'agit d'une formation exigeante, mais aussi intéressante et orientée vers l'avenir.

Il est bien connu que le développement et l'exploitation d'applications basées sur le cloud posent également des exigences particulières en matière de sécurité, de protection des accès et d'exploitation technique. La Busi-ness Technology Platform ne fait pas exception à la règle. Comme pour les applications au sein du réseau de l'entreprise, qui se trouvent derrière le pare-feu de l'entreprise, les applications dans la BTP doivent également être sécurisées au moyen de mécanismes d'authentification et d'autorisation. Si des erreurs se produisent, le risque de dommages dans le cloud est naturellement beaucoup plus élevé. La sécurisation de toutes les applications tout au long de leur cycle de vie doit donc jouer un rôle central, en veillant à ce que toutes les personnes concernées respectent et assimilent impérativement les concepts et les directives.

L'utilisation de Platform as a Service comme base pour les applications d'entreprise ouvre également de nouvelles perspectives aux entreprises en termes d'exploitation. La mise en place d'une nouvelle "infrastructure" dans le cloud se fait en appuyant sur un bouton, un nouveau sous-compte est constitué en quelques minutes et est disponible en état de fonctionnement. La stabilité technique du "matériel" et des services de base du cloud (bord supérieur du système d'exploitation) est également prise en charge par le fournisseur de cloud - dans le cas de la BTP, il s'agit donc de l'exploitant d'infrastructure respectif comme Microsoft, Amazon, Google ou d'autres, mentionnés ci-dessus - et bien sûr par SAP lui-même.

D'autre part, on renonce aussi à certaines habitudes devenues évidentes, comme par exemple la possibilité de pouvoir définir librement et de manière autonome les cycles de release de toutes les piles logicielles, même "en dessous" de la couche d'application. Dans la BTP (comme probablement dans pratiquement tous les autres environnements de cloud computing), ceci est normalement défini de manière centrale par SAP et assure une base toujours actuelle pour les propres applications.

Conclusion

Outre les avantages attendus au niveau de l'exploitation, un développement plus rapide et une très bonne intégration dans l'univers SAP, la BTP en tant qu'environnement de développement est même parfois la seule possibilité de réaliser ses propres extensions lors de l'utilisation d'applications SAP SaaS. SAP met à la disposition des développeurs, comme nous y sommes habitués de la part de l'entreprise, de nombreux outils pour faciliter le quotidien et accélérer le processus de développement.

Mais au-delà du développement d'applications, la BTP est aussi la plateforme stratégique pour les utilisateurs de SAP. Un petit exemple est un service pour la mise à disposition de taux de change même sans S/4 déjà dans le système ERP. Mais d'autres services commerciaux comme une intégration centrale des données de base ou la X-facture se trouvent également dans l'offre clé en main.

Enfin, la Business Technology Platform offre aux entreprises des opportunités et des possibilités jusqu'alors inexistantes pour la mise en place de processus commerciaux entièrement nouveaux. Grâce à l'ouverture organisationnelle et informatique des applications BTP et aux nombreux outils d'intégration disponibles dans SAP BTP, il est désormais possible de mettre en œuvre des scénarios beaucoup plus facilement et rapidement. Les fournisseurs, les clients et les autres partenaires peuvent ainsi être reliés étroitement à leurs propres données et processus, de sorte qu'il existe de véritables processus de bout en bout. 

Les services intelligents (services IA) en constante augmentation dans la BTP, que les entreprises peuvent parfaitement relier et combiner avec leurs propres applications, aident à créer de la valeur à partir des données. Si elle est mise en œuvre et utilisée de manière cohérente, la BTP de SAP aide ainsi à se préparer aux défis actuels et futurs et à s'adapter avec agilité aux changements de la situation du marché.