Tag Archive for: performance

EPM Reformation

The EPM Reformation

Enterprise Performance Management (EPM) is undergoing the same transformation that Enterprise Resource Management (ERP) systems brought about in the early 90s.  As complimentary solutions such as Asset Management, Payroll, and General Ledger converged into one consolidated, modular system, so too are the solutions that comprise EPM (Financial Consolidation, Budgeting/Forecasting, Strategic Planning, and Reporting).   Along with the obvious benefits and economies of scale that accompany this transition, we must be aware of the pitfalls associated with the design, implementation, deployment, and support of these mission critical applications.

EPM as a Compliment to ERP

Just as Enterprise Resource Planning (ERP) solutions are an essential component of the Back Office operations of every Fortune 500 Company, Enterprise Performance Management systems are complimentary in nature and provide insight into the operational and financial effectiveness of the organization.  Metaphorically speaking – If the organization was an automobile, ERP would be the engine and EPM would be the gauges.  Carrying the analogy forward, nothing prevents us from operating a car without a speedometer, gas gauge, or heat indicator.  Furthermore, when the car is running well (at least in so far as we perceive) we have little interest in these instruments.  But, what about when we hear the first ping in the engine, or the car doesn’t respond when we hit the accelerator.  Worse yet – A seize up (aka Recession).  In the absence of information conjecture prevails and we are forced to speculate as to the cause of the problem. Without EPM, organizations are essentially operating their business in a similar fashion; reactive at best, “from the gut” at worst.

The Problem

From a business (functional) perspective, EPM solutions are categorized by the convergence of Analytic Application such as Financial Consolidation, Budgeting/Forecasting, and Strategic Planning with traditional Business Intelligence Solutions hallmarked by Query & Reporting, Key Performance Indicator (KPI) Dashboards, and Enterprise Scorecards.  As EPM has evolved from it’s siloed upbringing as a departmental solution to the Enterprise-class solutions of today, the underlying technology required to support these applications has become more broad and in recent years increasingly more complex.  This evolution is both natural and expected.   Given the expansive use of EPM based solutions, technical constructs such as multidimensional databases, data marts, enterprise data warehouses, workflow engines, web services, SOA, Calculation Scripts, ETL packages, and Master Data (Hierarchies) have all become vital components to the architecture.

In so far as organizations appreciate the criticality of EPM solutions to their organization, there is a gross under estimate of the effort associated with deploying and supporting these mission critical applications.  This similar lack of effort appreciation is shared by the ERP implementation of the 90s.  How often did we hear about the $2 million dollar ERP solution that came in at $20 million or more?

Gaining an Appreciation

Few would argue that the ERP solutions of today have not brought about a degree of integration and consistency throughout the business.  The ability to integrate key operational back-office systems up and down the organization with the capacity to exchange data between functional modules without fear of inconsistency is certainly a hallmark of the ERP promise.  But, this integration did not come without a price.  The same can be said for EPM.

ERP and EPM are both the harbingers of consistency, transparency, and audit ability.  As such, they force the institution of standards and controls where they have not historically existed.   Furthermore, there is an illusion that these disciplines run contradictory to loosely coupled legacy processes that are thought to be more flexible, nimble, and sufficient for supporting the business.  Whereas this may appear to be true when viewing each process as a stand-alone, siloed operation (forecasting separate from budgeting, separate from financial consolidation, separate from operational reporting).  It is important to have the right perspective here.  As with traditional ERP solutions, to gain an understanding of the EPM value proposition, you must first rise above the individual business solutions that encompass performance management (i.e. Financial Consolation, Budgeting/Forecasting, Reporting, etc).  Only by viewing these applications from a holistic, integrated business perspective can you appreciate the business and technology economies of scale that accompany Enterprise-class EPM solutions.

The Point

EPM solutions if approached correctly must be seen as the acronym implies, “Enterprise” in scope.  Similar to their ERP counterpart, EPM solutions can and in many cases should be implemented modularly, but under the auspice of an overall Solution Deployment Strategy.  Notice the term “Solution” not “Application”.  Applications are but one component of the EPM strategy.  Others include: Technical Infrastructure, Data Management/Governance, Process Integration, Communication/Change Management, and Administration & Support.  When you view EPM solutions from this perspective it is hard not to appreciate the level of involvement required from Executive Leadership, The Business, and Information Technology.  Organizations must think of their EPM solutions as “ERP Projects”; enterprise enabling solutions that require the establishment of well documented and endorsed strategy that align with the corporate directive.   In this vain, EPM requires a realistic investment of resources, time and capital to be successful.   Then again, you could pull away from the car lot with a 1971 Pinto and hope no one hits you from behind…

 
/0 Comments/by

Users Can Improve Essbase Reporting Performance

Users of Essbase have some control over the performance of a database and how responsive it is when retrieving data.  With a basic understanding of how Essbase stores data, users can optimize performance by changing the order of the dimensions and members in a report.

It might be helpful to read our article on sparse and dense dimensions.  Here is a brief overview:

An Essbase database is comprised of thousands, if not millions or billions, of data blocks.  Each block of data, and its size, is defined by the dense dimensions in the Essbase outline.  The volume of blocks is dictated by the unique combinations of sparse dimension members.  If Time and Accounts are dense, each block created would hold all the months for every account.  If Organization and Product are sparse dimensions, there would be a block for each unique combination of Organization and Product.  A block would exist for Center 10 / Product A, as well as Total Organization / Total Product.  If the outline has 20 members in Organization and 15 members in Products, the database could have up to 300 independent blocks.

If a report is written to show an entire income statement for all 12 months for Total Product and Total Organization, how many blocks would have to be queried?  Remember, there is a block for each unique member combination of Organization and Product.  The answer is one, because there is a block for Total Organization/Total Product that includes every account and every member in the time dimension.

How many blocks would be accessed if a report pulled Total Sales (a member in the Accounts dimension) in January for every product?  Since the Product dimension is sparse and there are 15 products, 15 blocks would have to be opened to return the results.

Here is where your understanding of what sparse and dense represents will help you improve your reports.  Opening a data block, reading the contents, and closing it, is similar to opening, reading, and closing a spreadsheet.  It is much faster to open one spreadsheet, or block, than 15 spreadsheets.  So, if the database retrieves are written in such a way to minimize the number of blocks that need to be accessed, or the order in which they are accessed, performance can improve.

I will agree that if data for all 15 products is needed for the report, all 15 blocks have to be opened.  There is no way around that.  That said, often times users will build one worksheet for income statement and one worksheet for balance sheet.  This means that the report is making two passes on the same blocks.  In theory, it takes twice as long to open/read/close a data block 2 times than it does once.  It is faster to have the income statement and the balance sheet accounts in one worksheet, which only makes one pass on the required blocks.  One worksheet for Income Statement and one for Balance Sheet can be created with cell references to the worksheet that has the retrieved data, if 2 separate reports are required.

I frequently see another example of a report requiring multiple passes to the same data block.  Using our example dimensions above, assume product information is required in a report for multiple accounts.

    Jan Feb Mar
Income Product A      
Income Product B      
Income Product C      
Income Product D      
Expense Product A      
Expense Product B      
Expense Product C      
Expense Product D      

The Essbase retrieve above would start from the top of the spreadsheet and move down the rows to retrieve the data from Essbase.  This cycle would open the Product A block, then B, C, and D, and retrieve the associated income for each.  It would then have to reopen the same 4 blocks to access expenses.

The following example, again going from top to bottom, would access both income and expense while the block is open.  The way this retrieve is setup, it eliminates the need to access the same block multiple times, yet still pulls the required information.

    Jan Feb Mar
Income Product A      
Expense Product A      
Income Product B      
Expense Product B      
Income Product C      
Expense Product C      
Income Product D      
Expense Product D      

These examples are very small.  In a real world example, a report of this size would not produce significant variances in the time it takes to retrieve them.  Users often have spreadsheets that are hundreds of rows long and take minutes to retrieve.  In these situations, eliminating the need to access the same block multiple times can produce notable improvements in the time it takes to retrieve data from Essbase.

With a basic understanding of how your database is setup, users of Essbase can help themselves with some simple changes to the format of the retrieve worksheet.  If access to the dimension properties in your database is unavailable, ask your system administrator to supply them for you.

 

 
/0 Comments/by