Le temps des phares est révolu

Dans le cadre d'un job d'étudiant en 1998, j'ai posé la question naïve à l'administrateur de la base SAP de savoir comment je pouvais accéder à ce SAP à partir de mon application Visual Basic.

À l'époque, les utilisateurs devaient copier-coller les données des articles de l'interface utilisateur graphique SAP vers l'application de stockage externe. Sans dire un mot, il m'a mis dans les mains un livre gris à couverture souple imprimée :

"Mastering SAP Remote Function Call in C/C++". Rétrospectivement, c'était probablement sa façon de dire : laisse tomber.

Près de 20 ans se sont écoulés depuis et beaucoup d'eau a coulé le long du Leimbach en passant devant le siège de SAP à Walldorf. Les questions relatives aux avantages commerciaux et à la bonne approche technique sont toujours d'actualité.

Intégration des données et des processus

Lorsqu'il s'agit d'interfaces SAP, nous distinguons en principe deux grands domaines : L'intégration des données et l'intégration des processus.

L'intégration de données concerne généralement le transport de grandes quantités de données structurées. Le sens et le but sont à voir dans les domaines autour de l'analyse des données.

Cela peut aller de simples graphiques pour la direction jusqu'à l'analyse prédictive et l'exploration de données à l'aide de l'intelligence artificielle. Dans tous les cas, ce domaine se situe en aval des opérations commerciales classiques, qui sont généralement couvertes par SAP ERP.

Si l'on restait complètement dans le monde SAP, on couvrirait les besoins en analyse de données de manière classique avec BW, Hana et les outils frontaux BO.

Le deuxième grand domaine est l'intégration des processus. Ici, le transfert de données s'effectue au niveau de la transaction individuelle. Un processus peut commencer dans SAP et être transféré à un sous-système.

Un bel exemple serait une offre client créée dans SAP SD, mais qui serait ensuite enrichie de données supplémentaires, d'images et de dessins en dehors de SAP.

L'inverse est également envisageable. Un workflow non-SAP permet de collecter des informations sur un nouvel enregistrement de la base de données articles auprès de différents services. Les services concernés sont la gestion des produits, les achats et, le cas échéant, des collègues de la logistique.

Ce n'est que lorsque toutes les informations sont complètes et cohérentes que les données et le processus de placement sont transmis à SAP MM. Pratiquement toutes les interfaces SAP peuvent être classées dans ces deux catégories d'intégration de processus et de données, chacune d'entre elles étant complètement différente sur le plan technique.

Interfaces de rupture

Avant d'examiner les aspects techniques, il convient de se poser la question du pourquoi. Avec sa palette de produits et de modules quasiment incommensurable, SAP pénètre théoriquement toutes les exigences de presque tous les clients existants de SAP.

Chaque interface entre les systèmes ou les fabricants est souvent considérée comme une sorte de point de rupture qui devient particulièrement gênant lorsqu'il ne fonctionne pas. Et en règle générale, c'est bien sûr la faute de l'autre partie. Et pourtant, il y a des arguments qui font taire ces inquiétudes.

Un souhait souvent entendu de la part des utilisateurs est l'appel à de meilleures performances. Je tiens à m'opposer expressément au reproche général selon lequel SAP est lent, mais il n'en reste pas moins que, depuis la création de l'entreprise, la société de Walldorf a presque pour tradition de concevoir ses logiciels de manière à ce que le matériel disponible soit toujours un peu trop lent pour les applications.

Pendant longtemps, cela a surtout été le cas pour SAP BW. L'utilisation de Hana a certainement relativisé les choses, mais il n'en reste pas moins que c'est justement le domaine de l'analyse des données qui mettait à l'épreuve la patience de l'utilisateur jusqu'à la limite de la douleur, voire au-delà.

Il est donc logique que de nombreux clients SAP existants trouvent dans les sous-systèmes externes un bien meilleur rapport coût/performance.

Un autre argument important est la fusion avec des données non-SAP, que ce soit dans l'intégration de données ou de processus. Conserver des données d'entreprise entièrement dans le logiciel d'un fabricant ne fonctionne que dans les brochures sur papier glacé, mais jamais dans la vie réelle.

Et oui, bien sûr, SAP ERP et SAP BW offrent la possibilité de charger des données externes dans SAP et de les y traiter, mais ce n'est en aucun cas une méthode réaliste et abordable.

Ceux qui ont besoin de données SAP et non-SAP en même temps devront trouver un endroit en dehors de SAP pour le faire, ou alors ils devront y consacrer beaucoup de temps et un budget important.

Des cahiers des charges aux dimensions bibliques

La numérisation est sur toutes les lèvres. Les médias, les politiques et les chefs d'entreprise interprètent tout ce qui est possible et impossible dans ce terme. Elle fournit également notre troisième argument, qui est en fait bien plus ancien que le terme de numérisation lui-même : L'agilité.

C'est certainement dû à l'âge et à la longue histoire de SAP que certains schémas se rencontrent souvent dans la gestion de projet : Au lancement du projet, le consultant entre dans la salle de réunion, taille son crayon et écoute le futur utilisateur lui demander ce qu'il aimerait.

Le cahier des charges - souvent plus épais que la Bible - est mis en œuvre et, après de longs mois, voire des années, la mise en production a lieu.

Malheureusement, le monde a déjà tourné trois fois et même l'utilisateur spécialisé de la réunion initiale n'est pas un devin. Mais c'est ainsi que fonctionne la mise en place de processus gérés par SAP en général, et c'est exactement le contraire de l'agilité.

Toutefois, si nous transférons les données via une interface élégante dans un sous-système adapté, nous pouvons faire en sorte, d'un point de vue technique et organisationnel, que les cycles d'itération dans les projets passent de plusieurs mois à quelques jours et que la capacité d'adaptation s'envole vers le ciel. C'est cela, l'agilité.

Un grand précurseur de ce mode de pensée est d'ailleurs la Self Service BI, qui ne signifie rien d'autre que d'admettre officiellement que lors de la création d'une source de données d'analyse, on ne sait pas encore exactement à quelles questions la base de données doit répondre.

Si vous pensez que les utilisateurs ont les yeux humides et les mains tremblantes d'enthousiasme devant leur ordinateur, vous vous trompez. En effet, c'est ce qu'ils font depuis toujours avec Excel.

Nous connaissons maintenant les trois arguments les plus importants : la performance, le mixage avec des données non-SAP et l'agilité. Il y en a beaucoup, beaucoup d'autres, mais au cours des vingt dernières années et de près de 2500 projets d'interface, ces trois-là sont le distillat de ce qui préoccupe les clients existants de SAP à ce sujet. Il est d'ailleurs intéressant de constater que rien ou presque n'a changé au fil du temps.

Technique de transfert de données

Considérons tout d'abord les aspects techniques pour le thème de l'intégration des données, c'est-à-dire une sous-discipline typique de la Business Intelligence. Quel que soit le fabricant, cette partie est prise en charge par une couche que nous appelons ETL (Extract, Transform, Load) ou ELT (Extract, Load, Transform).

Souvent, les données doivent encore être transformées en une forme préparée pour l'analyse, par exemple par des contrôles de qualité et de cohérence. Selon que cette transformation est effectuée pendant le transport ou après l'arrivée dans le système cible, on parle d'ETL ou d'ELT.

Dans chaque type de système d'analyse ou d'entrepôt de données, on trouve une telle couche sous différentes formes.

ETL et SQL

L'un des scénarios les plus courants serait par exemple le stockage des données dans un serveur Microsoft SQL. La partie ETL serait prise en charge par les services d'intégration SQL Server (SSIS).

Un outil livré avec le serveur SQL. Les flux de données y sont modélisés graphiquement puis automatisés. Cela fonctionne si bien et à un prix si avantageux que même des clients qui ne sont pas issus de Microsoft utilisent de temps à autre le SSIS pour transporter des données dans des systèmes étrangers (par exemple un entrepôt de données Oracle).

Les transformations souhaitées sont dans tous les cas effectuées sur le chemin du transport. Outre d'autres fournisseurs ETL comme Alteryx, une alternative à cela serait de laisser les données originales des systèmes précédents telles quelles, de les classer d'abord et de les affiner ensuite à partir d'une couche de staging en aval - ELT justement.

Cette approche fonctionne également très bien avec toutes les cibles de données courantes : SQL Server, Oracle, applications Hadoop, Amazon Redshift. La liste peut être allongée à l'infini et dépend des goûts du client.

Une fois que les données ont été préparées pour l'analyse, un fonds pratiquement infini de possibilités d'analyse s'ouvre. Du classique Excel à Power BI, en passant par des fournisseurs comme Board ou Tableau, qui font tous référence en matière d'expérience utilisateur.

Même si SAP n'est théoriquement qu'un fournisseur de données parmi d'autres dans un tel paysage, l'expérience montre qu'il occupe une place à part. Cela s'explique surtout par le fait que la connexion à SAP est techniquement plus complexe que d'autres et qu'elle peut rapidement devenir un gouffre si l'on utilise les mauvais outils.

Si nous considérons SAP ERP comme un fournisseur de données, un certain nombre d'objets sources conviennent comme point de départ. Dans le cas le plus simple, les tables. S'il est vrai que le nombre de tables SAP se situe quelque part, selon la version et le module, dans une fourchette à six chiffres, l'expérience montre que celles qui sont vraiment pertinentes sont faciles à trouver et s'avèrent être un problème maîtrisable dans la pratique.

De nombreux clients aiment également recourir aux requêtes. Il s'agit certes d'une technique impressionnante et ancienne, mais les clients SAP existants qui ont un long historique peuvent justement recourir à des artefacts existants sans devoir réinventer la roue.

Lorsque les volumes de données augmentent, il faut bien sûr envisager un chargement incrémentiel. La possibilité la plus simple est d'utiliser des sources de données OLTP classiques, comme celles qui alimenteraient un BW.

Ce type de transfert de données est d'ailleurs en train d'être rénové par SAP et remplacé par l'ODP, plus élégant et plus robuste. Il n'est donc pas prévu que ce type de transfert de données soit victime d'une feuille de route Hana dans un avenir proche.

SAP BW et le péage routier appelé licence Hub

Le rôle d'un SAP BW est un aspect important. L'expérience montre que deux tiers de tous les clients utilisent l'accès aux données de SAP ERP et un tiers à partir du BW. Pour passer par le BW, on peut dans le cas le plus simple recourir à des requêtes BEx classiques.

Lorsque les volumes de données augmentent, les sources de données d'exportation peuvent assurer un transfert incrémentiel des données de l'objet BW concerné vers un système en aval.

Un point très important doit encore être mentionné ici : si les données ne sont pas transportées directement de l'ERP, mais de la BW vers un entrepôt de données externe, un droit de passage doit être payé à Walldorf, selon les conditions de licence et le contrat, avec le nom de la licence Open-Hub.

Politiquement, cela devrait apparemment dissuader les clients SAP existants de suivre cette voie. D'après mon expérience, cela a plutôt l'effet inverse. En effet, cela les encourage financièrement à supprimer le BW existant du flux de données.

Les raisons de transporter les données d'abord via un BW et ensuite seulement dans un DataMart sont plutôt minces et ont souvent plus à voir avec la politique et l'histoire qu'avec une nécessité technique.

Intégration des processus

La technique derrière l'intégration de processus est fondamentalement différente de celle de l'intégration de données de la section précédente. En effet, il s'agit avant tout de restituer une transaction unique, soit de SAP vers l'extérieur, soit de l'extérieur vers SAP.

Côté extérieur, on utilise souvent des systèmes de workflow. Il peut s'agir par exemple de Nintex, K2 ou Microsoft Flow. Ils peuvent être techniquement intégrés dans un SharePoint ou non.

S'il ne s'agit pas d'une application de workflow, nous trouvons souvent des applications Office (le plus souvent Excel) du côté non-SAP, voire des consommateurs mécaniques comme un convoyeur ou d'autres machines de production, qui dépendent également de SAP pour les données.

Dans le cas d'Excel, un cas d'utilisation typique pourrait être soit de transférer des données de SAP vers une feuille de calcul Excel (par exemple, l'adresse du client vers le numéro de client) et/ou de les retranscrire à partir de là (par exemple, gérer des nomenclatures d'articles). Les applications sont nombreuses et représentent généralement un gain d'efficacité important pour l'utilisateur final.

Il ne doit en effet pas quitter ses environnements familiers (Excel, SharePoint ou même d'autres logiciels tiers). SAP et Microsoft ont fait plusieurs tentatives dans ce sens par le passé avec Duet.

Cela n'a guère été couronné de succès et, au final, de bonnes idées ont été réduites en poussière par une mauvaise mise en œuvre technique et trop de politique. Du côté de SAP, le point de départ est pratiquement toujours un module fonctionnel. Il peut s'agir soit d'une BAPI standard existante, soit d'un module Z développé en interne.

D'autres techniques, comme les enregistreurs de transactions ou autres, se sont révélées peu flexibles. L'utilisation d'une passerelle SAP doit également être soigneusement étudiée. La passerelle SAP n'est en fin de compte qu'une couche supplémentaire qui traduit le module fonctionnel en OData.

Cela présente deux inconvénients majeurs : La couche supplémentaire diminue les performances et la réactivité ; en outre, seules certaines transactions commerciales peuvent être contraintes dans ce mode de pensée orienté tableau d'OData.

Les cas d'utilisation dans lesquels les données sont très hiérarchiques et non tabulaires (p. ex. une nomenclature ou des données complexes de la base de données articles) deviennent très vite laids et confus dans Gateway, ce qui non seulement limite l'agilité dans le processus de développement, mais l'empêche souvent complètement.

La pratique a montré qu'un accès avec le moins de couches possible est le meilleur, le plus simple et le plus rapide : accéder directement au module ou au BA par RFC à partir du système externe.

Soit par quelques lignes de code à programmer soi-même, soit par des outils intelligents qui encapsulent la programmation dans un éditeur graphique. Même si cela peut paraître un peu timide, dans la pratique, cela s'est presque toujours avéré supérieur aux passerelles et aux IP de ce monde.

Conclusion

Nous avons vu ici les aspects les plus importants concernant les interfaces SAP. La première question qui joue un rôle est de savoir si le client souhaite transporter des données de masse (intégration de données) ou relier des processus et des transactions au sein de SAP avec le monde extérieur.

Les principales motivations sont d'obtenir de bonnes performances et de rapprocher les données SAP des données non-SAP. Une autre raison est la nécessité de construire des paysages de systèmes et des flux d'informations de telle sorte qu'ils soient déjà préparés aux changements futurs, c'est-à-dire agiles.

D'un point de vue technique, de nombreux objets du côté SAP peuvent être considérés comme des fournisseurs de données : Tables, requêtes, sources OLTP, requêtes BW, etc. Lors de l'intégration des transactions, le client existant a tout intérêt à laisser de côté les couches intermédiaires dans la mesure du possible.

Même si ceux qui aiment vendre les couches intermédiaires voient naturellement les choses différemment. Les avantages l'emportent grâce à de meilleures performances et à une plus grande agilité. Pour conclure, il est généralement conseillé d'oser plus de pragmatisme et des cycles de feedback et d'itération courts.

L'époque des grands projets phares qui résolvent tous les problèmes d'intégration est révolue. Au final, les choses doivent fonctionner de manière stable dans le monde réel et non sur papier glacé.