Streamlining Audit Compliance Reporting

Where were you when the first reports of the forthcoming bankruptcy of Enron began to surface?  I was in Stamford, CT in a Hyperion training class.  I realize that it is odd that I remember that but clearly this event proved pivotal.  The resulting Sarbanes-Oxley (SOX) Act of 2002 redefined the landscape of the business world and subsequently financial systems.  One of the most significant portions of the Act was Title III which mandates that senior executives take individual responsibility for the accuracy and completeness of corporate financial reports.1

With the introduction of SOX, the corporate veil had been pierced and senior executives needed to ensure that the financial results of the organization were accurate.  Failure to do so could result in government fines, depressed share price, loss of job and even possible incarceration.  This legislation launched a number of company wide initiates to ensure SOX compliance.  As you might imagine, Oracle/Hyperion production applications as well as planned projects were enhanced and expanded to support these new requirements.  At the same time, Hyperion & each of its partners was working to enhance their software to assist organizations with these new compliance requirements.

In version 7 of the WebLink release, Upstream Software introduced the Process Explorer module.2  This is the elusive 5th step (Last Step) that I referred to in my post Using the Check Report to Proactively Identify Data Quality Issues.  Simply stated, Process Explorer allows a user of FDM to answer a series of questions related to their financial data and certify that the answers are true, accurate and complete.  The answers to each questionnaire & its sections are recorded in the FDM database and can subsequently be reported against and used to support SOX reporting requirements.

Below are the elements of the Process Explorer:

Component Purpose
Group Top level grouping. Contains individual sections. Examples are Financial Statements, Accounts Payable, Accounts Receivable.
Sections Grouping of types of questions.  These are subsets of groups.  For example, the Financial Statements group may have a section for Review and another for Completeness.
Questions List of questions that need to be answered for each section.
Profiles The collection of Groups assigned to a location.
Reviewers The person that is responsible for answer the questions in each section of a profile.  Each group within a profile may have a different reviewer.
Submitters The person that is responsible for the final sign off of the assessment or certification for the location.
Proxy A person that may complete the review or submission in the event the primary person is unavailable.

The Last Step process can be assigned to any location in FDM.  Generally the Last step cannot be invoked until the Check workflow step executes and the result is a Pass.  The Last Step/Process Explorer loads in a separate module.  The list of questions that need to be answered for each section for which the Reviewer is responsible are displayed.  Each question can be answered with a Yes, No or NA (Not Applicable) response and also allows for commentary to be entered to explain an answer.  Once all questions for a section are answered the Reviewer can promote that section to the Submitter.

In addition to the questionnaire, the Process Explorer allows a Reviewer or Submitter to attach supporting documents.  These are stored in the FDM repository and can be retrieved at any time.

The Submitter can review the answers provided by the Reviewer for each section.  This can be done within the Process Explorer or from Reports module of FDM.

Once the Submitter is satisfied with the responses from the Reviewer for each section, the location certification and/or assessment can be submitted.  This will automatically lock the FDM point of view which prevents any additional data from being processed thereby ensuring that data will not/cannot be changed.

The question I am often asked by my clients is how many implementations use this functionality.  Unfortunately I have found that a small percentage of FDM customers are leveraging this functionality.  I believe there are 2 key reasons for this:

  • This dynamic exists for 2 reasons. First the Process Explorer module is not often covered in much detail during the sales cycle. This is not that much different from Process Management in HFM. It is highly conceptual and also not very “sexy”. As a result, some FDM customers may not even be aware of the functionality (similar to FDM Reports). Secondly, the Process Explorer module is somewhat complex and takes a fair amount of experience to design and deliver properly. Some simply may lack the knowledge of the module or how to implement it. This is not meant to be disparaging to the less experienced in the FDM community; however, it is important to understand the experience and capabilities of the partner that you are or have chosen.
  • As I alluded to in the lack of knowledge section, the Process Explorer is sometimes met with the same level of resistance as the Process Management/Phased Submission functionality of HFM. The reality is that these modules add a certain amount of overhead to the close process. As such, organizations that run lean sometimes are reluctant to add additional steps to the process.

I hope that this post will address both of these barriers and that you will find a use for this valuable functionality in your application.  If you are interested in leveraging the Process Explorer and need additional assistance, please feel free to contact me.

1 ––Oxley_Act
2 – Special thanks to Wayne Paffhausen for being an FDM historian
This entry was posted in Out of the Box Functionality and tagged . Bookmark the permalink.

Leave a Reply