Remarques concernant la conception de dimensions

Conception de dimensions pour créer la structure de l'application

Ajoutez des comptes, des entités et d'autres dimensions en conformité avec votre processus métier.

Les dimensions ont pour fonction de classer les valeurs des données en catégories. Planning est fourni avec les dimensions suivantes : Compte, Entité, Scénario, Version, Période et Années. Si vos planifications impliquent plusieurs devises, votre application comporte également une dimension Devise.

Vous pouvez utiliser la dimension Libre pour définir vos propres valeurs, telles que Produit, Client ou Marché. Vous pouvez avoir un total maximal de 32 dimensions. Toutefois, les meilleures pratiques recommandent d'en inclure moins de 12. Vous pouvez ajouter des dimensions à l'aide d'un fichier de chargement ou les créer dans Oracle Smart View for Office.

Vidéos

Suivi du processus permettant d'identifier les dimensions

Utilisez ce processus pour identifier les dimensions à inclure dans l'application.

1. Identifiez les processus de planification uniques en fonction des exigences.

   Exemple : planification marketing, planification des ventes, planification des frais généraux, panification du capital, planification du flux de trésorerie, planification du personnel

2. Identifiez les dimensions pour chaque processus de planification.

   Exemple : Product, Market, Channel, Product Segment, Customer Segment

3. Définissez les relations entre les dimensions.

   Exemple : Product présente une relation n à n avec Market. Product Segment et Product présentent une relation 1 à n. Labor Resources et Material Resources ne présentent aucune relation.

4. Classez les dimensions par catégorie pour la planification et le reporting.

   Exemple : Product, Market et Channel sont des dimensions de planification, tandis que Product Segment et Customer Segment sont des dimensions de reporting.

5. Mappez les processus de planification avec des modules Planning.

   Exemple : configurez la planification marketing à l'aide de Projects ou de Financials, et configurez la planification des frais généraux et la planification du flux de trésorerie à l'aide de Financials et de cubes personnalisés.

Prise en compte des cas d'emploi courants pour les dimensions

Consultez les cas d'emploi courants pour les dimensions suivants et les recommandations associées.

• Dimensions standard (obligatoires)

  Avec la plupart des cas d'emploi courants et généraux de Financial Planning, vous pouvez utiliser des dimensions standard, qui peuvent être renommées.

• Dimensions libres ou facultatives

  Etendez la dimensionnalité à l'aide de dimensions libres ou facultatives, qui peuvent être ajoutées (activées) ou renommées selon vos exigences.

• Plusieurs hiérarchies dans une dimension

  Combinez au moins deux dimensions sans relation en une seule dimension pour éviter toute non-pertinence interdimensionnelle.

• Hiérarchies alternatives pour la planification ou le reporting

  Utilisez des hiérarchies alternatives lorsque les mêmes membres peuvent être regroupés sous différents parents à des fins d'allocation descendante ou de reporting.

• Dimensions d'attribut pour le reporting

  Les dimensions d'attribut servent à répondre aux exigences en matière de reporting si ces dimensions présentent une relation avec une dimension, qui ne change pas au fil du temps.

• Listes dynamiques et dimensions ASO pour le reporting

  Vous pouvez utiliser des listes dynamiques et des dimensions ASO pour le reporting lorsque la relation entre la dimension de reporting et les autres dimensions change au fil du temps.

• Listes dynamiques et dimensions BSO à cubes multiples pour la planification

  Cette stratégie est utile lorsque la dimension de planification n'est pas la dimension principale d'un processus de planification et qu'elle doit être divisée en sous-processus.

L'exemple de feuille de calcul suivant montre une planification de dimensions avec l'identification des dimensions et leur cas d'emploi.

Consultation d'exemples de stratégie de conception

Consultez les exemples suivants afin de comprendre les stratégies de conception supplémentaires pour les dimensions.

Utilisation de dimensions d'attribut pour le reporting

L'utilisation de dimensions d'attribut pour le reporting peut servir à répondre à vos exigences en matière de reporting. L'attribut présente une relation avec une dimension et la relation entre les deux dimensions ne change pas au fil du temps.

Exemple :

• Définissez un attribut nommé Program sur la dimension Project.
• Vous pouvez ensuite créer une hiérarchie de membres dans la dimension Program. Les membres de niveau supérieur de la dimension Program seront automatiquement agrégés.
• Associez chaque membre de Project à un membre de niveau feuille de la dimension Program dans une règle Groovy d'ajout de projet.
• Vous pouvez ainsi filtrer les projets par programme.
• Les formulaires de rapport peuvent afficher les dépenses et les revenus au niveau d'un programme.

Utilisation de listes dynamiques et de dimensions ASO pour le reporting

Vous pouvez utiliser cette stratégie lorsque la relation entre la dimension de reporting et les autres dimensions change au fil du temps.

Exemple :

• Ajoutez une dimension SkillSet au cube ASO et mappez la liste dynamique SkillSet avec la dimension SkillSet.
• Créez un mapping de données pour déplacer les données du cube BSO vers le cube ASO.
• Le mapping de données peut être exécuté en tant que traitement par lots, ou vous pouvez implémenter la transmission dynamique ou des règles Groovy.
• Vous pouvez utiliser des formulaires de rapport sur le cube ASO pour afficher les besoins en main-d'oeuvre par compétences dans les projets.

Utilisation de listes dynamiques et de la conception BSO à cubes multiples

Cette stratégie est utile lorsque la dimension de planification n'est pas la dimension principale d'un processus de planification et qu'elle doit être divisée en sous-processus.

Exemple :

• Employee et Job sont des dimensions dans Workforce, et des listes dynamiques dans Project Planning.
• Project Planning utilise des détails libres pour planifier les charges de main-d'oeuvre au niveau de Job et d'Employee.

Plusieurs hiérarchies dans une dimension

Vous pouvez utiliser plusieurs hiérarchies dans une dimension. Combinez au moins deux dimensions sans relation en une seule dimension pour éviter toute non-pertinence interdimensionnelle.

Exemple :

• Les dimensions Jobs, Equipment et Material ne présentent pas de relation dans Projects. Elles sont donc combinées en une seule dimension Resource Class.
• Les dimensions Profit Centers et Cost Centers ne présentent pas de relation dans Financials. Elles peuvent donc être combinées en une seule dimension Entity.

Hiérarchies alternatives pour la planification ou le reporting

Utilisez des hiérarchies alternatives lorsque les mêmes membres peuvent être regroupés sous différents parents à des fins d'allocation descendante ou de reporting.

Exemple : créez des consolidations dans la dimension Product pour la planification et le reporting selon la marque et les catégories de produit.

Dix meilleures pratiques principales pour les dimensions

Appliquez les meilleures pratiques importantes suivantes lors de la conception de dimensions.

1. L'ordre des dimensions doit suivre un format de sablier modifié.

   Avec ce format, la dimension la plus dense est en première position, suivie des dimensions moins denses. Doivent suivre les dimensions dispersées, avec les dimensions dispersées agrégées avant celles non agrégées. Au sein des dimensions dispersées, les plus denses doivent se trouver avant les moins denses.

   Avec un cube BSO hybride, l'ordre est identique, sauf que les dimensions dispersées non dynamiques doivent se trouver avant celles dynamiques.

   Pour en savoir plus sur les dimensions denses et dispersées, reportez-vous au tutoriel suivant : Gestion des dimensions dans Cloud EPM.

2. Une grande taille de bloc a une incidence majeure sur les performances.

   La taille de bloc dépend du nombre de dimensions denses et des membres dans ces dimensions. Une taille de bloc optimale est comprise entre 8 ko et 500 ko. Réduisez le nombre de dimensions denses à 3 au maximum. Les niveaux 1 et supérieurs doivent être de type Information seule ou Calcul dynamique pour les dimensions denses.

3. Les comptes de type Texte, Liste dynamique, Date et Pourcentage stocké doivent être définis sur Jamais pour la propriété de consolidation.

   L'agrégation de ces valeurs créera des données inutiles, sauf si les comptes sont explicitement exclus dans un script d'agrégation.

4. Tous les membres de deuxième génération doivent être définis sur Ignorer.

   Vous ne pouvez pas inclure ces membres racine dans les formulaires car vous ne pouvez pas définir la sécurité pour ces membres. L'agrégation des membres de deuxième génération à la racine est donc inutile. De plus, cette opération augmente le nombre de blocs dans l'application.

5. Les dimensions longues ou à plat entraîneront un problème lié aux performances d'agrégation.

   Si plus de 200 membres se trouvent sous un membre parent, ajoutez des parents intermédiaires.

6. L'activation de membres de dimension pour plusieurs cubes créera des références croisées dynamiques et entraînera des problèmes de performances.

   Utilisez l'attribut défini par l'utilisateur HSP_NOLINK pour empêcher la création de références croisées dynamiques. Utilisez des mappings de données ou la transmission dynamique pour déplacer les données entre les cubes.

7. Pour les calculs simples, utilisez les mathématiques d'outline au lieu d'écrire des formules de membre.

   Exemple de calcul simple : Compte C = Compte A - Compte B.

8. Dans la mesure du possible, évitez les membres parent avec un seul enfant.

   Les membres parent avec un seul enfant entraînent la présence de partages implicites ou de blocs ou données en double si le membre parent est défini sur Ne jamais partager.

9. Agrégez les dimensions de grande taille dans le cube ASO au lieu du cube BSO lorsque cela est possible.

   Les performances seront ainsi améliorées, par exemple lors d'une maintenance et d'une actualisation du cube.

10. Stockez les données historiques antérieures à deux ans dans le cube ASO au lieu du cube BSO.

    Si vous disposez de données historiques datant des 5 ou 10 dernières années, toutes les données ne sont pas nécessaires pour les calculs. Si nécessaire, vous pouvez conserver les données historiques des deux dernières années pour les calculs dans le cube BSO et déplacer les autres données historiques vers le cube ASO. Pour des performances optimales, il est recommandé de limiter la taille du cube BSO afin de garantir l'exécution correcte des calculs pour la saisie de données.

Planification de la dimension Entité

La dimension Entité représente votre structure organisationnelle, telle que les centres de coûts, les départements, les unités opérationnelles, les divisions, etc.

Vous pouvez regrouper les centres de coûts en créant des membres de consolidation, appelés parents, qui reflètent la vision de votre organisation. Par exemple, les consolidations peuvent se faire par unité métier, division ou toute autre structure fonctionnelle. A titre d'exemple, vous pouvez créer des centres de coûts qui sont consolidés en unités métier, lesquelles sont consolidées en divisions.

Vous pouvez également créer plusieurs structures de reporting. Par exemple, une autre structure peut être créée pour prendre en charge le reporting régional. Si vos planifications impliquent plusieurs devises, définissez la devise de base de chaque entité.

La dimension Entité est l'une des dimensions principales utilisées pour le processus de budgétisation. Avec les dimensions Scénario et Version, la dimension Entité est utilisée pour définir une unité d'approbation, un composant discret qui peut être promu ou rétrogradé pour approbation ou révision par les homologues d'un utilisateur.

Les membres de toutes les dimensions en dehors de l'unité d'approbation sont promus et rétrogradés en même temps que l'unité d'approbation elle-même. Par exemple, les douze mois sont promus ensemble lorsqu'une unité d'approbation est promue. Les mois ne peuvent pas être promus indépendamment.

Après le chargement ou la mise à jour de chaque dimension, il est recommandé d'actualiser l'application.

Planification de la dimension Compte

La dimension Compte est l'emplacement de votre plan de comptes. Elle doit comprendre les membres concernés par la planification ou la prévision. Elle n'inclut pas nécessairement tous les comptes de votre plan.

Par exemple, votre dimension Compte peut comprendre les comptes pour Compte de résultat, Bilan et Flux de trésorerie. Elle peut également inclure des comptes pour les ICP et les ratios. Dans certains cas, vos comptes peuvent comporter des sous-comptes, mais cela n'est pas habituel.

La dimension Compte englobe l'intelligence financière. Les types de compte suivants sont pris en charge :

• Dépenses : coût du travail

• Revenus : source de revenus

• Actif : ressources de la société

• Passif et capitaux propres : intérêt résiduel ou obligation aux créanciers

• Hypothèse enregistrée : hypothèses de planification centralisées garantissant une certaine cohérence dans l'application

Les paramètres de type de compte sont utilisés pour rapporter les valeurs Trimestriel et Nombre total d'années et pour l'analyse de la variance.

Planning utilise une structure hiérarchique pour créer des sous-totaux et des totaux de groupe de comptes. Un opérateur de consolidation est affecté à chaque groupe de comptes et détermine son mode de consolidation avec son parent.

Exemple :

Résultat net = Total des produits - Dépenses totales

Dans cet exemple, l'opérateur de consolidation pour Total des produits est le "+" et l'opérateur de consolidation pour Dépenses totales est le "-".

La dimension Compte peut être alimentée par un chargement de données ou par l'intermédiaire de Smart View. Pour charger des données à partir d'un fichier, le format de fichier doit respecter des exigences spécifiques.

Après le chargement ou la mise à jour de chaque dimension, il est recommandé d'actualiser l'application.

Meilleures pratiques :

• Les membres de niveau supérieur doivent être définis sur Calcul dynamique.

• Pour les formules de membre utilisées pour calculer les ratios et d'autres types d'ICP ou de pourcentage, définissez-les sur Calcul dynamique, Deux passes. Le paramètre Deux passes calcule correctement les pourcentages aux niveaux supérieurs.

Planification de la dimension Version

Vous pouvez utiliser des versions pour conserver différentes itérations du processus de planification. Les versions sont également utiles pour contrôler l'accès aux données en lecture ou en écriture.

Ces deux types de version sont disponibles :

• Cible standard : les données d'entrée peuvent être saisies aux niveaux supérieurs.

• Version ascendante standard : les données d'entrée peuvent uniquement être saisies au niveau 0.

La fonctionnalité des approbations et du workflow peut uniquement être activée pour les versions ascendantes.

Au titre de meilleure pratique, les versions suivantes sont recommandées :

• En cours : emplacement d'exécution des tâches des utilisateurs, notamment la vérification des résultats réels, et le développement de plans et de prévisions.

• 1ère passe : si vous voulez conserver plusieurs itérations de votre plan, vous pouvez en conserver une dans cette version. Vous pouvez créer d'autres membres si vous avez besoin de plusieurs itérations enregistrées. Vous pouvez utiliser la fonctionnalité Copier les données pour déplacer des données vers cette version. Elle copie les données et les entrées textuelles.

• Simulation : fournit un espace réservé dans lequel les utilisateurs peuvent modifier les hypothèses et analyser les résultats.

Après le chargement ou la mise à jour de chaque dimension dans le processus de création, il est recommandé d'actualiser l'application.

Planification de la dimension Devise

Si vous avez activé plusieurs devises pour votre application, vous pouvez ajouter les devises que vous utilisez pour la planification et le reporting.

Vous pouvez ensuite définir des taux de change par scénario et année à utiliser dans les conversions. Un script de calcul est créé pour vous permettre de convertir les devises. Pour saisir des taux de change, suivez le processus décrit dans la section Spécification de taux de change dans Administration de Planning.

Meilleures pratiques :

• Limitez le nombre de devises de reporting. En règle générale, les clients n'en ont qu'une.

• Entrez les taux de change pour chaque combinaison scénario-année valide.

• A partir de là, la conversion de devises peut être calculée en exécutant la règle métier Calculer les devises associée par défaut à chaque formulaire.

• Le type de taux de change d'un compte est modifié, par exemple de Fin à Moyen.

Exécutez le script de calcul de conversion de devises avant les opérations suivantes :

• Examiner les données locales mises à jour dans les devises de reporting

• Exécuter certains calculs qui peuvent être dépendants des données de devise de reporting

Planification des taux de change

Chaque application possède une devise par défaut que vous définissez lors de sa création. Lorsque vous configurez des tables de taux de change, vous saisissez les taux de change de toutes les devises source vers la devise par défaut. La triangulation est utilisée pour la conversion vers toutes les autres devises de reporting.

Les taux de change sont définis par scénario et par an pour les taux moyens et de fin.

Planification de la dimension Période

Utilisez la dimension Période pour établir la plage de calendrier au sein d'une année donnée, par exemple, par mois.

Meilleures pratiques :

• Utilisez des variables de substitution pour cette dimension pour prendre en charge le reporting et les calculs. Les variables de substitution potentielles sont CurrMo, CurrQtr et PriorMo. Ces variables doivent être mises à jour chaque mois.

• Pour utiliser des calculs de période, tels que Cumul annuel ou Cumul trimestriel, sélectionnez l'icône de série chronologique dynamique dans la dimension Période. Vous pouvez ensuite sélectionner les calculs de période dont vous avez besoin pour votre processus.

• Les périodes de récapitulatif, telles que les totaux trimestriels, et le total annuel doivent être définis sur le calcul dynamique afin de réduire le temps de calcul.

• Après le chargement ou la mise à jour de chaque dimension, actualisez l'application.

Planification des années et des variables de substitution

Les années sont intégrées à de nombreux emplacements de l'application, notamment les formulaires, les calculs, les rapports et Smart View. Etant donné que vous allez utiliser l'application pendant de nombreuses années, la meilleure pratique de référencement de cette dimension consiste à utiliser une variable de substitution.

Les variables de substitution servent d'espaces réservés globaux pour les informations qui changent régulièrement. La variable et la valeur correspondent à l'année, et la valeur peut être modifiée à tout moment.

La valeur de la variable de substitution est affichée sur les rapports et les formulaires sous la forme d'un espace réservé. Ceci permet de réduire la maintenance de l'application.

Au titre de bonne pratique, créez des variables de substitution pour chaque année incluse dans votre processus. Par exemple :

• CurrY, Année en cours

• NextYr, Année (contractuelle) budgétaire

• PriorYr, Année précédente

Conception de dimensions libres

Vous pouvez utiliser une dimension libre pour catégoriser autrement vos données. Par exemple, les dimensions libres peuvent inclure Produit ou Marchés.

Gardez à l'esprit que les autorisations d'accès ne peuvent pas être attribuées au niveau de la dimension, également appelée première génération. Par exemple, il n'est pas possible d'attribuer directement des autorisations d'accès au membre Produit pour tous les descendants. Si vous activez la sécurité pour votre dimension libre, il est recommandé de concevoir une deuxième génération pour toutes les dimensions libres auxquelles la sécurité sera appliquée avec les affectations d'accès de sécurité en tête.

Après le chargement ou la mise à jour de chaque dimension, il est recommandé d'actualiser l'application.

Meilleures pratiques supplémentaires

Effectuez les tâches suivantes après avoir ajouté ou mis à jour des dimensions.

• Actualisez l'application.

  Vous devez actualiser l'application chaque fois que vous modifiez la structure de l'application.

  Les modifications apportées à l'application ne sont visibles par les utilisateurs qui effectuent des tâches de saisie de données et d'approbation qu'une fois l'application actualisée.

  Par exemple, lorsque vous modifiez les propriétés d'un membre Entité, ajoutez un scénario ou changez les autorisations d'accès, ces modifications ne sont visibles pour les utilisateurs qu'après actualisation de l'application.

• Chargez les données historiques.

  Après avoir chargé toutes vos structures, telles que les comptes et les entités, vous pouvez charger les données historiques. Il peut s'agir de données issues des résultats réels de l'année précédente, et du plan et du budget de l'année en cours.

  Le chargement de données historiques permet aux utilisateurs d'analyser les résultats, d'examiner les tendances et d'effectuer des comparaisons significatives.

  Cette opération aide également à vérifier les structures que vous avez créées dans votre application. Par exemple, vous pouvez vérifier le lien des données avec les rapports précédemment créés. Si les données ne peuvent pas être rapprochées, vous devez vérifier si un problème de données en est la cause ou s'il existe un problème au niveau des structures.

  Créez une règle d'agrégation pour que les données consolidées puissent apparaître dans votre application.

• Planifiez des croisements valides.

  Les croisements valides permettent aux administrateurs de service de définir des règles appelées règles de croisement valide qui filtrent les croisements dimensionnels pour les utilisateurs lors de la saisie de données ou de la sélection d'invites d'exécution. Par exemple, vous pouvez indiquer que certains programmes sont valides uniquement pour des services spécifiques. Utilisez les croisements valides pour contrôler que la saisie de données s'effectue uniquement sur ces croisements.

  Lors de la conception de formulaires, gardez à l'esprit les points suivants pour les croisements valides.

  • Si des dimensions avec des croisements valides figurent sur la page, seules les combinaisons valides sont présentées à l'utilisateur dans le sélecteur de membres.
  • Si des dimensions avec des croisements valides figurent dans la colonne ou la ligne, le concepteur de formulaire peut supprimer totalement les croisements non valides. Lorsque l'option de suppression n'est pas sélectionnée, les croisements non valides sont définis en lecture seule.