Every organization has a process for managing its data. It’s a must in today’s digital world. We all know this, but we also know that many organizations struggle with their data management processes. Especially those organizations that rely on common, multipurpose tools to do so. Email, phone calls, Excel spreadsheets, and ticketing systems can help facilitate the process, but usually lack in one area or another as sufficient workflow programs. And if the tools aren’t bad enough, the process for reviews and approvals can be just as frustrating. For many data managers, managing the process and the people involved in that process is a full time job in itself.
In terms of enterprise dimensions and hierarchies, Oracle DRM provides an easy-to-use solution — DRG (Data Relationship Governance). DRG provides workflow capabilities for governing the hierarchies within DRM. DRG workflows can be customized to meet the many different needs of an organization. Have a process that requires multiple approvals, from multiple groups? DRG can accommodate that. Have a process that requires additional information to be provided downstream of the initial request? DRG can accommodate that also. Or maybe you have a process requiring the request to be routed to different individuals based on certain criteria? DRG allows for that too. It’s very flexible and allows for a high degree of customization. So let’s take a look at an example of a completed DRG request to get an overview of the module.
After logging into DRM, the DRG module can be accessed by clicking Worklist from the Tasks menu on the left hand side. Within Worklist, several views (Assigned, Urgent, Overdue, etc.) exist for the Requests that the user has rights to in the application. All additional DRM Tasks (such as Browse, Query, etc.) that the user has access to are presented below the Navigate menu.
In the top-middle pane of the screen users are presented with a list of requests based upon the view that has been selected. The details of the selected request are presented in the middle pane, just below the list. Next, the Request Activity section displays the audit log of the selected request. An entry in bold represents a comment entered by a user at some point in the workflow.
Users can open a request by double-clicking it from the list. The request opens in a new tab within the application. Requests contain several tabs within themselves. The Request Items tab displays what is being requested (e.g. new account, move to a new parent, etc.). It’s worth noting that multiple items can be contained within a single request. The properties associated with the selected request item are displayed in the Item Details section in the bottom pane.
Next is the comments tab which provides a list of all the comments entered so far, and the ability to enter new comments. The attachments tab provides a list of the files attached to the request (these are usually support documents for the change being requested). The participants and activity tabs present information about the history of the request.
On the right side of the screen we see the Workflow Path. This lists out the various stages of the workflow. Workflows always begin with a Submit stage and end with a Commit stage. An Enrich stage allows for users to modify the request in some way, such as populating properties, downstream from the initial submission. Approval stages are just that, approval/rejection only.
Submit, Enrich, Approve, Commit — These are just the standard names for the stages. Each can be customized to read something entirely different to meet any organization’s needs. A common example is renaming the Commit stage to “Final Approval”.
Green check-marks signify that the request has passed successfully through those stages of the workflow. The current stage is listed in bold. The changes being request are not applied to the hierarchies in DRM until the request passes through the final stage (i.e. the Commit stage). Just above the Workflow Path is a section titled Workflow Tags. Tags allow users to mark requests as urgent and/or provide a due date.
This concludes our introductory overview of the DRG module within DRM. Stay tuned for the next post where we process a new request through the workflow!
Missed part of this series? Here are the previous installments:
Why Oracle DRM is Essential for Managing Master Data (Part 1)
Why Oracle DRM is Essential for Managing Master Data (Part 2)
Why Oracle DRM is Essential for Managing Master Data (Part 3)
Why Oracle DRM is Essential for Managing Master Data (Part 4)
Nice tutorial. The Oracle Hyperion DRM tutorial was help ful for me. Keep Sharing Tutorials.