Data Relationship Governance

ICAP Gains Robust Control Over Financial Master Data with Oracle Enterprise Data Governance Solution

Seismi are excited to share a recent press release announced by Oracle about our successful implementation of Oracle Data Relationship Management (DRM) and Oracle Data Relationship Governance (DRG) at ICAP. Oracle confirms that the ICAP implementation of DRG is the first in the United Kingdom.

You can find the press release here.

Tagged , , , , , ,

Seismi Sponsor Oracle DRM SIG

Event date: 24th March 2015Seismi Clients_Blog_Sidebar_DeBeers
Event Location: Oracle City Office, One South Place, London EC2M 2RB

We are pleased to announce our continued support for the Oracle DRM Special Interest Group (SIG).

Oracle is hosting the event and Seismi will be presenting a customer use case. The De Beers Group of Companies is in the process of implementing Oracle DRM and FDM to optimise the relationship between their extensive collection of general ledgers and their consolidation tool, HFM. They will be sharing their story to date, outlining their use case, their solution and the benefits they are expecting the solution to bring. They will also highlight any pitfalls and lessons learnt from their project.

For further information on, and to register for the event, please click here.

Spaces are limited so please register as soon as possible to join us.

Tagged , , , , , , ,

DRM and DRG - 11.1.2.4

As you probably know by now, Oracle have released DRM 11.1.2.4. The first thing that strikes me is that this new version comes with a new look. The buttons and elements are in the same place but the colours and theme have been updated to give it a new, clean look. The next thing we noticed is that overall performance seemed better. Oracle have implemented a new improved architecture optimized for multi-processor deployments on 64-bit hardware. The trade-off is that this new version is no longer compatible with Windows 32 bit operating systems. Applications now use a single engine and server to reduce the overhead linked with the multi-engine architecture of previous versions. The result is an application capable of handling much more concurrent processes with less hardware.

The new features delivered in this new version can be divided between DRM and DRG.

DRM New Features

To start, we had a look at the new hierarchy group exports feature. In DRM you can now define exports that will run on all the hierarchies within a specific group. These exports will always run from the top node of all the different hierarchies. You cannot select a specific branch as you can in normal exports. This can be remediated through the effective use of filters. This new feature can be very useful for companies who are governing their chart in E-Business Suite or Fusion from DRM as it will make it a lot simpler to define which hierarchies should be published to the value sets.

The second feature worth noting is that DRM imports now support reverse lookups. This means you can take advantage of lookups tables you have defined. The goal here is to have one single point where you can define the relation between a system attribute and it’s meaning for the users. So for example, Account Types are stored in E-Business Suite as single characters (“A”, “L”, “E”, “R”…). In DRM you can have a user friendly property for the account type (“Asset”, “Liability”, “Expense”, “Revenue”…) and a lookup property to transform that to the E-Business Suite format. Thanks to these reverse lookups, you can import the chart of accounts from E-Business Suite with the single character and the reverse lookup will automatically understand that “A” means that your user defined account property should be set to “Asset”. This feature may not seem like a major breakthrough but it is down to the core goal of Master Data Management, centralising definitions in a single location.

Other noteworthy new features include substitution parameters in imports and exports to use runtime parameters, dynamic columns in exports to add columns without creating new properties, imports with no sections to ease the integration with upstream systems and the ability to set node types and validations assigned to an imported hierarchy within the import definition. These will all make the integration simpler to create and manage.

DRG New Features

Just as the general DRM interface, DRG requests have changed look. Requests now contain different tabs to view items, comments, attachments, participant’s details and activity. Information is easier to access and yes, you can now attach documents to a request! DRG now also supports custom labels and property instructions so you can adapt the label of a property to the specific workflow and add instructions for that property. These small changes go a long way in making requests clearer for all the different stakeholders. Another important new feature is the separation of duties option that enables workflows to enforce that an approver cannot have participated in any previous stage of the request. This is a good simple way to force that every request is reviewed by at least two pairs of eyes!

The main new feature that many of us working with DRG have been waiting for is also included in this release: conditional stages. When building a workflow, you can now assign conditions to the execution of a stage. The condition can be based on properties or the result of validations and you can also chose to apply the stage to the full request if at least one item meets the condition or to split the request and apply the stage only to the relevant items. This new feature does exactly what it needs to.

The next feature we tested is the request from file option. This allows users to create a request with multiple items from a file. The theory here is that a user can prepare a large request in a spreadsheet, save it in the correct format and load it into a request. DRG requires that similar commands are grouped into independent files. These files can then be loaded and combined into one request. In practice this feature was a little disappointing; it does not look like you can automate this load into the DRG queue. As a result a third party system can generate a load file but cannot automatically submit the identified changes into the DRG process for onward processing. Hopefully this limitation will be addressed soon.

Note – After publication of this post, we were contacted by Oracle to let us know that it is possible to trigger the load of a file containing items of a DRG request from a batch file. The batch parameters required to do so were just missing from the documentation. This is great news as it means we will be able to automatically import master data from a third party system then trigger a set of requests to ensure that master data is enriched as required. Users will simply arrive in the morning and find the required actions waiting in their inbox. We will be testing and posting a review of that feature soon.

Finally, one point worth noting is that DRG is going mobile. This release is compatible with the Oracle EPM app which allows users to review and action DRG requests in their inbox directly from their tablet or smartphone. This same app can also allow you to interact with Hyperion Financial Management, Planning, Tax Provision and Financial Close Management. Obviously, access through a smartphone or tablet will depend on each company’s security policy and we would always recommend ensuring that these clients have the appropriate protection before allowing them to interact with core financial applications. However, provided this is done, this shows how Oracle is adapting to the new ways we work and interact.

As a conclusion, this may not be a ground-breaking release like 11.1.2.3 when Oracle introduced the new DRG workflow and JavaScript derived properties and validations. It feels more like a natural evolution of 11.1.2.3 into a finer tuned version. The improved architecture, the new clearer layout of information in DRG requests and the new conditional workflow stages are reason enough to look at adopting 11.1.2.4.

 

Tagged , ,