Chart of Accounts

Oracle updates and enhances EPM System Release

A brief blog this week given the Easter holidays.

Great news that Oracle has just announced the formal release of a DRM template for EBS which we reviewed last August.

This template provides out of the box integration to Oracle E-Business Suite (EBS) and will reduce the implementation costs of implementing Oracle Hyperion Data Relationship Manager (DRM) to control your chart of accounts.

We’ll be back next week with hopefully a case study on a recent DRM implementation.


Tagged , , ,

Webcast | Is Chart of Accounts Management Costing You More Than It Should?

This free webcast will be happening at 1pm (GMT) on Tuesday 17 April 2012 and will show how you can save 1000’s of man days effort yearly by centralising Chart of Accounts management and building efficiencies into your organisation by eliminating Human Middleware and automating your process.  Register here

Any good business knows the importance of having a well-aligned Chart of Accounts (CoA) to enable effective analysis, reporting and decision-making. But manually organising data and meta data from fragmented systems can be a complex and costly process damaging data integrity, impeding financial controls, and driving up costs.

Oracle Hyperion Data Relationship Management (DRM) allows you to seamlessly integrate chart of accounts and other meta data from multiple systems, simplifying data analysis and delivering reliable information to all your decision-makers.

Seismi have been invited by Oracle to discuss relevant case studies and explain how to avoid common project errors, and show how you can:

  • Increase efficiency with proven best practices in CoA design and maintenance;
  • Accelerate ERP upgrades and consolidations with a streamlined CoA;
  • Mitigate governance risk by consolidating disparate systems into a single, unified view; and
  • Gain a clear financial understanding of acquired companies with rapid analysis of critical information.

The webcast will be useful for the following:

  • Financial Controllers;
  • Financial Directors;
  • Finance Managers;
  • Finance Systems Managers; and
  • Anyone involved or embarking on any finance systems transformation program!

Don’t miss this opportunity to see how you can prevent Chart of Accounts management from costing you more money than it should.

Tagged , , , , ,

Video | Using Masterdata Governance to overcome Business Challenges (Part 1)

This week Ross Gilfillan will be introducing the start of a series of video blogs that explore how masterdata governance, using Hyperion Oracle’s Data Relationship Manager (DRM) tool, can be used to overcome a number of common business challenges.

These challenges include ongoing governance of disparate and distinct chart of accounts; integrating acquisitions; implementing and updating charts of accounts; and mapping.

Over the next few weeks Ross will look in detail at how Oracle Hyperion DRM can be used to govern Oracle’s E-Business Suite, Hyperion Financial Management and Hyperion Essbase.

Please do contact us if you would like to explore these topics in more detail. Ross’s contact details are also included at the end of the video.

Tagged , , , , , , , ,

Chart of Accounts Conversion | Common Pitfalls (Part 2)

Last week we looked at the fundamental challenges associated with chart conversion projects. This week we thought that it would be useful to identify the common pitfalls that we see repeatedly. These include:

  • Treating accounting policies and practises as an afterthought – Many organisations only consider accounting policy very late in the project cycle, when either looking at standardising month-end processes or like-for-like reporting.  However, even a small accounting policy change can have a fundamental impact on your standard chart of accounts. For instance, a small change to how overhead costs are allocated could impact on the chart design, ERP logic, month-end close process or EPM design. As such accounting policy should be agreed as one of the first tasks of your project rather than one of the last;
  • Defining code logic before understanding reporting requirements – Often we see organisations define their standard chart first, and then define their report requirements. This creates an iterative process as every change to report requirements has to be reflected in the chart. This gradually  invalidates the code logic and creates rework. Reporting requirements should be prioritised so that there is a definite understanding of requirements prior to defining the code logic, therefore ensuring your new chart is fit for purpose. Your report requirements should then be validated by the business, using real data, before creating your chart logic and codes; and
  • Big Bang doesn’t work – As mentioned last week, coping with the impact of change on your budgeting and consolidation systems is one of the major challenges of a SCoA project. A common pitfall is to attempt to change your chart in your ERP and EPM applications at the same time. This greatly increases the complexity of your initiative, puts increased pressure on your project resources and can create a highly iterative chart design process. Changes required to meet planning requirements drive changes to the chart design and vice versa.  This is a difficult cycle to stop and will prove expensive and frustrating.

If you would like to understand any more about our approach, methodology or company, then please give us a call.

Tagged , , , ,

Chart of Accounts Conversion | The Challenges (Part 1)

Standard chart of accounts (SCoA) conversion projects have the potential to be complex and risky. As such we thought it would be useful to investigate chart conversion over two blogs, starting this week with some of the following fundamental challenges:

  • Business Engagement – SCoA initiatives tends to arise when a legacy chart of accounts has become unwieldy through uncontrolled change whether dictated by mergers and acquisitions (M&A) or organic growth.  This change in business focus results in the need for better financial processes and reporting and often results in a SCoA project (although this is not the only option, but we will save that for a later blog).   The new SCoA needs to be ratified by multiple areas of an organisation, all fighting for their specific needs to be addressed.  Without careful management, this can become a very iterative process and the results can be an aggregated chart as opposed to a truly standardised structure;
  • Validation – Whilst it is an accepted fact that each area in the organisation will fight for its specific needs to be addressed, they are usually reluctant to sign off the chart until they see the impact on their reports and month end processes. In most cases, these numbers are only produced after a trial conversion to the new standard chart (with all the pain that accompanies that process). In our experience this is too late in the process and can result in many expensive iterations and trial conversions;
  • Satellite Systems Impact – A chart conversion will usually affect the interfaces between your various financial applications. In the worst case this can invalidate the design of existing consolidation, reporting and planning applications. Trying to change the interfaces and re-implement all of these applications whilst changing your chart of accounts dramatically increases the scope, complexity and risk of a SCoA project. Devising an effective approach to managing the impact of a chart conversion on your satellite applications is a major challenge for a SCoA project; and
  • Change Management – The existing financial applications continue to change during the CoA design and conversion process. This creates a challenging masterdata governance problem as masterdata created  during this period needs to be extracted and included in the design process. This creates multiple versions of the truth and can create a real headache for the design team. Similarly, managing multiple versions of SCoAs, report definitions, and mapping files is difficult.

Next week we will look at some of the common pitfalls of chart conversion.  If you would like to find out more about howSeismi helps our clients tackle these challenges, then please do not hesitate to get in contact.

Tagged , , ,

Governing EBS | Using Masterdata Governance to solve the 'Human Middleware' Problem (Part 2)

Following on from last week’s blog article where we discussed the issue of ‘human middleware’ this week we want to examine three of the typical challenges that our over-worked “human middleware” have to contend with.

1) Manual Governance – forecasting, consolidation and reporting systems typically use dimension structures that are derived from the Oracle E-Business Suite (EBS) chart of accounts, but which are customised depending on the specific system.  For example, a planning solution may require additional masterdata to support driver based budgeting.  Our poor human middleware has to understand the differences between each of the satellite applications and EBS; ensure completeness of mapping tables;  and finally prove data passed between the necessary application and EBS reconciles (usually supported by nothing more than a trusty spreadsheet that very few people understand and the burning of some serious midnight oil);

2) Report Definitions – obviously reporting happens at every level of an organisation: from an individual line manager reporting on his specific area of responsibility, to the CFO trying to understand the financial direction of his company.  Each of these reports may be produced from separate reporting tools storing different definitions for key reporting constructs. (e.g. revenue).  This poses our downtrodden human middleware with a new set of issues, principally trying to align definitions across multiple reporting applications and then explaining any differences to the user community; and, finally

3) Integration – non-Oracle subledgers often share masterdata with EBS.  These subledgers should be made aware of any changes in valuesets, but also need to respect the business rules in EBS, specifically around valid combinations.

As you can see, our poor, embattled ‘human middleware’ could do with a hand.  Their lives would be made considerably easier if they had a single tool capable of understanding and storing structures, properties, mappings and relationships associated with their core masterdata in a single location, as well as automating these processes. Masterdata governance is the tool that can provide a real boost, not only to their working lives and overall productivity, but also to improve the quality of information reported as well as the ability of your company to react to inevitable change.

Tagged , , , , ,

Governing EBS | Using Masterdata Governance to solve the ‘Human Middleware’ Problem (Part 1)

Oracle E-Business Suite (EBS) has in-built functionality to maintain a chart of accounts. This includes: defining the segment structure of the chart of accounts; the value sets; creating basic reporting terms using parents and summary accounts; controlling the relationships between segments (using either cross validation rules or a combinations table).

So why bother with governing EBS? Very few EBS instances operate in isolation. For example, you need to forecast, consolidate and report using the data in the EBS General Ledger, and you need to load data from your forecasting systems and non-Oracle subledgers into EBS. The number of interfaces can be truly breath-taking yet for many large companies this business problem is managed using ‘human middleware’: accountants who spend month-end extracting and transforming data in spreadsheets to load into other systems, followed by reconciliation, error checking, re-running  and more reconciliation…

This reliance on ‘human middleware’ has a pervasive effect on the finance function:

  1. Reduction in analysis – By focusing on data transformation, reconciliation and report creation, the finance function surrenders its role as proactive business analysts who direct the strategy of the organisation and who are first to identify and react to tactical threats and opportunities;
  2. Obstacle to change – The consequence of the highly manual month end process is that the finance function is reluctant to change the way the business is measured or forecast because of the additional risk and addition effort this entails. The finance function thus unwittingly becomes an obstacle to change, rather than the champion it should be; and
  3. Loss of confidence – ‘human middleware’, despite incredible dedication, inevitably results in errors. As a result, the business starts to doubt finance function reports and starts performing its own reconciliation, data collection and analysis…

In next week’s blog we will explore what we see as the three key issues of manual governance, report definitions and integration as well as how masterdata can provide a real solution to ‘human middleware’.

Tagged , , , , ,

Masterdata Workshops with Oracle | London (October 2011)

Seismi are partnering with Oracle to host a series of masterdata workshops for customers to discuss their key pain points relating to masterdata governance and systems integration. Each workshop will be attended by a single customer to ensure they can discuss their issues in confidence.

These focused workshops will be collaborative working sessions with Seismi and Oracle working through the prospective customers’ challenges and giving them guidance based on Seismi’s “real world” implementation experience.

They are taking place on 10th and 11th October and each organisation will be assigned a 90 minute session.

Who should attend

Organisations with one or more of the following requirements would benefit from attending:

  • Acquisitive – which intend to grow through acquisition, but do not have a solution in place to deploy a standard financial reporting, budgeting and consolidation solution quickly and easily;
  • Standardisation – keen to standardise reporting across multiple business entities;
  • Governance – keen to gain control over account creation in their ERP instance;
  • Integration – running multiple ERP systems which need to report on a single standard;
  • Reporting requirements – need to report against multiple standards;
  • Chart – looking to create a Standard Chart of Accounts; or
  • Process review – about to embark on a financial transformation project.

In addition, we would be delighted to see organisations, which are experiencing one or more of the following problems:

  • Cost reduction – High cost of ownership associated with maintaining and running EPM and ERP solutions;
  • Errors – Error prone integration between EPM and ERP solution;
  • Manual intervention – Manual, multiple step business processes with multiple failure points; or
  • Error trapping – Process driven by reactive error trapping.

Book your place

To reserve your place or discuss the workshop in more detail then please contact us directly, or alternatively give your Oracle EPM Account Manager a call.  See you there!

Tagged , , , ,

Breaking the Master-Slave relationship

Large organisations typically have multiple masterdata silos, each containing core business hierarchies.  Each silo addresses an individual business need and tends to be controlled by separate individuals within the organisation. For example, there will be separate teams responsible for the general ledger, budgeting systems, reporting systems and consolidation systems. Indeed the challenge is often greater than this, with different divisions of the organisation maintaining completely independent Chart of Accounts (CoA).

The relationship between these applications and teams is often hierarchical, with those higher in the organisation forcing change to those lower down. This can be termed a master-slave relationship and results in significant problems for any organisation. Changes to the master system drives reactive change to slave systems and changes to the slave systems jeopardises the integrity of the numbers reported. The result is a manual and inefficient process with all changes requiring significant testing prior to implementation.

Organisations can solve this problem in a number of ways.  The larger service providers  would advocate a change and conversion program to the underlying ERP and EPM solutions.  This approach is often unwieldy, lengthy and requires significant change management.  More importantly it is incredibly costly.  If the main objective of your organisation is to standardise financial reporting, not to align business processes and technology, then a far more effective and cheaper approach is to implement a governance and change management process that aligns reference data between the various silos.  These governance solutions enforce business rules, run pre-emptive checks against related data and will highlight the impact of a change on all systems.

Oracle Hyperion Data Relationship Manager (DRM) is a very powerful masterdata management tool that can be used for this purpose and Oracle Hyperion DRM allows organisation to centralise and standardise their masterdata into a single location.

Tagged , , , ,

Hyperion DRM enables robust governance and reporting

This week we thought we would share a brief video that shows a recent implementation where Seismi managed to use Oracle Hyperion Data Relationship Manager (DRM) to create a Finance Hub for a large corporate client. This enabled the client to achieve the following:

  • govern a general ledger containing disparate charts of accounts;
  • model a standard set of reporting structures covering both financial and non-financial information;
  • control the mapping between the general ledger, a standard view of the business, as well as consistent reports definitions for all business units; and
  • create a set of standard reports that could be delivered to SAP Business Objects and Oracle’s Essbase (or any other reporting tool for that matter!).

The benefits of this approach were wide-ranging and included the following:

  • Control of the core general ledger and reporting structures was placed in the hands of the business users;
  • Business rules were deployed to ensure that these users proactively considered the impact of general ledger changes on core financial reports at the point of entry;
  • Reconciliation between applications has been removed as Hyperion DRM enforces the necessary mappings; and
  • Month-end processing time has been significantly reduced because users have confidence in the figures being reported.

This project delivered a truly robust approach to governance and reporting by integrating the general ledger with the client’s Enterprise Performance Management requirements.

Tagged , , , , , ,