What skill set should a Hyperion EPM Administrator have? Part I

Working with clients in today’s environment of streamlined resources, one of the areas often overlooked in an EPM implementation is the candidate who is going to fill the role of System Administrator for an organization. There is a direct correlation between the level of success an EPM project has and the candidate fulfilling this all important role.

I’ve been associated with projects where the Administrator has had a less than enthusiastic attitude toward this responsibility; thinking that this is just one more area of responsibility being piled on them. I always try to encourage and communicate that this is an incredible opportunity for them to learn/master a new technology on the job. In addition, the skill set they can acquire through “knowledge-transfer” with the project consultants is invaluable. The portability of this knowledge with future employers is also a benefit that administrators don’t always seem to grasp, as there is a constant need for seasoned Hyperion administrators in the marketplace. Clients consistently inquire as to whether we can assist them in recruiting experienced Hyperion Administrators based on our network of contacts.

Some of the skills from an implementation perspective that we as a project team like to see in an Administrator is a willingness to embrace the technology that’s being implemented Successful Administrators are the ones who jump in to the “deep-end” of the pool with the consulting team and understand that there may be some hiccups along the way, but ultimately the organization will be in a significantly better place once the project has gone “Live”. A consistent theme to those who are resistant to change is how their current legacy systems can handle can adequately handle the organizations requirements, however when questioned a little deeper about the limitations and issues of their current system and how that platform can position the organization for future growth, that’s when the realization of the shortcomings of the current are truly recognized.

The ability to effectively communicate is another critical skill that a successful Administrator must have because they will need to have the ability to speak to different audiences. Success administrators need to be able to communicate with their peers as users and often times users from different parts of the organization outside the familiar confines of the Finance area. In addition, successful Administrators need the ability to effectively communicate with Manager, Director, Vice President level employees. The Administrator must also be able to effectively communicate with the IT group as they will be the liaison between the business side and the technical side of the organizations. Each of these groups has their own “language” and vested interest in the organization which must be recognized by the Administrator in order to be successful.

Much of skill set that successful Administrators need is technical in nature but too often the “people” side is under emphasized. Overall, a good attitude with the ability to effectively communicate at various levels within the organization as well as the technical aptitude to learn a new technology are the ingredients for a successful administrator.

In Part II, we’ll discuss some of the more technical skills that a Hyperion Administrator should either have or acquire in order to be an effective and successful administrator.

The Impact of IFRS for EPM Reporting – Part 6

In Part 6, I want to provide more detail on the similarities and differences for reporting Financial Instruments. The details below were from notes I took during a presentation during a company sponsored educational seminar about IFRS.

Financial Instruments

Similarities

Both require financial instruments to be classified into specific categories to determine measurement

Both require the recognition of all derivatives on the balance sheet

Hedge accounting is permitted under both

Both require detailed disclosures in the footnotes Differences

Fair value measurement

• US GAAP – one measurement model (FAS 157) based on exit price
• IFRS – various standards use slightly varying wording to define fair value – transaction price at inception date is generally considered fair value

Use of fair value option

• US GAAP – financial instruments can be measured at fair value with changes in income
• IFRS – financial instruments can be measured at fair value with changes in income, when certain criteria (more restrictive) are met

Differences

Day one profits

• US GAAP – can recognize day one gains on financial instruments even when all inputs to the measurement model are not observable
• IFRS – only recognized when all inputs are observable

Debt vs. equity classification

• US GAAP – certain instruments with characteristics of both debt and equity must be classified as liabilities
• IFRS – classification focuses on the contractual obligation

Compound (hybrid) financial instruments

• US GAAP – not bifurcated into debt and equity components, but may be bifurcated into debt and derivative components
• IFRS – required to be split into a debt and equity component, and if applicable a derivative component

Hedge effectiveness – short cut method

• US GAAP – permitted
• IFRS – not permitted

Hedging a component of a risk in a financial instrument

• US GAAP – risk components that may be hedged are specifically defined – no additional flexibility
• IFRS – allows entities to hedge components of risk that give rise to changes in fair value

Impairment recognition – available for sale debt instrument

• US GAAP – may have an impairment due solely to a change in interest rate if the entity does not have the positive ability and intent to hold the asset
• IFRS – generally only evidence of a credit default results in impairment of an AFS debt instrument

Convergence

In 2007, the IASB exposed a discussion paper to propose one measurement model for fair value whenever fair value is required. This paper was consistent with the concepts in FAS 157. Both boards appear to be moving towards ultimately measuring all financial instruments at fair value with changes in fair value reported through income.

The Impact of IFRS for EPM Reporting – Part 5

In Part 5, I want to provide more detail on the similarities and differences regarding Assets: intangible assets, long-term assets, impairment of assets and Leases. The details below were from a presentation during a company sponsored educational seminar about IFRS.

Intangible Assets

Similarities

Same definition: nonmonetary assets without physical substance

Recognition criteria require that there be probable future economic benefits and costs that can be reliably measured

Start up costs are never capitalized as intangible assets

Goodwill only recognized in business combinations

Internal costs related to the research phase of R&D are expensed

Amortize over the useful life

Goodwill never amortized

Differences

Development costs

• US GAAP – expensed, some software developed for internal use can be capitalized (SOP 98-1)
• IFRS – can be capitalized when technical and economic feasibility can be demonstrated. No separate guidance addressing computer software

Revaluation

• US GAAP – not permitted
• IFRS – permitted, but reference to an active market required, therefore, rare

Property, plant and equipment

Similarities

Costs to be capitalized are similar

Both require a provision for asset retirement costs when there is a legal obligation, although IFRS requires provision in certain other circumstances as well

Depreciate on a systematic basis

Assets held for sale are measured at lower of carrying amount or fair value less costs to sell

Differences

Revaluation

• US GAAP – not permitted
• IFRS – may be applied to an entire class of assets to fair value

Capitalization of borrowing costs

• US GAAP – generally, capitalize. Can include certain equity method investments
• IFRS – policy choice: capitalize or expense, but must be consistent to all. Equity method investments are not qualifying assets. (NOTE: choice will be eliminated in 2009, when the costs must be capitalized)

Investment property

• US GAAP – not separately defined, so accounted for as held for use or held for sale
• IFRS – defined as an asset held to earn rent or for capital appreciation. May be accounted for at cost or at fair value

Impairment of Assets

Similarities

Similarly defined impairment indicators

Both require goodwill and intangibles with indefinite lives to be reviewed annually for impairment

Despite similarity in overall objectives, differences exist in the way in which impairment is reviewed, recognized and measured

Differences

Review for impairment indicators – long-term assets

• US GAAP – whenever events or changes in circumstances indicate
• IFRS – assessed at each reporting date

Method of determining impairment

• US GAAP – 2 step approach – determine recoverability, then loss
• IFRS – one step approach – calculate loss if indicators exist

Impairment loss calculation

• US GAAP – Amount carrying amount exceeds fair value (FAS 157)
• IFRS – Amount carrying amount exceeds its recoverable amount

Goodwill

• US GAAP – recoverability test first at the reporting unit level, then calculate loss
• IFRS – impairment test at the cash generating unit level

Reversal of loss

• US GAAP – prohibited
• IFRS – prohibited for goodwill. Other long-term assets reviewed annually for reversal indicators

Leases

Similarities

Party that bears substantially all of the risks/rewards of ownership recognizes a lease asset and corresponding obligation (capital lease)

• US GAAP has bright line tests, IFRS doesn’t – but generally follows the US GAAP test

Operating leases expense recognized straight line over lease term

Lessor accounting essentially the same

Differences

Lease of land and building

• US GAAP – if fair value of land is greater than 25% of the total fair value – consider the land and building components separately
• IFRS – land and building elements considered separately – no 25% test

Recognition of a gain/loss on a sale and leaseback

• US GAAP – gain or loss is generally deferred and amortized over the lease term
• IFRS – For an operating lease, the gain/loss is recognized immediately. For a capital lease, the gain/loss is deferred and amortized over the lease term
• IFRS does not have a leveraged lease classification

The Impact of IFRS for EPM Reporting – Part 4

In Part 4, I want to provide more detail on the similarities and differences regarding: Business Combinations and Inventory. The details below were from a presentation I viewed during a company sponsored educational seminar about IFRS.

Business Combinations

Similarities

• All accounted for using the purchase, or acquisition method
• Recognized at fair value, but currently differing definitions of fair value
• Acquisition date is the date that the acquirer obtains control
• Contingent consideration recognized at fair value at acquisition date, subsequent changes in earnings
• Negative goodwill recognized immediately as income
• Acquired in-process R&D recognized at acquisition date fair value
• Restructuring liabilities only recognized if criteria have been met, and is recognized at the acquiree level at the acquisition date
• Net identifiable assets of acquiree are recognized at their full fair value
• All transaction costs expensed as incurred

Differences

Acquisition of less than 100% of acquiree

• US GAAP – noncontrolling interest is measured at fair value, including goodwill
• IFRS – Choice of measuring noncontrolling interest at either full fair value including goodwill or at its proportionate share of the fair value, exclusive of goodwill

Inventory

Similarities

Same principle that the primary basis of accounting for inventory is at cost

Both define inventory as assets held for sale in the ordinary course of business, in the process of production for such sale, or to be consumed in the production of goods or services

Permitted techniques for cost measurement, such as standard cost method or retail margin method are similar

Cost of inventory includes all direct expenditures to ready inventory for sale, including allocable overhead

Differences

Costing methods

• US GAAP – LIFO permitted
• IFRS – LIFO is prohibited

Measurement

• US GAAP – carried at lower of cost or market
• IFRS – carried at lower of cost or net realizable value

Reversal of inventory writedowns

• US GAAP – cannot be reversed
• IFRS – can be reversed up to the amount of the original impairment loss

Automating Your Reporting Package in Hyperion

Putting together your monthly, quarterly, and annual reporting packages is menial enough, but if that process is done manually, it makes it all the more tedious. Especially if, in a worst case scenario, you’re having to consolidate, reconcile, and update individual spreadsheets and print those off one-by-one….

Hyperion Workspace provides a great solution to remedy this problem through its inherent batching and scheduling functionality. This feature set allows you to collect reports into a book, batch reports and books, and schedule them for a variety of output. Following is a brief rundown of the scheduling process.

First off, you will need to decide whether your reports should be gathered into a book. Books generally consist of logical sets of reports and/or report snapshots. A report snapshot is a picture of a report on a specific date and time and does not dynamically link back to the source database. You might see a book gathered by category (monthly, quarterly, annually), by scenario (actual, budget, forecast), or by functional area (sales, engineering, administrative). It all depends on business need and logical groupings.

Books have their own point of view (POV) that allow you to override user or grid POVs. For those who aren’t familiar with Hyperion POVs, in a report, a POV is a single dimension member that applies to the entire report. From a report perspective, you have dimension members in rows, columns and the page. Any dimensions not included in the row, column, or page fall to the POV and any dimension in the POV can only have a single member selected. A grid POV applies to a grid in a specific report, whereas a user POV applies for a specific user across multiple reports. So, as an example, if you wanted to run all reports for the budget scenario for 2010, you could override report selections by using the book POV. Books can also be set up with prompts, allowing member selections to occur when the book is run.

Finally, books have a table of contents feature, enabling you to show and/or print out a listing of the reports included in the book.

The second step would be to create a batch. A batch can include items such as individual reports, report snapshots, and books. The batch is required in order to schedule reports for output. Also, if reports or books included in the batch contain prompts, members can be selected for those prompts as part of the batch set up. Like a book, a batch has its own POV that can override the POVs of its included objects.

The last step in automating your reporting package is to schedule the batch. The batch scheduler allows you to generate output immediately or on a specified date, time, and recurring frequency. Oftentimes, what I’ll see clients do is run their scheduled reports afterhours, so the processing time occurs while end users are out of the system. From a performance standpoint, this is optimal since the batch generation won’t compete with end users for system resources.

A newer feature of batch scheduling is bursting. Bursting allows you to enable reports to be run for multiple POV members. As I mentioned above, the POV is a single dimension member applying to a particular object. Bursting lets you choose multiple members and then runs the batch output for those selections. This would be useful if, for example, you wanted to run both budget and actual reports or reports for the western, eastern, northern, and southern regions.

The next batch setting is the output. You have the following options:
• Generating a report snapshot saved in the reports repository. A nice feature here is that you can set permissions to the output as part of the batch scheduler.
• Printing output.
• Exporting the output in PDF format to a shared directory and/or as an email attachment. This can be especially useful for users who do not have an ID set up in the application.
• Exporting the output in HTML format to a shared directory.

Finally, you can set up the batch scheduler to send an email if the batch generation is either successful or unsuccessful.

In terms of the mechanics for setting up books and batches and scheduling them, it’s fairly straightforward. All of these items are created in Hyperion Workspace. For books and batches, that’s done through the File -> New -> Document menu option. To schedule batches, click the Navigate icon and go to Schedule -> Batch Scheduler.

Once all your reports, books, and batches have been set up and scheduled, you really should have a self-sustaining system with dramatically decreased cycle times.

How to search Planning Supporting Detail: Part 1 - Getting the data

Background Information

Supporting Detail is a powerful tool that helps planners build and communicate bottom-up values when planning such expenses as travel, salary, and projects, where you need to calculate aggregate values. Supporting detail can include text, values and operators that define how data aggregates.

This feature is particularly useful when budgeting when you have multiple expenses falling in the same line. However, one of the drawbacks is when you want to report on at the supporting detail level for particular line item. Suppose you want to look at the supporting detail for Facilities Expenses across multiple entities. You want to see all the entities that have the supporting detail item of Landscaping. This is rather difficult to do given the current mechanisms in planning for reporting on supporting detail.

One of the common complaints about supporting detail is this inability to report and search at the supporting detail level. However through the use of database objects such as views and Excel, this supporting detail can be searched and reported on. By no means do you have to use Excel to retrieve this data but it is the most common BI tool that all companies have. You can use any business intelligence reporting tools such as OBIEE to also provide the means to retrieve the supporting detail.

This blog entry will focus on setting up of the database to retrieve the data.

Overview

First, Supporting Detail is not stored in Essbase. This is the root of why you can’t get to it via the Add-In or Smartview. Supporting Detail is stored in the planning relational database in a couple of tables called HSP_COLUMN_DETAIL and HSP_COLUMN_DETAIL_ITEM. HSP_COLUMN_DETAIL provides the actual intersection where the supporting detail is stored whereas the actual supporting detail labels and values are stored in the HSP_COLUMN_DETAIL_ITEM table. The data is stored as keys so you also need to query the table HSP_OBJECTS and HSP_PLAN_TYPE to decode the key values to meaningful data as you would see in Planning.

The data that is stored in the HSP_COLUMN_DETAIL is stored as a member name so if you would like to see your supporting detail using the alias you will also need to include a mechanism to get the alias name from the HSP_ALIAS table.

There are many different ways to extract data from these tables ranging from stored procedures to database views. I prefer to use database views to give a real time look into the supporting detail but there are drawbacks and possible performance issues using this method.

For this blog entry I will focus on a simple method of extracting supporting detail. I will follow up this entry with additional blogs with methods for incorporating the alias and also converting the supporting detail value from the local currency to USD.

Example

For this example, assume you have a planning model that has 9 dimensions. The data is stored in HSP_COLUMN_DETAIL as DIM1, DIM2, etc ... so you will need to determine which dimension equates to the appropriate DIM column in the table. For this model the following table shows the dimensional mapping for the HSP_COLUMN_DETAIL table.


I have created a view using the following SQL. It is important to note that you will need to use outer join syntax to join HSP_COLUMN_DETAIL and HSP_OBJECT. HSP_COLUMN_DETAIL can have null values in the dimensional columns depending on your planning model.

select p.type_name PLAN_TYPE,
o1.object_name SCENARIO,
o2.object_name ACCOUNT,
o3.object_name DEPT,
o4.object_name PERIOD,
o5.object_name VERSION,
o6.object_name CURRENCY,
o7.object_name YEAR,
o8.object_name EMPLOYEE ,
o9.object_name PROJECT,
cdi.label SUPP_DETAIL,
cdi.value LOCAL_VALUE
from
hsp_column_detail cd inner join hsp_column_detail_item cdi on cd.detail_id=cdi.detail_id
left outer join hsp_object o1 on cd.dim1 = o1.object_id
left outer join hsp_object o2 on cd.dim2 = o2.object_id
left outer join hsp_object o3 on cd.dim3 = o3.object_id
left outer join hsp_object o4 on cd.dim4 = o4.object_id
left outer join hsp_object o5 on cd.dim5 = o5.object_id
left outer join hsp_object o6 on cd.dim6 = o6.object_id
left outer join hsp_object o7 on cd.dim7 = o7.object_id
left outer join hsp_object o8 on cd.dim8 = o8.object_id
left outer join hsp_object o9 on cd.dim9 = o9.object_id
left outer join hsp_plan_type p on p.plan_type = cd.plan_type;

By using the sql to create a view I am able to query the supporting detail as it is saved in planning. This view can then be queried via your business intelligence reporting tool. This view gives the user a the ability to look at the supporting detail that is stored in a planning model and the user can utilize the filter analysis functions of the reporting tool to take a close look at the supporting detail items.



I will follow up this blog entry with subsequent entries showing how to do currency conversion from local to USD with supporting detail, return the alias instead of a member name in the supporting detail record set, and utilize the planning security model to return specific supporting detail based on identity.

Getting Your EPM Project Off to a Successful Start

I think most would agree that getting a software implementation project off to a good start is key to arriving at a successful finish. Even so, I think that many people involved with these types of projects would be able to site several instances of cases where that did not occur.

One problem I’ve experienced in the past is when there is a misunderstanding between requirements gathering and design. Essentially, the project would jump right into design without a clear understanding of business requirements. When that happens, you can end up with a constantly changing design, missed deadlines, budget overruns, and lack of user acceptance, among a host of other things. In fact, without a clear understanding of the requirements, you would rarely ever end up finishing a project successfully.

Requirements should tell an organization what its business needs are in order for it to perform and succeed. These requirements should be gathered via interviews with key stakeholders and subject matter experts, from the highest level of the organization to the lowest, as deemed necessary. They should be an all inclusive list that is prioritized based on budget, timing, business need, etc. The design, on the other hand, should tell you how to build the tool once you’ve determined what the immediate business requirements are.

What I’ve experienced most often during EPM implementation projects is a small amount of requirements (we want a distributed system that’s easily deployable to end users, we need to have single source of the truth, we need to have multiple what-if versions of data) and a lot of design (here is our chart of accounts, this is how our data is sourced, these are the reports we need to generate). Requirements should take a fair amount of time to gather, fully vet, and complete. Once completed, a document should be presented and signed-off by all parties before proceeding to the design phase. If an adequate amount of time is taken to complete requirements and design, the build portion of the implementation should, in theory, become much easier.

Let me add a caveat here. Projects have budgets and timelines and do not continue in perpetuity. Therefore, requirements gathering and design should not go on forever and, obviously, have to be done within the confines of the project. The point is to do a complete and thorough job both gathering requirements and developing the design, to give your organization the best shot at successfully building out a solution.

After requirements and design are complete, key stakeholders should stay involved throughout the project to make sure their requests are accurately being fulfilled. It’s one thing to gather a list of all the requirements and develop a design, it’s another to build it into an application and make sure the end product is truly what was desired and meets the needs of its users.

Finally, success criteria should be included as part of requirements and design and re-visited at the end of the project to make sure all criteria were met. This provides a means for “grading” the project and ensuring that key items were considered and implemented successfully.

Optimization of Established Planning Applications – Part 1

A common question that I am often asked when first arriving at a client with established Planning applications is, “How can I improve my applications performance.” Two short–term initiatives that can often provide more robust performance for established Planning environments are the following:
1. Remove unnecessary history
2. Reorder outlines

Remove Unnecessary History

Often an inordinate amount of history maintained within Planning applications to facilitate year over year reporting. Maintaining excessive history in a Planning application creates unneeded blocks, the greater the number of blocks, the greater the processing time for calculations. While year over year analysis capabilities undoubtedly have to be maintained, I often leverage the practice of creating a reporting application to facilitate Planning Optimization.

Native Essbase reporting databases are developed to archive historical data. These new reporting databases are based on the existing databases within the Planning applications. All data not associated with generating future budgets or forecasts from each of the Planning applications is moved to the reporting database through partitioning, xrefs or data extracts and loads. Planning data (i.e. Budgets, Forecasts, and Plans) would then be moved into the reporting databases at scheduled intervals to allow the year over year analysis, in addition to allowing for an optimal configuration of planning.

Basic steps to moving history out of Planning:

1. Create native essbase reporting cubes to archive historical data
2. These new reporting cubes should be based on the existing cubes in the Planning applications
3. Remove all data not associated with generating future budgets or forecasts from each of the Planning applications
4. Load all historical to the new reporting cubes
5. Remove dimension members pertaining to historical data and alternate hierarchies from the Planning applications
6. Integrate current year data from the Planning applications to the reporting cubes
   

Reordering of Outlines

Industry wide standards recommend that outlines be structured in an hourglass shape. From top to bottom; dense dimension members with the most stored members to the dense dimension with the smallest number of stored members. Then sparse dimension members with the least stored members to the sparse dimension with the largest number of stored members.

I acknowledge that this rule doesn’t apply to every model; however I do suggest that application administrators run multiple iterations of a baseline calculation reordering the dimension to ascertain the optimal outline order for calculation processing. Reordering outlines to increase the chance of achieving a single anchoring dimension with multiple bitmaps often result in achieving the optimal calculation performance.

Administrators can simulate calculations using SET MSG ONLY in a calculation script. A simulated calculation produces results that help you analyze the performance of a real calculation that is based on the same data and outline.

By running a simulated calculation with a command like SET NOTICE HIGH, you can mark the relative amount of time each sparse dimension takes to complete. Then, by performing a real calculation on one or more dimensions, you can estimate how long the full calculation will take, because the time a simulated calculation takes to run is proportional to the time that the actual calculation takes to run.

While these steps aren’t the be all, end all to optimization, these initial steps will help get you started.

In the next blog, we’ll address leveraging multiple plan types and calculation running in topdown and serial modes

The Impact of IFRS for EPM Reporting – Part 3

In Part 3, I want to provide more detail on the similarities differences and convergences regarding: Consolidations, Joint Venture Accounting, and Equity Method Investees. The details below were from a presentation I viewed during a company sponsored educational seminar about IFRS.

Similarities

• The basis for determining whether or not subsidiaries are consolidated is based on control, but there are differences in the definition of control. Generally, subsidiaries subject to control by the parent are consolidated.
• Equity investments (referred to as “an associate” in IFRS) in which the investor has “significant influence” (generally 20% or more) but not consolidated is considered an equity method investment

Differences

Consolidation Model

• US GAAP – focus on controlling financial interest (FIN 46)
• IFRS – focus on the concept of the power to control – presumed to exist at 50% voting

Special Purpose Entities

• US GAAP – FIN 46 requires the primary beneficiary (determined based on the consideration of economic risks and rewards) to consolidate
• IFRS – consolidate when the substance of the relationship indicates that an entity controls the SPE – No concept of QSPE

Significant events between reporting dates

• US GAAP – Disclosed in financial statements when different dates are used
• IFRS – adjusted for in the financial statements

Joint Ventures

• US GAAP – generally accounted for using the equity method
• IFRS – either the proportionate consolidation method or the equity method

Convergence

FASB and IASB had a joint project that addressed non-controlling interests, which culminated in the issuance of FAS 160, Non-controlling Interests in the US and a revision of the accounting for non-controlling interests for IFRS.

IASB recently issued an exposure draft that proposes the elimination of proportionate consolidation for joint ventures.

In Part 4, I will provide more detail about our next two topics business combinations and inventory.

Are your Performance Management metrics useful?

Performance Metrics are the heart of any BI/EPM implementation, but often, the ability to effect change in the metrics is not seamless. In this blog, I'll explore three key factors related to less-than-optimal usage of Performance Management Metrics and suggest practices to improve application of metrics to an organization's benefit.

Metric Background
Metrics are intended as a simple measurement of activity. By developing and publishing organizational metrics to decision makers, the labor intensive effort of collecting source data, manipulating or adjusting the data, and ultimately calculating metrics, is eliminated. Unfortunately, this also eliminates a large part of the knowledge capital necessary to understand how to influence metrics.

• Key decision makers expected to act upon metrics must understand the full formula for deriving the metric. Only with this information can the best decisions regarding how to improve a business's performance be made.

Relevance of a change in a Metric's value
Similar to having an understanding of the makeup of a metric, organization decision makers must have an understanding of the relevance of a change in the value of a metric. Often, formulas producing metric results mask exponential changes in source values to appear to be linear changes. Over time, this can result in less efficiency from additional attempts to improve a measurement.

• Organizations must have an understanding of the relevance of a change in a key metric at different points. A thorough understanding of the historical change, as well as an analysis of the point at which further improving a metric results in materially diminishing returns, will guide the organization's decision makers to base their decisions on the most accurate basis at a point in time.

Industry Trends
Over time all organizations undergo changes to their business model, whether due to internal, external, or a combination of factors. Flexible metrics can enhance the ability for an organization to respond to changing market dynamics by quickly refocusing key decision makers to respond to business model changes.

• Frequent review of Performance Metrics for relevance to the current business climate allows for improved competitive advantage by reducing the time necessary to refocus an organization.

In conclusion, Performance Metrics are an invaluable tool to improve the decision making intelligence of an organization. However, to leverage maximum long and short term benefit requires a commitment to supporting the organization with the best possible guidance. Organizations that embrace their Performance Metrics as an avenue for executing strategy can realize significant gains in competitive advantage.

The Impact of IFRS for EPM Reporting – Part 2

Previously, I gave a brief overview of IFRS and it’s potential impact to many organizations. In that summary I provided a list of major differences between IFRS and US GAAP, the first item in that list was Financial Statement Presentation. I want to provide some more detail about each item in the list as well as provide some references for anyone wanting to learn more about the changes driving financial reporting.

So, let’s talk about Financial Statement Presentation. Below are the similarities and differences between IFRS and US GAAP.

Similarities

• Balance sheet, income statement, statement of cash flows, footnotes
• Accrual basis
• Similar materiality and consistency concepts

Differences

Classification of expenses

• US GAAP – based on function (e.g., cost of sales, administrative)
• IFRS – based on function or nature (e.g.., salaries, depreciation)

Layout of balance sheet and income statement

• US GAAP – Public companies must follow Regulation S-X
• IFRS – IAS 1 prescribes a list of minimum items – less prescriptive than S-X

Extraordinary items

• US GAAP – restricted to items that are both unusual and infrequent
• IFRS - prohibited

Some additional information about Financial Statement Presentation

In addition to the IFRS changes, the FASB and IASB have started considering other alternative reporting guidelines that may be incorporated into the IFRS standard in the future.

Some of the alternatives that are being discussed are significantly different than current reporting under both IFRS and US GAAP. This potential change in reporting presentation was brought to my attention by an actual client and they are already discussing the impact and requirements to fulfill the new guidelines.

The partial information below is from a publication by KPMG’s Department of Professional Practice – Audit, October 2008, Defining Issues, No. 08-42:

The FASB and IASB favor significant changes in the structure and content of the basic financial statements, and have set out their preliminary views on those changes. If the preliminary views go forward during the remaining due-process steps, the statement of financial position would no longer be organized primarily by assets, liabilities, and equity, and the income statement would no longer be organized primarily by revenues and expenses. Instead, the information in the statements of financial position, comprehensive income, and cash flows would be organized under “business,” “financing,” “income taxes,” “discontinued operations,” and “equity,” the latter not included in the statement of comprehensive income. Information would be disaggregated more than is the case today, and a new schedule would reconcile the information in the statement of cash flows to the information in the statement of comprehensive income.

…

The presentation model would have each entity present information in “sections” grouped by these major activities: business, financing, income taxes, discontinued operations, and equity. The model gives the business and financing sections subordinate reporting “categories.” Business-activities information would be separately presented for the operating- and investing-activities categories, and financing-activities information would be separately presented for financing assets and financing liabilities.

The classification scheme for financial statements is illustrated in Table 1

If you would like to read more about this subject the full KMPG article is located at the link below:

http://www.us.kpmg.com/RutUS_prod/Documents/9/DI_08_43_SEC_Mark_to_Market_Study.pdf

None of these decisions are final yet, but these are some of the things that we need to keep in mind for the future of EPM and BI.