Projets

---

Le groupe industriel Schneider Electric a retenu un outil de CDC (change data capture) pour améliorer la qualité des données extraites de ses ERP SAP vers ses data lakes. Avec Qlik Replicate, les flux d'intégration sont développés en quelques heures contre 2 à 5 jours auparavant et la consommation de ressources IT est réduite. L'outil pose aussi les bases d'une stratégie Data Mesh.

PublicitéPour extraire au fil de l'eau, quasiment en temps réel, les données de plusieurs dizaines d'ERP SAP vers des plateformes de données globales à des fins d'analyse, le spécialiste de la gestion de l'énergie et des automatismes industriels Schneider Electric s'est équipé d'un outil de CDC (change data capture). Celui-ci a permis aux équipes DataOps de passer à la vitesse supérieure sur les extractions. Le projet a été mené par l'entité Data & Performance qui a pour vocation de définir la gouvernance Data au niveau groupe et de fournir au Comité exécutif et aux différentes BU de Schneider Electric les éléments nécessaires - data products, KPI, rapports - pour mesurer et piloter la performance opérationnelle et financière de l'entreprise mondialisée.

Présent dans plus de 100 pays, le groupe Schneider Electric emploie plus de 128 000 collaborateurs pour un chiffre d'affaires total de 28,9 milliards de dollars en 2021. Il recourt à plus de 80 ERP - dont les 4/5e sont d'origine SAP - pour gérer l'ensemble de ses activités. Le contexte applicatif dans lequel s'effectue l'extraction des données vers le Global Data Hub et les différents data lakes régionalisés est donc relativement complexe. Le Data Hub, déployé dans le cloud d'AWS, vient progressivement remplacer un datawarehouse qui ne répond plus aux besoins futurs. En effet, ce dernier ne permettait pas de passer à l'échelle face à l'explosion des demandes d'analyse venant des métiers, ni de monter en puissance sur de nouveaux traitements, autour de l'intelligence artificielle, des services cognitifs ou de la classification de données.

Contraintes sur les volumes extraits

Quelques années plus tôt, l'équipe qui avait mis en place ce datawarehouse avait choisi de développer un outil spécifique paramétrable pour effectuer les extractions de données SAP qui venaient l'alimenter. Avec le temps, plusieurs limites sont toutefois apparues sur cet outil. « Initialement développé sur des technologies de type client, l'extracteur rencontrait des problèmes de scalabilité », nous a exposé Laurent Marzouk, directeur de l'architecture et de l'innovation des plateformes de données globales. Arrivé chez Schneider Electric il y a 5 ans, M. Marzouk participe activement à la conception et la mise en place du nouveau Data Lake groupe. Il est chargé de définir la roadmap d'évolution technique et fonctionnelle des plateformes Data globales du groupe (Data Hub central et Data Lakes régionalisés) « afin notamment d'adresser les nouveaux besoins métiers et d'établir des standards d'architecture pour les projets BI ».

L'équipe travaillant sur l'extracteur maison était donc contrainte sur les volumes de données extraits des systèmes SAP. Elle avait dû se résoudre à restreindre le nombre de colonnes rapatriées à ce qui était vraiment nécessaire aux équipes métiers, relate M. Marzouk. « Alors que le paradigme même d'un datalake, c'est au contraire d'extraire des systèmes opérationnels toutes les données dont on a besoin, de manière non transformée, sans se limiter en lignes, ni en colonnes », souligne-t-il. De fait, en analysant les extractions faites sur SAP pendant plusieurs années, des problèmes de complétude sont constatés sur les données. 

PublicitéEntre 2 et 5% de données manquantes

Un autre problème est identifié. De temps à autre, à la demande des métiers, des batchs de mise à jour massifs étaient exécutés pour corriger certaines données dans les ERP SAP. Mais pour des questions de performance, la journalisation de ces batchs avait été désactivée. « Comme la méthode utilisée pour extraire les données s'appuyait en partie sur les logs SAP, nous ne pouvions pas détecter tous les changements qui avaient eu lieu ; et nous n'étions pas du tout en mesure de détecter les records qui avaient été supprimés », pointe M. Marzouk. « En termes de complétude, nous avions ainsi identifié entre 2 et 5% de données manquantes ». Or, l'un des objectifs du data lake était de pouvoir fournir des data products qui soient au meilleur niveau de qualité possible en termes de complétude et d'exactitude.

« Nous avons donc cherché une autre approche et la seule qui s'est avérée pérenne était une approche de type CDC capturant à la source toute transaction exécutée au niveau de la base de données, quelle que soit l'application au-dessus, de manière à pouvoir ensuite pousser ces données vers les plateformes cibles », explique Laurent Marzouk. Mais si les solutions de CDC sont nombreuses sur le marché, celles capables de capturer en clair les changements au niveau des systèmes SAP ne sont pas légion, rapporte le directeur architecture des plateformes data. « Après avoir étudié les rares solutions compatibles à cette époque, nous avons finalement retenu Qlik Replicate ». Le logiciel, initialement édité par Attunity, a été racheté par Qlik en 2019.

Réduction de la bande passante consommée

L'un des autres intérêts de l'alternative Qlik Replicate, c'est la réduction des ressources IT consommées. Avec un outil maison, un ETL ou un iPaaS, on se connecte à SAP de façon proactive. Il faut définir des patterns d'extraction pour récupérer de manière incrémentale les données qui sont modifiées, de manière à les accumuler dans le data lake avant de pouvoir les transformer. « Ce sont des requêtes complexes qui génèrent, au niveau la plateforme opérationnelle SAP, une charge bien plus importante que ce qui est nécessaire », souligne Laurent Marzouk. « Qui plus est, ces batchs d'extraction multiples constituaient une charge concurrente avec celle de l'activité opérationnelle qui doit demeurer prioritaire dans un ERP ». 

A contrario, « l'approche CDC est par essence beaucoup plus légère puisqu'elle capture tout transaction UPSERT (Update, Insert, Delete) en quasi-temps réel. L'impact sur les plateformes opérationnelles est donc bien moindre car lissé sur la journée, contrairement à des batchs parfois massifs qui s'exécutent une à deux fois par jour. Les enregistrements créés, modifiés ou supprimés sont transmis au serveur Qlik Replicate qui les propage dans notre Data Lake. La charge et la consommation de ressources s'en trouve allégée, de même que la consommation de ressources au niveau des ERP. C'est important », insiste Laurent Marzouk en ajoutant : « Et puis bien sûr, cela a contribué aussi à diminuer significativement la consommation de la bande passante réseau puisque nous devions auparavant rapatrier beaucoup plus de données que nécessaire au niveau des ERP dans le data lake avant d'effectuer un filtrage a posteriori. Nous avons vraiment observé des gains de performances à ce niveau-là ».

Un premier pilote en trois mois

Le choix de Qlik Replicate remonte à environ deux ans. La première entité à l'avoir testée est basée en Amérique du Nord où se trouve installée l'une des plateformes data hub régionales, également sur AWS (d'autres se trouvant en Europe et en Chine principalement). « Ils ont commencé à évaluer la solution en mode pilote avec quatre sources qui n'étaient d'ailleurs pas toutes SAP », se souvient M. Marzouk. A deux ERP SAP de générations différentes, un S4/Hana et un ECC, s'ajoutait une base DB2 sur mainframe et un datawarehouse Oracle. « Donc quatre sources assez significatives, différentes et complémentaires de ce que nous pourrions potentiellement avoir à gérer », décrit M. Marzouk. « En trois mois, ils ont été capables de délivrer un pilote et, deux mois après, ils ont commencé à progressivement passer en production sur leur plateforme. Nous avons alors déployé la solution au niveau du Data Hub global et commencé à intégrer les données des autres ERP principaux du groupe ».

Ces ERP consolidés - une quinzaine - portent 80% du chiffre d'affaires de Schneider Electric dans les principaux pays où opère l'industriel français. Ce sont les données de ces ERP qui ont été historiquement ingérées sur le datawarehouse et, depuis quatre ou cinq ans, sur le Global Data Hub. Le reste des ERP, dont les données sont peu à peu intégrées dans le data lake par d'autres outils, concerne des segments d'activités particuliers ou résultant d'acquisitions, ils seront progressivement consolidés sur les plus gros ERP ou migrés dans le cloud.

Du Data Mesh avant l'heure

Avant même d'installer Qlik Replicate dans son paysage applicatif, l'un des principes définis par l'entité Data & Performance de Schneider Electric, dans le cadre de sa stratégie historique d'ingestion de données, fut de déléguer aux régions la responsabilité d'ingérer dans leur Data Hub régional les données des plateformes opérationnelles colocalisées, indique M. Marzouk. Avec un triple objectif : « Résoudre certains problèmes de performance lors des phases d'ingestion, mettre en place une topologie Data Hub & Spokes multi-régions permettant de supporter plus simplement les exigences des différentes réglementations en matière de data residency & privacy, et bien sûr s'appuyer sur les équipes locales compétentes ». L'objectif final étant de mettre en place une architecture de bout en bout permettant de fédérer ces différents Data Hubs et d'offrir une vue unifiée de toutes ces données afin de les rendre aisément consommables et supporter les multiples besoins en termes d'AI, de BI et d'analytique, nous a expliqué Laurent Marzouk. « Ces principes ont permis d'introduire il y trois ans chez Schneider Electric le concept de Data Mesh avant même que celui-ci ne soit démocratisé dans la communauté Data ».

Suite au pilote Qlik Replicate conduit aux Etats-Unis, un pilote de plus grande envergure a été démarré au niveau global avec des sessions de formation. Le choix d'une telle solution nécessitait de mettre en place la bonne gouvernance et le bon operating model. « Il fallait donc une équipe compétente que l'on a formée ». Les équipes opérationnelles et de delivery (DataOps) ont été les premières concernées. Mais afin de tirer tous les bénéfices d'une approche Data Mesh, il est également prévu d'inclure d'autres profils plus métiers afin de pouvoir passer à l'échelle. 

Des flux d'intégration créés en quelques heures

Jusqu'à présent, les DataOps chargés de développer les flux d'intégration, d'après les spécifications fonctionnelles qui leur étaient fournies, avaient besoin de deux à cinq jours pour extraire toute nouvelle table des ERP SAP et les verser dans le data lake. Avec la solution CDC, « nous sommes passés à quelques heures pour chaque table, car nous n'avons plus besoin de définir par nous-mêmes les patterns d'extraction incrémentale. Qlik Replicate nous a permis de changer complètement de paradigme et d'échelle, avec des gains opérationnels observés très significatifs et des économies d'échelle substantielles en termes de FTE/FTC* », relate M. Marzouk. A cela plusieurs raisons. « L'interface est beaucoup plus user friendly que celle d'un ETL ou d'un iPaaS, essentiellement basée sur du click et du drag & drop. Les connecteurs natifs vers SAP permettent de se connecter directement sur l'ERP visé et d'obtenir la liste des tables qui nous intéressent. Il suffit alors de sélectionner une ou plusieurs tables fonctionnellement cohérentes, de créer automatiquement un job de réplication puis de le démarrer ». Et l'on est sûr de récupérer 100% des données supprimées, modifiées ou ajoutées.

Après les équipes DataOps, il était prévu de mettre l'outil de CDC entre les mains d'équipes plus métiers, « lorsque la gouvernance et l'operating model qui vont avec auront été définis et validés, dans la droite ligne de la stratégie Data Mesh que nous avons mis en place depuis 3 ans », expose M. Marzouk. Il s'agit d'embarquer les équipes digitales et métiers (Global supply chain, global marketing, customer relationship, HR...) en mettant à leur disposition les outils leur permettant de développer en toute autonomie des data products de bout en bout ».

Aller plus vite sur le time to data

Actuellement déployé sur deux ou trois ERP jusque-là non connectés au Data Hub global, car récemment intégrés au paysage IT de Schneider Electric, le projet Qlik Replicate est dans un premier temps focalisé sur l'ingestion des données orientées sur les commandes, les ventes et les factures « afin de compléter le scope des Data Products qui permettent d'analyser la performance financière et opérationnelle du groupe. Ce sont de loin les données les plus consommées dont nous avons pu améliorer la couverture business ». Viendront ensuite, comme précédemment indiqué, les ressources humaines, le global supply chain, mais aussi le global marketing ou, encore, l'équipe Digital customer relationship chargée de la Customer journey. « Ces équipes digitales sont en lien avec les équipes métiers opérationnelles et ont besoin de créer des data products pour piloter leur activité, mais ces derniers ont aussi vocation à être croisés avec des data products d'autres domaines fonctionnels du Data Hub, ce qui permettra de générer de nouveaux insights jusque-là difficiles à obtenir. Toutes ces équipes ont besoin d'aller plus vite sur le time to data, autre raison pour laquelle nous avons choisi d'introduire cette technologie de CDC ». 

Au début du projet, les capacités de réplication quasi-temps réel de l'outil ne primaient pas sur les problématiques de complétude des données et d'efficacité opérationnelle des équipes. « Mais on observe que la frontière entre les besoins purement BI et les besoins très opérationnels devient de plus en plus ténue », note M. Marzouk. « Donc, une solution comme celle-là nous permettra à terme, dans un avenir assez proche, d'alimenter un data lake opérationnel pour lequel cette notion de temps réel va s'avérer un atout supplémentaire ».

Impliquer les équipes en charge des plateformes SAP

Interrogé sur les difficultés rencontrées au cours du projet Qlik Replicate, le directeur de l'architecture des plateformes de données présente l'outil comme « assez simple techniquement à déployer » malgré quelques prérequis techniques à respecter. « Il y a notamment un certain nombre de droits à mettre en place pour le compte de service utilisé par Qlik Replicate afin de permettre à l'outil d'aller lire les données dans les logs de la base de données qu'il monitore par exemple », explique-t-il, ce qui nécessite un accès physique au niveau de la base de données. Une instance Qlik Replicate est déployée en IaaS aux Etats-Unis et une autre en Europe, « chacune étant colocalisée aux plateformes dont elles extraient les données ». Ces serveurs monitorent et extraient les données en mode CDC depuis les ERP SAP régionalisés pour les déposer ensuite sur les data lakes cibles concernés.

L'un des freins majeurs identifié par M. Marzouk sur ce type de projet est la réticence des équipes techniques en charge des plateformes SAP à déployer les prérequis nécessaires au bon fonctionnement de Qlik Replicate, car elles ne se sentent pas forcément concernées au premier chef par les besoins en business intelligence. Leur mandat premier est de garantir la pérennité et le bon fonctionnement de ces plateformes opérationnelles qui sont critiques pour toute entreprise. « Il faut donc faire preuve de didactisme concernant le fonctionnement de l'outil et le fait qu'il soit sécurisé et leur expliquer en quoi ce type de solution peut au contraire aider à soulager à terme la charge liée aux jobs d'extraction de leurs plateformes », fait valoir Laurent Marzouk. « Il est très important d'impliquer ces équipes dès le 1er jour afin de s'assurer de leur collaboration et de leur support. »

L'indispensable sponsorship de niveau exécutif

Un autre point est selon lui très important. C'est la nécessité d'un sponsorship de niveau exécutif. « Ça ne peut pas être un projet tiré par l'IT. Si l'on n'a pas un responsable exécutif business ou Data qui est partie prenante du projet, capable de définir les priorités, rendre les arbitrages et rappeler le caractère stratégique de cette approche pour l'entreprise, notamment vis-à-vis des équipes techniques en charge des plateformes SAP, cela devient très compliqué et peut faire perdre beaucoup de temps », met-il en garde. Il peut par exemple s'agir du directeur métier d'un département ayant beaucoup de demandes en termes d'extraction temps réel ou ayant un projet de time to data, avec de fortes contraintes de temps. Chez Schneider Electric, le sponsoring est plutôt venu du « Data Office central », via le Chief data officer. « Il n'y a pas de réponse unique à cette question, mais il faut quelqu'un qui ait du poids dans la décision et qui comprenne surtout la portée stratégique de cette solution et la valeur qu'elle apporte à l'entreprise. 

« Nous avons aussi positionné très clairement l'utilisation de cette nouvelle technologie d'intégration dans notre portfolio d'outils de middleware et d'intégration de données, par le biais d'un Playbook ». L'utilisation de Qlik Replicate est pour l'instant restreinte à l'extraction des données des ERP avec pour objectif de remplacer progressivement l'outil maison qui va devenir obsolète. « Nous ne nous interdisons pas bien sûr d'en étendre l'usage par la suite mais, pour l'instant, il y a encore beaucoup à faire avec SAP ». L'outil est utilisé en IaaS, déployé sur une machine virtuelle. Il peut être installé à partir d'une marketplace, fourni sous forme de template sur les principaux clouds publics (AWS, Azure...) par Qlik. Une version PaaS existe sous le nom de DMS, Data Management Services. « Nous l'avions également examinée pour d'autres sources de données, elle est très intéressante pour faire du cloud to cloud, mais elle n'offre pas les connecteurs SAP ».

Combiner data mesh et data virtualization

Qlik Replicate est donc l'un des piliers techniques introduits il y a deux ans pour supporter la stratégie data mesh et apporter plus d'autonomie aux équipes DataOps, digitales et métiers sur la partie intégration de données. « Mais ce n'est pas le seul », indique Laurent Marzouk. « Nous avons commencé à regarder d'autres technologies pour leur permettre de définir de manière plus agile et autonome leurs Data models. Dans cette optique, nous nous intéressons donc, également, à des technologies de data virtualization, parce que, de la même façon, modéliser un data product au sein d'une plateforme massivement parallèle comme RedShift que l'on utilise dans AWS, c'est quelque chose qui nécessite vraiment une expertise assez forte et assez pointue. » Or, les équipes business opérationnelles n'ont pas forcément toutes ces compétences. Le fait d'introduire de la virtualisation de données va permettre de passer à l'échelle aussi sur des phases d'expérimentation, et faire monter en puissance de nouvelles personnes.

« Le data mesh, c'est avant tout une question d'organisation d'équipe et de délégation des responsabilités pour la production de data products, mais c'est aussi une question d'architecture et de solutions techniques adaptées. On sait aussi que la data virtualisation nous permettra de mettre en oeuvre un time to data plus rapide pour d'autres sources de données que SAP en évitant de développer des flux d'extraction et de déplacer la donnée lorsque ce n'est pas nécessaire. CDC et data virtualization sont deux technologies complémentaires qui viennent très efficacement compléter notre architecture Data Hub & Spoke en apportant plus d'autonomie et d'agilité à nos équipes Data ».

* FTE : full-time equivalent
FTC : full-time contractor

Article rédigé par

Maryse Gros, Journaliste, chef de rubrique LMI

Partager cet article