Témoignage d’une ingénieure études et développement sur les facteurs clés de succès autour de SAP Data Services (BODS)

Raaidah, peux-tu te présenter et nous partager les types de projets sur lesquels tu interviens dans le contexte SAP ?

Je suis ingénieure études et développement depuis 3 ans chez Infogene, avec une dizaine d’années d’expérience dans le domaine IT, en particulier sur des projets décisionnels en lien avec SAP BODS (Business Objects Data Services).Ma rencontre avec SAP BODS s’est jouée sur un concours de circonstances ! Le projet que je devais rejoindre prenait du retard, et en parallèle, il y avait un besoin de ressources complémentaires pour un projet SAP Data Services. J’ai tout de suite trouvé SAP Data Services user friendly, avec pas ou peu de code, une interface graphique où on peut agir en drag and drop. J’ai ainsi eu envie de poursuivre, d’abord en soutien, puis je suis rapidement montée en compétences pour piloter certains périmètres de développement. Si des connaissances techniques, comme SQL, sont nécessaires, c’est accessible, sans compter que les compétences et l’expertise SAP BODS sont très demandées par les grands groupes!J’interviens depuis sur des missions variées, assez longues, avec une prépondérance dans le secteur pharmaceutique. Je participe au développement dans des projets informatiques pour la pharmacovigilance, les ressources humaines, les finances… toujours autour de SAP BODS. Si les métiers diffèrent, le principe de l’outil ETL reste fondamentalement le même.

‍

‍

Business Objects Data Services est l’outil ETL de SAP. Avant de parler de l’outil, en quoi l’uniformisation des données provenant de différentes sources est essentielle ?

L’uniformisation des donnéesest bien sûr essentielle pour améliorer leur qualité, faciliter leur exploitation ou réaliser des reportings. Elle réduit les incohérences et les redondances qui peuvent être liées à la multiplicité des sources de données.En effet, plutôt que d’adapter les traitements à chaque source, on fait converger les données qui proviennent de différentes origines vers des normes communes, et ensuite, on applique des règles d’interrogation, indépendantes des sources.Un exemplevécu : dans les ressources humaines, les données provenaient de fichiers Excel et d’une application dédiée RH qui contiennentdes dates, des identifiants... Dans les fichiers Excel, les ID saisis à la main sont parfois en majuscules, parfois en minuscules alors qu’ils sont normés en majuscules dans l’application RH. Quand l’entreprise souhaite calculer le nombre d’employés, certains se retrouvent comptés en double car sous des formats différents! En uniformisant les données, on va comparer les différentes sources, appliquer des règles de gestion pour mapper les données, les fusionner et résoudre ainsi ce problème de cohérence.Au niveau du champ date, suivant la source, la donnée va parfois être la date seule, parfois inclure les heures, minutes et secondes. Si on prend la date d’achat côté procurement, pour certains calculs qui doivent déclencher des évènements, cela va engendrer des soucis et créer des décalages.

C’est donc loin d’être simplement un problème IT : l’uniformisation des données a des résonnances immédiates sur les métiers !

Suivant les secteurs d’activité et les métiers, la perception de ce sujet d’uniformisation change. Dans le domaine de la pharmacovigilance, où les données sont extrêmement sensibles, le client que j’accompagnais avait pleinement conscience de ce sujet et y accordait beaucoup d’importance. Les données devaient passer par des étapes de validation, respecter une charte de qualité exigeante et être signées par le responsable métier et le responsable qualité.Dans d’autres domaines, par exemple les ressources humaines, mon client n’était pas exigeant sur les concepts IT où les données, mais sur leurs impacts métiers. Il exprimait son besoin: KPI sur les salaires ou l’absentéisme, requêtes précises… et c’était à nous d’identifier les enjeux potentiels en termes de qualité et les solutions à mettre en place afin de réaliser avec le client les arbitrages métiers nécessaires. La qualité des données est également essentielle, mais c’est du «backoffice» en quelque sorte.

‍

‍

Comment décrirais-tu SAP Business Objects Data Services, pour en donner une définition pragmatique ?

SAP BODS (Business Objects Data services) est l’ETL (Extraction Transformation et Chargement) de SAP. Il fait partie de la suite SAP BusinessObjects qui est dédié à l'informatique décisionnelle.Avec la multiplication des sources et des volumes d’informations, ces outils ETL sont devenus très importants pour les organisations afin de transformer les données, améliorer les capacités d’analyse et faire des projections dans le futur.SAP Data Services permet d’extraire les donnes en provenant de sources hétérogènes (bases de données, fichiers Excel, Web Services…), les uniformiser en appliquant des règles de gestion afin de transmettre des données transformées et les charger dans un système cible. La solution permet d’ordonnancer les traitements et de les planifier dans le temps de manière récurrente aussi bien que de nettoyer les données, les agréger et réaliser des calculs.Les données passent par plusieurs étapes, en suivant la chaîne décisionnelle: fichiers sources, centralisation dans un ODS ou Operational Data Store, travail des données dans le datawarehouse ou base de données relationnelle, puis l’étape de datamart pour les agréations, les calculs et auquel est connectée la facette reporting.

‍

‍

Il existe de nombreuses solutions d’EAI, ETL ou ESB sur le marché. Quels sont les avantages de SAP Data Services ?

Le premier avantage, c’est que l’outil est parfaitement intégré dans la suite Business Objects et plus globalement avec les différents modules SAP. Il me semble d’ailleurs, que c’est la seule solution à disposer d’extracteurs pour les données de nomenclatures deSAPECC (ERP Central Component) etSAPBusiness Warehouse (SAP BW).En plus de l’intégration facile des données provenant des applications métiers et des outils SAP, c’est également un outil robuste. SAP Data Services peut charger des très gros volumes de données rapidement. L’outil a une architecture distribuée et peut donc traiter les requêtes de plusieurs Job Servers et référentiels. Il met également à disposition un central repository où tous les Jobs sont stockés et le système de versioning permet de suivre les versions.

La bibliothèque permet de réutiliser les données et les composants dans d’autres projets, ce qui offre un vrai gain de temps pour les tâches reproductibles ! Sans y être contraint : les fonctionnalités, et le générateur avancé de code SQL permettent de faire des transformations poussées sans être limité aux composants fournis.

Les avantages dépassent la phase de développement. Avec la console de management, les administrateurs peuvent planifier les traitements de manière automatique et récurrente, superviser les flux, réaliser des analyses d’impacts d’un objet sur toute la chaîne décisionnelle. Sans compter que le support SAP est efficace et présent.L’utilisation des contextes est aussi un atout. Par exemple, je suis en train de développer un traitement et je souhaite tester avec des données de production. Au lieu de changer les connexions des datastores, je créé des contextes: la source est la production, mais la cible est l’environnement de développement. On peut ainsi tester avec des données plus pertinentes et propres sans risque pour l’environnement de production.

‍

‍

Pourrais-tu nous partager des cas d’usage et des retours d’expérience autour de projets que vous avez menés avec SAP Data Services ?

Avec plaisir. Dans un de mes projets, un grand groupe pharmaceutique souhaitait consolider les informations de différentes sources en mettant en place un entrepôt de données pour les études cliniques. L’objectif était que les différentes équipes R&D puissent ensuite récupérer et analyser les données nécessaires, provenant de différents systèmes.Comme les sources étaient hétérogènes, les données devaient être transformées au travers d’un processus de nettoyage et d’harmonisation grâce à SAP BusinessObjects Data Services. Une fois les données agrégées et historisées selon les besoins, elles étaient chargées dans le datawarehouse puis le datamart. Toutes ces étapes étaient menées avec SAP BODS en respectant l’architecture décisionnelle (ODS, base de données temporaire, datawarehouse, datamart).L’exigence sur la qualité des données était très élevée: des automatismes étaient mis en place pour vérifier les données. Par exemple, si une fonctionnelle était vide, et que l’anomalie provenait du système source, le responsable métier était automatiquement averti pour procéder à la correction avant de redescendre la donnée.Ce groupe pharmaceutique désirait également être capable de suivre l’évolution de certaines données dans le temps. Il fallait donc historiser les informations et pouvoir suivre, avec des flags, les dates de validité des lignes.

Si ces étapes paraissent compliquées, dans la pratique, SAP Data Services dispose de fonctions dédiées permettant de contrôler les données et les composants. Il est donc inutile de passer par des requêtes SQL compliquées qui ralentiraient la performance.

Pour prendre un autre exemple, au sein d’un groupe biopharmaceutique international, le projet consistait à récupérer des données RH en provenance de l’outil métier afin de calculer des KPIs sur les promotions, le tau d’absentéisme, la répartition des employés par division et entité, les salaires… Nous avons pour cela mis en place un datahub qui regroupait les informations détaillées par employé et une architecture dataviz pour les données agrégées utilisées pour les dashboards. Dans le datahub, les données étaient enrichies: âge, talents, fonctions… afin qu’elles puissent être ensuite directement exploitées d’un point de vue décisionnel.Dans mes missions, je n’ai pas noté de différences fondamentales dans les approches et les besoins entre différents secteurs d’activité. C’est avant tout la criticité des données, souvent propre aux métiers et aux services concernés, qui implique des processus de validation et de vérification plus exigeants. Au niveau de la sécurité, il faut aussi prendre en compte l’accès aux données en bout de chaîne, par exemple sur la partie reporting: ce ne sont pas des points que j’ai pilotés directement dans mes projets, mais en avoir conscience est important. Les contextes internationaux apportent également des enjeux supplémentaires avec la gestion des langues pour lesquelles SAP Data Services dispose d’options dédiées.

‍

‍

D’après ton expérience, quels conseils partagerais-tu autour de l’utilisation de SAP BODS ?

Dans les grands groupes, il y a souvent plusieurs projets en parallèle autour de SAP BODS. Ce n’est pas car je suis la seule développeuse sur mon projet, que je suis la seule à travailler sur SAP Data Services! Garantir que les projets développés respectent certaines normes et que les développements sont commentés est un gage de cohérence et de maintenabilité. Après le Go Live, c’est un vrai gain de temps pour le support si tout est bien documenté.Si l’entreprise dispose d’un central repository, versionner les déploiements permet de revenir aisément sur une ancienne version sans avoir à redévelopper. Il y a plein d’autres bonnes pratiques: limiter la parallélisation des flux si possible, charger en «bulk load» dans le cas de gros volume de données plutôt qu’en insert simple…

Devoir suivre un guide de bonnes pratiques indiquant en particulier les codifications peut paraître fastidieux, mais on se rend tout de suite compte de l’intérêt lorsque je dois aller étudier d’autres projets, que je ne connais pas directement, pour récupérer des éléments !

Et un dernier conseil, qui peut sembler une évidence : faîte simple dans le développement de vos flux. SAP BODS le permet, alors autant avoir la simplicité comme cible!