En bref
OAC peut analyser les données ERP Cloud soit via une connexion directe, simple mais limitée, soit via une architecture BI classique, plus flexible et complète.
La première est rapide pour des analyses standard, la seconde idéale pour des besoins avancés et de gros volumes. Le choix dépend du niveau de personnalisation et de complexité attendu.
Dans un environnement où les données sont au cœur de la prise de décision, Oracle ERP Cloud et Oracle Analytics Cloud (OAC) forment un duo pour transformer les informations opérationnelles en insights stratégiques.
Il existe différentes approches pour exploiter et analyser les données d’ERP Cloud dans OAC, en fonction des besoins de stockage, de performance et de flexibilité.
Cet article explore les principales architectures pouvant être implémentées.
Quelle architecture BI pour valoriser les données ?
Il existe 2 principales approches pour traiter et analyser les données ERP Cloud dans OAC : une approche que je qualifierais de directe et une autre qui est plus classique et qu’on rencontre généralement dans les projets Business Intelligence.
1. Approche « directe »
Il s’agit tout simplement d’utiliser la connexion native entre OAC et ERP Cloud via le connecteur Oracle Applications.
Ce connecteur permet de visualiser directement dans OAC les données provenant des applications de la suite Oracle Fusion Cloud Applications :
- Oracle Fusion Cloud Financials
- Oracle Fusion Cloud Human Capital Management
- Oracle Fusion Cloud Loyalty
- Oracle Fusion Cloud Procurement
- Oracle Fusion Cloud Project
- Oracle Fusion Cloud Supply Chain Planning
- Oracle Sales Automation
Cette connexion permet d’accéder aux subject areas et aux rapports OTBI disponibles dans Oracle ERP Cloud . On peut ainsi créer des datasets à partir de ces données et les visualiser dans Oracle Analytics Cloud.
Avantages
- Simplicité : pas besoin de compétences techniques avancées. Les subject areas sont prêtes à l’emploi.
- Rapidité : intégration native avec OAC, ce qui permet une mise en place rapide.
- Sécurité : le connecteur offre la possibilité de se connecter avec les identifiants de l’utilisateur connecté, permettant ainsi de limiter l’accès aux donnés en fonction des droits définis dans ERP Cloud.
Limites
- Accès limité et flexibilité réduite : accès uniquement qu’aux subject area et rapports OTBI disponibles
- Flexibilité réduite : les analyses sont effectuées à partir des données finales des subject area et rapports OTBI.
- Performances incertaines : les données disponibles dans OAC sont celles des rapports mises en cache dans OTBI, cache sur lesquels l’on n’a pas de contrôle
- Intégration limitée : les croisements avec d’autres sources de données, les traitements et flux sont effectués dans OAC ne disposant pas d’outils d’intégration complets et offrant une capacité de stockage limitée (pas adapté pour traiter de grosses volumétries)
L’approche directe est idéale pour des besoins d’analyses rapides et standardisées, basées sur les rapports ERP Cloud existants. Elle convient aux utilisateurs métiers qui n’ont pas besoin d’accéder aux données brutes ou de réaliser des analyses complexes.
2. Approche « classique »
Cette approche permet de répondre aux limites observées dans la première approche, en adoptant une architecture BI classique permettant d’intégrer, de traiter et de stocker de grosses quantités de données sources des rapports et subject area d’ERP Cloud.
Cela est rendu possible par l’utilisation de BI Publisher qui offre un accès direct aux tables sources ERP Cloud. Il est donc possible de créer des rapports à partir de requêtes SQL d’extraction des données des tables et les charger dans une base de données (ADB, ATP, ADW…) via un outil ETL (ODI ou OIC par exemple).
Avantages
-
Accès complet : on peut analyser les données de toutes les tables d’ERP Cloud, sans restriction.
-
Flexibilité : possibilité de transformer, d’enrichir les données et de définir ses propres KPI aisément avant l’analyse.
-
Volumétrie illimitée : les données sont stockées dans un datawarehouse optimisé pour le traitement de gros volumes.
-
Intégration multi-sources : On peut croiser les données ERP Cloud avec d’autres sources (CRM, données externes, etc.)
Limites
-
Complexité : la mise en place nécessite des compétences techniques (développement ETL, configuration, maintenance).
-
Coût : licences supplémentaires pour les outils ETL (ODI/OIC) et le datawarehouse (ATP/ADB)
-
Temps de développement : la configuration des flux ETL et la modélisation sémantique peut prendre du temps, surtout pour des analyses complexes.
L’approche classique notamment avec extraction des données de rapports BI Publisher est idéale pour des besoins de :
- Accès aux données sources d’ERP Cloud pour calculer et analyser des KPI spécifiques non disponibles dans les subject area standards
- Réalisation d’analyses avancées ou des croisements multi-sources.
- Gestion de gros volumes de données.
Pour résumer, voici un comparatif synthétique :
Vous hésitez entre les deux approches pour votre projet ?
Nos experts SQORUS vous accompagnent dans le choix de l’architecture la plus adaptée à vos besoins.
Quelle approche choisir pour votre projet Oracle BI ?
Le choix entre analyser les données d’Oracle ERP Cloud à partir des rapports standardisés ou des données sources dépend de vos besoins spécifiques.
- Approche directe : idéale pour des analyses rapides et standardisées, sans besoin de compétences techniques avancées en Business Intelligence.
- Approche classique : idéale pour des analyses avancées et personnalisées, avec un accès complet aux données et une flexibilité maximale dans la construction de votre architecture BI.
Quelle que soit l’approche choisie, une bonne compréhension des besoins métiers et une expertise approfondie des outils Oracle (Oracle Analytics Cloud, BI Publisher, ODI, OIC) seront essentielles pour exploiter pleinement le potentiel des données Oracle ERP Cloud.
SQORUS, expert Oracle Analytics Cloud et ERP Cloud
Chez SQORUS, cabinet de conseil spécialisé dans la transformation digitale des fonctions Finance, EPM et RH, nous accompagnons nos clients depuis plus de 35 ans dans la mise en œuvre de projets Oracle Analytics Cloud et Oracle ERP Cloud.
Notre expertise en Business Intelligence, intégration de solutions Oracle Cloud (OAC, BI Publisher, ODI, OIC) et Data Management garantit des architectures BI performantes, sécurisées et alignées sur vos enjeux métiers.
Vous souhaitez transformer vos données Oracle en levier stratégique et optimiser votre architecture BI ? Nos experts sont à votre écoute. Parlons-en !
Contact
Un projet ? Une demande ? Des questions ?
Contactez-nous dès aujourd’hui et découvrez comment nous pouvons concrétiser ensemble l’avenir du numérique de votre entreprise.
FAQ
Quelle est la différence entre l'approche directe et l'approche classique pour analyser les données Oracle ERP Cloud dans OAC ?
Il existe deux grandes architectures pour exploiter les données d'ERP Cloud dans Oracle Analytics Cloud. L'approche directe s'appuie sur le connecteur natif Oracle Applications pour accéder aux subject areas et rapports OTBI, sans compétences techniques avancées. L'approche classique utilise BI Publisher pour extraire les données des tables sources d'ERP Cloud, les charger dans un datawarehouse via un outil ETL (ODI ou OIC) et les restituer dans OAC, offrant ainsi une flexibilité et une volumétrie illimitées.
Quelle est la différence entre OAC et OTBI dans Oracle ERP Cloud ?
Oracle Transactional Business Intelligence (OTBI) est un outil de reporting natif intégré à ERP Cloud, permettant d'analyser les données transactionnelles en temps réel via des subject areas prédéfinis. Oracle Analytics Cloud (OAC) est une plateforme analytique plus avancée, qui offre des capacités de visualisation, de modélisation sémantique et d'intelligence artificielle, tout en s'intégrant à des sources de données multiples au-delà d'ERP Cloud.
Quelles sont les limites du connecteur natif OAC / ERP Cloud à anticiper avant de se lancer ?
Le connecteur Oracle Applications offre une mise en place rapide et sécurisée, mais présente des contraintes importantes : accès limité aux seuls subject areas et rapports OTBI disponibles, performances dépendantes du cache OTBI sur lequel vous n'avez pas la main, et capacité de stockage insuffisante pour traiter de grosses volumétries. Ces limites peuvent rapidement freiner des projets d'analyse avancée ou multi-sources.
