L’IA évolue rapidement, et la pression pour démontrer une valeur tangible s’intensifie. Mais alors que les investissements s’envolent et que l’appétit pour l’adoption ne cesse de croître, de nombreuses entreprises constatent que leur socle de données n’est pas tout à fait à la hauteur pour prendre en charge les agents d’IA et les applications.

Les données se trouvent dans différents systèmes on-premises et dans des environnements multi-cloud. Chaque source possède sa propre structure, sa propre logique et ses propres règles métier. Utiliser ces données pour l'analyse, la planification ou l'IA implique souvent de passer du temps à extraire, nettoyer et combiner les données afin de reconstruire le contexte pour différentes applications. Que signifie ce champ ? Quelle définition est correcte ? Comment ces données se connectent-elles à ce processus ?

Cela se produit à plusieurs reprises dans l’ensemble de l’entreprise, créant une « taxe de complexité » qui ajoute du travail pour rendre les données existantes exploitables. La taxe de complexité ralentit les équipes informatiques responsables de l’évolutivité et de la gouvernance. Elle ralentit également les équipes métier qui ont besoin de réponses plus rapides, de Workflows plus simples et de résultats fiables.

Une structure de données métier aide à relever ce challenge en reliant les données et le contexte métier au sein d’un socle fiable et réutilisable. Ce socle devient beaucoup plus facile à comprendre lorsqu’on le découvre à travers l’expérience des personnes qui l’utilisent. Suivons trois personnes au sein d’une organisation d’entreprise pour voir comment une structure de données métier peut prendre en charge un Workflow de planification connecté, de la création d’un produit de données à la génération de modèles de planification, puis aux mises à jour finales des plans.

Créer un produit de données fiable

Notre première utilisatrice est Olga, une développeuse métier. On lui a demandé de créer un produit de données dérivé basé sur un produit de données existant provenant de SAP S/4HANA. Son objectif est de mettre les bonnes données à la disposition de Ryan, qui les utilisera pour créer un modèle de planification.

Olga commence dans Joule Studio. Elle décrit ses besoins en langage naturel, en demandant un produit de données simplifié sur les centres de coûts qui inclut uniquement les centres de coûts actifs, les descriptions en anglais, ainsi qu’une liste consolidée des identifiants et des descriptions.

L’agent d’IA recherche des sources existantes et présente des options qu’Olga peut examiner. Il ne part pas de zéro et ne présume pas de l’étape suivante. Au lieu de cela, il guide Olga à travers un processus itératif, en demandant confirmation tout au long du parcours. Olga peut voir un aperçu du nouveau produit de données avant de poursuivre, ce qui lui permet d’avoir confiance dans les données et la logique, car elle a participé au processus.

L’agent propose un nom pour le produit de données, qu’Olga met ensuite à jour pour qu’il corresponde à la convention de désignation qu’elle et Ryan ont convenu d’utiliser. L’agent applique la modification et prépare le produit de données en vue de sa publication.

L’expérience d’Olga illustre comment une structure de données métier permet de réutiliser le contexte métier dans différents systèmes et domaines, ce qui constitue un avantage important. Olga n’a pas eu besoin de commencer avec des données brutes, ni de recréer la logique de zéro. Elle a travaillé avec des produits de données gouvernés existants, tout en restant impliquée afin de créer un produit de données de haute qualité pour le prochain utilisateur.

Transformer des données fiables en un modèle de planification

Le prochain utilisateur de notre scénario est Ryan, un modélisateur de planification travaillant dans SAP Analytics Cloud. Il doit créer un modèle de planification des dépenses d'exploitation pour Anna, une analyste de données responsable d'un domaine d'activité spécifique.

Ryan commence également son travail dans Joule, en décrivant le modèle qu’il souhaite créer et le niveau de détail dont Anna a besoin. Joule reconnaît son intention et recherche les produits de données disponibles qui correspondent à la demande. Comme le produit de données nouvellement dérivé par Olga a déjà été publié et est clairement nommé, Ryan peut facilement le trouver, le sélectionner et poursuivre.

Ce processus guidé par l’agent évite à Ryan de devoir rechercher les produits de données disponibles, comprendre leurs structures, créer des dimensions et les maintenir lui-même. L’agent construit un modèle pour effectuer les actions spécifiques sur les données demandées par Ryan, et ce, en quelques secondes plutôt qu’en plusieurs heures.

Enfin, Ryan demande à l’agent d’ajouter une présentation analytique au modèle de planification afin qu’Anna puisse plus facilement visualiser leurs résultats. L’agent Joule résume ce qu’il va utiliser, crée des visualisations et les organise dans une disposition intuitive. Ryan affine le tableau de bord obtenu avant de le partager avec Anna.

Ryan a constaté le deuxième avantage important d’une structure de données métier : la modélisation devient plus simple et plus rapide lorsque des sources de données fiables sont facilement disponibles. L’agent peut agir sur des données gouvernées disposant d’un contexte métier clair, et Ryan a confiance dans le résultat.

Planifier sans retracer chaque point de données

Enfin, nous rencontrons Anna, une planificatrice financière. Elle ouvre le modèle de planification et la présentation que Ryan a publiés. Avant d’apporter des modifications, elle crée une copie de travail privée afin de pouvoir ajuster son plan sans modifier la version publiée.

Du point de vue d’Anna, les données sont prêtes à être utilisées. Certains coûts proviennent de SAP S/4HANA. D’autres données proviennent d’un flux d’un assureur tiers connecté via la structure de données. Les données dont elle a besoin pour la planification sont facilement accessibles, et Anna n’a pas besoin de s’arrêter pour demander d’où provient chaque valeur.

Anna utilise le langage naturel pour élaborer le plan, en supprimant certains éléments et en demandant à Joule de les renseigner à nouveau selon d’autres critères. Joule conserve le contexte de ses invites précédentes, applique les calculs à l’ensemble des dimensions et réintègre les résultats dans le plan.

L’expérience d’Anna met en évidence un autre avantage d’une structure de données métier : la confiance est intégrée au Workflow. Les données proviennent de sources SAP et non-SAP, mais Anna n’a pas besoin de vérifier chaque point de données avant de poursuivre. Elle peut planifier en toute confiance, car le socle de données a déjà assuré la connexion des sources, la préservation du sens et l’application de la gouvernance.

Trois utilisateurs, un workflow connecté

Ensemble, Olga, Ryan et Anna montrent ce qui se produit lorsque les données, le contexte et les Agents d’IA travaillent ensemble. En quelques minutes seulement, trois personnes accomplissent un travail qui prenait autrefois des jours, et chacun travaille à partir de la même base de données fiable.

Pour les responsables informatiques, cela signifie que l’IA agentique n’est fiable que si les données qui la sous-tendent le sont également. Une structure de données métier fournit aux agents le contexte métier dont ils ont besoin pour prendre en charge le travail réel dans tous les rôles, systèmes et processus. Elle aide les équipes à passer de données fragmentées et d’efforts manuels répétés à une façon de travailler plus simple, où les données sont connectées, leur signification est préservée et la confiance fait partie intégrante du processus.

Regardez le webinaire à la demande, Créer un socle de données pour l’IA avec une structure de données métier, pour voir la démo en action et suivre Olga, Ryan et Anna à mesure que chaque étape se déroule dans SAP Business Data Cloud.