Dans cet article, nous allons présenter un cas d’usage des spaces de SAP DWC
Un peu de contexte Business
Vous êtes responsable des achats chez un fabricant de meubles.
En fin stratège que vous êtes, vous ne prenez pas le risque de mettre tous vos œufs dans le même panier lorsqu’il s’agit d’achat de MP. En d’autres termes, vous diversifiez vos sources d’approvisionnement que ça soit en termes de fournisseurs et de pays d’approvisionnement.
Néanmoins, vous n’échappez pas à la règle qui veut que vous vous approvisionniez chez le plus intéressant.
Et il se trouve que pour le bois (principale MP composant de vos meubles), il est difficile de faire mieux que ce que propose un très vaste pays qui se trouve tout à l’Est.
Arrive un jour où un évènement à portée mondiale éclate. Ce pays entre en conflit avec son voisin de l’Ouest et forcément, des conséquences sur l’économie mondiale se font ressentir.
Votre entreprise n’y échappe pas.
Vos approvisionnements en bois prennent du retard, son cout de revient explose du fait du rallongement des transports, et enfin des consignes gouvernementales incitent fortement à ne plus s’approvisionner depuis ce pays.
(Toute ressemblance avec une situation connue n’est que pure coïncidence)
Vous êtes contraints de rapidement faire appel à d’autres fournisseurs.
Dieu merci, votre carnet d’adresse est suffisamment bien garni pour arriver à faire en sorte que tous se précipitent pour vous communiquer leurs tarifs. L’ultime étape est donc d’identifier l’impact sur vos coûts de revient afin d’être en mesure de prendre des décisions opérationnelles très très rapidement, mais aussi stratégiques telles que : retirer certaines références du catalogue, changer de type de bois sur une catégorie d’article afin d’en réduire l’impact sur le prix de vente, ou pourquoi pas (soyons fous !), remettre au gout du jour l’idée de racheter une filiale exportatrice au Brésil ?!

Dans son dernier outil de datawarehousing (Datasphere), SAP a mis en œuvre un « objet » appelé « space ». Cet objet a pour utilité de créer des environnements de travail virtuels à l’intérieur desquels, seuls les utilisateurs ayant des autorisations peuvent y accéder. Comme partout ailleurs, il existe différents droits en fonction de ce qu’il est permis de faire ou non.
Sans space, il n’est pas possible de commencer à travailler avec Datasphere.
Grâce aux éléments de configuration de spaces, SAP Datasphere permet de :

-donner de l’autonomie aux Métiers
-tout en préservant la sécurité des modèles.

Voyons ici une configuration qui vous permettra en tant que responsable des achats à vous aider à rapidement visualiser l’impact de ces nouveaux tarifs sur vos couts de production.

Comme son nom l’indique, celui-ci sera dédié à tout ce qui concerne l’administration de la solution, et sera accessible à une population très restreinte, plutôt IT/Admin. En tant que Métier, vous n’y aurez logiquement pas accès.

Cet univers aura comme utilité d’aller lire/charger toutes les données depuis vos systèmes source. Aucune transformation, aucune modélisation, aucune action particulière, si ce n’est, sélectionner les sources de données que nous souhaitons consulter.
Des données que l’on lira au travers de tables distantes (lecture en temps réel) ou table locales (réplication des données dans Datasphere) devront ensuite être partagées avec un space qui aura un rôle bien précis. En tant que Métier, vous n’aurez toujours pas accès à ce space étant donné que celui-ci concerne l’ensemble des domaines. Une gestion centralisée et maitrisée par l’IT/BI est donc nécessaire.

Un espace dans lequel une approche de modélisation est menée au sein du data builder. En passant par de la normalisation, la création de vues, de la sémantique technique, de la modélisation de flux, de l’agrégation etc.
Le but de cet espace étant de commencer à rendre la donnée intelligible pour ensuite la rendre accessible (en lecture) aux domaines (donc à une population ciblée) concernés.
En tant que Métier, vous ne serez toujours pas concernés puisque pour la même raison que le space Acquisition, celui-ci est toujours centralisé.
Patience…le prochain sera le vôtre 😉

A chaque domaine son espace. Dans chacun de ses domaines, on accède uniquement aux données qui nous concernent directement. Quant aux données transversales ; elles sont bien entendues partagées avec l’ensemble des espaces.
Dans ce space, vous serez totalement autonomes puisque vous pourrez manipuler vos données comme vous le souhaitez, à savoir :

• Personnaliser des (nouveaux) jeux de données (en masquant par exemple tout ce qui vous n’est d’aucune utilité),
• Créer vos propres KPIs
• Enrichir les données qui viennent de vos systèmes sources en y intégrant vos propres données
• C’est ici que vous ajouterez les derniers tarifs reçus de chez vos fournisseurs
• Intégrer votre propre sémantique qui saura parler à vos utilisateurs
• Définir comment vous souhaitez gérer le contrôle d’accès aux données
• Etc…

Maintenant que l’on a compris comment est-ce que l’on peut organiser ses spaces, voyons à présent comment cela s’opère dans le contexte que nous avons présenté ici.

Pour rappel : Nous aimerions connaitre l’impact des tarifs de bois proposés par nos fournisseurs, sur nos couts de production.

Comme vu précédemment, en tant que membre du département Achat, nous n’interviendrons qu’au sein de l’espace qui nous a été réservé, à savoir le « ACHAT/APPR. »

Pour des raisons de sécurité, et de partage des rôles au sein des équipes, un membre des achats aura en charge d’intégrer le fichier des prix dans SAP DWC, à partir de l’application Data-Builder. Le Data-Builder est la partie théoriquement technique, mais en ce qui concerne l’intégration d’un fichier plat, elle est à la portée de tous.

Revenons-en à la personne qui chargera le fichier plat. Son unique responsabilité sera celle-ci. Et grâce au rôle qui lui sera affecté, il pourrait n’avoir accès à aucune autre action.

Il existe environ 7 rôles standards dans SAP DWC. Si aucun des rôles ne convient aux autorisations que vous souhaitez accorder à un ou des utilisateurs, sachez qu’il est tout à fait possible de créer des rôles personnalisés.

Les tarifs sont à présent à disposition (en lecture) à tous les membres de l’espace « ACHAT/APPR. », et éventuellement aux membres d’autres espaces si vous décidez de partager les informations avec d’autres départements.

Rappelons qu’il est possible d’ajouter un contrôle d’accès aux données (DAC) ; ce qui permet de garder la maitrise de ce que l’on souhaite partager et à qui on souhaite le partager.

Toujours au sein de votre département (toujours donc au sein de votre espace Datasphere), un des membres de votre équipe aura la main pour customiser vos sets de données.

Dans l’application Business-Builder cette fois-ci. Celle réservée aux utilisateurs métiers.

C’est ici que tout va s’effectuer.

A partir de vues de données qui vous seront mises à disposition dont la provenance est votre système source + la table des tarifs fraichement intégrée, il suffira de :
-Créer un 1er modèle de faits contenant la décomposition actuelle du cout de revient des articles
-Filtrer la vue en ignorant les couts des Matières Premiers
-Renommer les champs en langage métier
-Créer un 2nd modèle de fait contenant uniquement les nouveaux tarifs
-Renommer les champs en langage métier
-Créer un modèle de consommation
-Joindre vos 2 modèles de fait précédemment créés
-Créer un nouveau KPI (cout de revient) qui sommera les couts de vos 2 modèles de fait
-Créer une perspective
-Sélectionner les champs et calculs qui seront mis à disposition de notre utilisateur final au sein de l’outil de reporting
-Ajouter le contrôle d’accès aux données (Optionnel)
-Sélectionner la dimension qui servira d’élément de restriction d’accès aux données

Vous pouvez à présent visualiser dans votre outil de reporting, le résultat de l’intégration de ces nouveaux tarifs.

Comme son nom l’indique, celui-ci sera dédié à tout ce qui touche à de l’administration, à savoir la gestion des utilisateurs, leurs autorisations, aux logs d’activité & monitoring, etc. Inutile de préciser que comme toute action relevant de l’admin, ce space sera strictement réservé à des administrateurs.

Arrêtons-nous quelques instants afin de voir comment peuvent être gérées les autorisations au sein de ce space.

1ere étape : Disposer d’une table d’autorisation contenant une colonne « User » ainsi qu’une colonne portant l’objet d’autorisation (ex : région, société, catégorie de produit, etc)
2ème étape : Créer une vue à partir de cette table
3eme étape : mettre la vue en partage avec les autres spaces
Vient ensuite l’intégration des autorisations grâce au DAC (Data Access Control) au sein des objets analytiques. Cette partie ne faisant plus partie de ce space, je ne m’étalerai pas davantage sur cet aspect.

Ainsi, les autorisations sont centralisées et sécurisées.

Ce space serait dédié comme son nom l’indique à faire l’acquisition de données en 1 : 1. Aucune transformation, aucune normalisation, aucun MDM à ce stade. Le strict équivalent de la couche d’extraction que l’on retrouve dans les grands principes BI.

A noter que ce space peut tout à fait être optionnel et être géré au sein du space « Administration ». L’idée d’un space dédié est de scinder la partie Admin de la partie Acquisition.

Population : IT/Admin

Fidèle aux grands principes BI, un environnement dédié à ce qui a trait à la Transformation. On y gère le MDM (BI), les filtres, jointures, unions, etc. Le tout afin de constituer des modèles de données exploitables de 2 manières différentes :

Soit connecter directement un outil de reporting aux objets de ce space qui auront été préalablement déclarés comme étant consommables
Soit partager (en lecture) les objets développés au sein de ce space avec d’autres spaces.

Population : IT/BI

Dédier des spaces à des domaines bien précis va permettre de cloisonner les données (toujours en ayant la possibilité de partager du contenu avec d’autres domaines). En d’autres termes, vous gardez le contrôle de qui voit quoi. Mais en plus, vous allez pouvoir personnaliser son contenu puisque seul le domaine concerné ne sera autorisé à y pénétrer.

Cela apporte une très grande autonomie aux utilisateurs. C’est d’ailleurs un des atouts majeurs de cette solution.

Et c’est ici que vient la distinction évoquée précédemment : Data-Builder & Business-Builder. Les métiers seront principalement utilisateurs de l’application Business-Builder. Ils pourront y intégrer leur propre sémantique, créer leurs propres jeux de données, gérer à leur manière le contrôle d’accès de leur données, etc …

Néanmoins, l’utilisation du Data-Builder, leur offrira la possibilité d’intégrer des fichiers plats dont ils seraient les seuls détenteurs. C’est un gain de temps énorme par rapport à BW. Cela confère aux métiers une autonomie qu’ils n’ont jamais connu dans l’univers BI SAP.

De la même manière que lorsque l’on souhaite faire évoluer un BW classique vers un BW/4, pour que DWC puisse lire le contenu d’un BW (ou BW/4), il faut exécuter une séquence de conversion. Il existe plusieurs méthodes et celles qui concernent BW Bridge se nomment la « remote conversion » et la « shell conversion ».

Le principe étant de transformer des objets obsolètes en objets pérennes. (ex : les InfoCubes deviennent des Advanced DSO) afin de pouvoir en lire le contenu.Ce qui va différencier ces 2 méthodes est que la Shell Conversion ne va traiter que les métadonnées, tandis que la Remote Conversion ira en plus, transférer les données vers un repository.

Nous allons retrouver le bon vieil Eclipse au sein duquel 2 instances viendront s’ajouter :

Une instance qui contiendra un projet BW (Bridge) Modeling tool : Toute la modélisation qui aura été convertie s’y retrouvera.

Une instance ADT (ABAP project tools) afin d’étendre les capacités de modélisation;

SAP BW Bridge cockpit
Une interface UI5 permettant d’administrer les données ainsi que les processus de chargement