La plupart des organisations utilisent Oracle Data Relationship Management sur une base cyclique qui correspond à leur calendrier opérationnel ou de reporting. Au sein de chaque période de calendrier, l'utilisation de Data Relationship Management suit un modèle prévisible :
Une nouvelle version de travail Data Relationship Management est créée en tant que copie de la version finalisée à partir de la période précédente. La nouvelle version peut contenir plusieurs hiérarchies (par exemple, pour le plan de comptes, la structure de l'organisation et la structure de produit).
Des modifications sont apportées à la version de travail. Des validations sont automatiquement effectuées lorsque des utilisateurs saisissent ou modifient les données de hiérarchie.
Si nécessaire, des modifications en bloc sur les données de hiérarchie sont exécutées à l'aide de scripts d'action.
A l'approche de la date limite de la période de reporting, la version prend le statut Soumis et les modifications ne sont plus autorisées. Des validations sont effectuées pour garantir l'intégrité des données. Des comparaisons peuvent être utilisées pour identifier les différences entre la version en cours et la version finalisée précédente.
Lorsque l'intégrité des données est garantie, la version prend alors le statut Finalisé et aucune modification n'est autorisée.
Le statut de la version pour la période de reporting précédente peut passer de Finalisé à Expiré, et la version est stockée en vue d'une utilisation future dans des analyses historiques ou sous la forme d'un enregistrement d'audit.
Des exports sont réalisés à partir de la version finalisée pour envoyer les données relatives aux hiérarchies aux systèmes participants. Une fois que tous les exports sont terminés et ont été chargés sur les systèmes de destination, tous les systèmes participants disposent de données hiérarchiques cohérentes qui servent de base au processus de reporting de fin de période.
Les contraintes de workflow organisationnel existantes peuvent être appliquées par Data Relationship Management :
Les règles métier peuvent exiger que tous les nouveaux centres de coûts soient approuvés par le département trésorerie de l'entreprise. Dans ce cas, il est possible d'ajouter une propriété pour indiquer l'approbation, et aucun noeud n'est exporté vers d'autres systèmes tant que le statut de la propriété n'est pas Approuvé. Le département trésorerie de l'entreprise peut se voir octroyer l'accès pour ne mettre à jour que l'indicateur de propriété. Une requête de propriété peut également être définie pour identifier les indicateurs de noeuds.
Les processus de gestion peuvent exiger que toutes les mises à jour de hiérarchie soient redirigées vers un groupe dédié chargé de les implémenter. Après révision et approbation, les changements peuvent être saisis dans un fichier plat en vue d'un chargement en bloc via les scripts d'action dans Data Relationship Management. Cette approche automatisée peut réduire de façon significative les fautes de frappe éventuelles.
Des processus métier plus complexes impliquant la coordination de plusieurs entrées utilisateur et l'approbation avant la validation des modifications peuvent être gérés à l'aide de demandes de modification.
Autres tâches réalisées sur une base irrégulière :
De nouvelles hiérarchies peuvent être définies pour prendre en charge une extension de la portée des systèmes participants. Des hiérarchies peuvent être importées à partir d'une source externe et être directement créées dans Data Relationship Management.
Des hiérarchies peut avoir besoin d'une restructuration pour répondre à la modification des besoins métier. Des versions distinctes peuvent être utilisées pour isoler ces modifications des autres versions de production utilisées pour l'export vers des systèmes d'abonnement.
A l'aide de la fonctionnalité de combinaison, les données nouvellement importées ou restructurées dans différentes versions peuvent être combinées dans la même version avec les autres données de production existantes.