Lebenszyklus von Data Relationship Management-Versionen

Die meisten Organisationen verwenden Oracle Data Relationship Management auf einer zyklischen Basis, die mit ihrem Betriebs- oder Berichtskalender abgestimmt ist. Innerhalb einzelner Kalenderperioden lässt sich bei der Verwendung von Data Relationship Management ein vorhersehbares Muster feststellen:

  1. Eine neue Data Relationship Management-Arbeitsversion wird als eine Kopie der abgeschlossenen Version aus der vorherigen Periode erstellt. Die neue Version kann mehrere Hierarchien enthalten (z.B. das Kontendiagramm, die Organisationsstruktur und die Produktstruktur).

  2. Änderungen werden an der Arbeitsversion vorgenommen. Validierungen werden automatisch ausgeführt, wenn Benutzer Hierarchiedaten eingeben oder ändern.

  3. Gegebenenfalls werden Massenänderungen an Hierarchiedaten vorgenommen, indem Aktionsskripte verwendet werden.

  4. Kurz vor dem Termin der Berichtsperiode wird der Versionsstatus in "Übergeben" geändert, und Änderungen sind nicht mehr zulässig. Validierungen werden ausgeführt, um die Datenintegrität sicherzustellen. Vergleiche können verwendet werden, um Unterschiede zwischen der aktuellen und der vorherigen abgeschlossenen Version festzustellen.

  5. Nach dem Sicherstellen der Datenintegrität wird der Versionsstatus in "Abgeschlossen" geändert, und weitere Änderungen sind nicht zulässig.

  6. Der Versionsstatus für die vorherige Berichtsperiode kann von "Abgeschlossen" in "Abgelaufen" geändert werden, und die Version wird für eine mögliche Verwendung in der Zukunft in historischen Analysen oder als ein Auditdatensatz gespeichert.

  7. Exporte werden von der abgeschlossenen Version ausgeführt, um Hierarchiedaten an die beteiligten Systeme zu senden. Nachdem alle Exporte abgeschlossen sind und in die Zielsysteme geladen wurden, weisen alle beteiligten Systeme konsistente hierarchische Daten als Basis für den Prozess der Berichterstellung am Ende der Periode auf.

Vorhandene organisatorische Workflow-Beschränkungen können von Data Relationship Management erzwungen werden:

  • Geschäftsregeln erfordern möglicherweise, dass alle neuen Kostenstellen von der Finanzverwaltung genehmigt werden. In diesem Fall kann eine Eigenschaft hinzugefügt werden, um die Genehmigung anzugeben, und Knoten werden erst dann in andere Systeme exportiert, wenn der Status der Eigenschaft in "Genehmigt" geändert wird. Der Finanzverwaltung kann eine Zugriffsberechtigung ausschließlich für die Aktualisierung der Anzeigeeigenschaft erteilt werden. Außerdem kann eine Eigenschaftsabfrage definiert werden, um die Anzeigeknoten zu identifizieren.

  • Geschäftsprozesse erfordern möglicherweise, dass alle Hierarchieaktualisierungen an eine bestimmte Gruppe weitergeleitet werden, die für die Implementierung solcher Aktualisierungen zuständig ist. Nach der Überprüfung und Genehmigung können die Änderungen für das Massenladen über Aktionsskripte in Data Relationship Management in eine Flat File eingegeben werden. Durch diese automatisierte Methode werden Schreibfehler erheblich verringert.

  • Komplexere Geschäftsprozesse, die die Koordination mehrerer Benutzereingaben und vor Änderungsübergabe eine Genehmigung umfassen, können mit Änderungsanforderungen verarbeitet werden.

Andere Aufgaben werden unregelmäßig ausgeführt:

  • Neue Hierarchien können eingerichtet werden, um eine Bereichserweiterung der beteiligten Systeme zu unterstützen. Hierarchien können aus einer externen Quelle importiert oder direkt in Data Relationship Management erstellt werden.

  • Hierarchien müssen möglicherweise neu strukturiert werden, um sich an neue Geschäftsanforderungen anzupassen. Mit getrennten Versionen können diese Änderungen von anderen Produktionsversionen, die für den Export in Abonnementsysteme verwendet werden, isoliert werden.

  • Mit der Kombinationsfunktion können in verschiedenen Versionen neu importierte oder neu strukturierte Daten mit anderen, vorhandenen Produktionsdaten in derselben Version kombiniert werden.