Continuous Planning Architecture, Phase 2

Back in April, Kimberley Bermender posted on the finance systems architecture needed to support a continuous planning environment. The overall design goals included:

• Lower cost of maintenance,
• Standards-based data integration,
• Support of accurate, near real-time views into operations,
• A platform to support detecting, modeling, selecting and implementing change and then measuring results.

The main ingredients were:

• financial and operational data stores,
• an analytic (OLAP) engine – with reporting, and
• planning applications

Inherent in the architecture is the movement of data between data stores and OLAP cubes, as well as fact and metadata management. To build on that architecture, “phase 2” can include two other components that build on those design goals and get you closer to enterprise performance management nirvana.

The first is master data (or ‘reference’ data) management, and the second is a common enterprise performance management rules or calculation engine.

Master data management includes the tracking and control processes of data relationships (especially hierarchies) and instances across the enterprise. For example, product sales for a store in Ft. Collins, CO could roll-up to a ‘Central’ region one quarter, and then to the ‘West’ region the next quarter after a re-org. It’s important to keep track of which region it belonged to when doing quarter over quarter comparisons and other management reporting (not to mention statutory reconciliation and reporting). And that hierarchy could be contained in the store reporting application, the sales forecasting system, the G/L, the customer relationship management (CRM) system, and so on. Right now, those relationships are probably being manually managed and ‘lightly’ controlled. Our more complex financial systems require more automation and more rigorous control over master/reference data. And it certainly addresses at least the first 2 design considerations of Kimberley’s architecture.

For more on master data, see this DMReview landing page.

The second component is a central business rules/calculation engine. In any enterprise performance management environment, users can easily get bogged down in the definitions of data and information. For example, that Ft. Collins store could be looking at a ‘revenue’ report and not know if it’s booked revenue, commissionable revenue, recognized revenue, and so on. And even when they find out what kind of revenue it is, there can be a question of it’s accuracy: how did head office calculate it, where did they get the data from, and does it include intercompany sales or not?

Having one business rules engine lets the enterprise define ‘recognized revenue’ once, with control over the algorithms, the data refresh frequency, the data sources, and so on. Once the rules engine has certified a number, it can be used by all other enterprise performance management systems: planning can use it for prior actuals, strategic financial models can use it for long term scenarios, same store sales dashboards can use it for ranking, and so on.
The three-fold goal is to get better transparency into financial information (how did we get that number), better accountability (finance owns and certifies the number), more efficiency (define it once, don’t reinvent the wheel), and ‘believe-ability’ (start debating what to do about the results, not where the number came from).

Here’s a good article by Robert Blasum in DM Review on central rules (he also connects them to master data management)

Thanks to Kimberley and the team for letting me guest blog, please feel free to visit the Business Foundation blog over at http://businessfoundation.typepad.com/

Tips from the Big Guys: Yahoo Shares Planning Architecture and EPM Strategies

With so much focus on Yahoo’s search advertising strategy and ongoing battles with Microsoft, a webinar that focuses solely on their internal planning and back-end processes is a welcome diversion, not to mention a fascinating education. The Yahoo EPM Webinar, sponsored by Star Analytics and Key Performance Ideas, provided insight into how one very large company deals with key performance management issues, including:

• Creating highly efficient planning systems
• Maintaining data integrity
• Improving corporate reporting standards

Bob Yau, a Director of Corporate Applications at Yahoo, walked through their Enterprise Performance Management strategy and architecture and discussed how they have successfully implemented a project to help Yahoo efficiently manage change in a highly competitive market.

Yahoo has created a technical architecture for managing and exporting Hyperion Planning and Essbase data that provides their global business community with 24x7 access to near real-time planning and reporting data. Data is scheduled and automatically exported frequently throughout the day from the Planning application and is (again, automatically) synchronized with their Oracle Data Warehouse, eliminating data latency. Other benefits (and key project requirements) include their ability to maintain corporate reporting standards and improve compliance.

While the webinar does get technical (that’s right, architectural diagrams and everything) Mr. Yau does an excellent job of focusing as much on the business requirements and user needs as the technical implementation. Mr. Yau finishes off the webinar with his ‘Top 10’ lessons learned from his implementation, which covers both technical and business experience. #10 – Partner with the business for success. Good advice. Thanks Yahoo for providing such an insightful view into some of your key processes that support your enterprise performance management.

View webinar

Insight on the Gartner BI Conference in Chicago

As a long time attendee of the various Gartner events, my favorite has always been the more intimate setting of the BI summit - typically held in Chicago. Boy, was I surprised at the 1200+ attendees of this year's conference and the expectation of bigger growth to fuel a move to Washington, DC in 2009. Last year’s event pales in comparison. BI advocates, typically a cross-over role between Finance and IT, have made a rather dramatic transition into the IT camp for this conference. Many of the sessions were educational and entry-level in scope and oriented to the first time architect and supporter of Business Intelligence environments. The event has clearly moved away from the user of past years.

Also notable was the absence of discussions on the relative cost savings in deploying a BI environment for better business planning and analysis. Other than the one rather cheeky session on how to negotiate a good deal with your BI vendor, I expected to hear more about cost cutting and using BI data to enable efficiencies and identify cost-prohibitive inefficiencies. The market picture has been doom and gloom and the "R" word blatantly used. Instead I heard a great deal about enabling integration and the expansion of analytic applications.

I think this is great news! Clearly the message was to expand the BI footprint and make use of the technology that can drive profitability, not focus on doing more with less. I had conversations with luminaries such as Howard Dresner and Ron Powell, but I also spoke with a number of vendors and implementers such as IBM GBS and Palladium, who had similar messaging of exploiting the existing technologies and refining processes to drive revenue and deliver data on a more continual basis to the employees who can make the right decisions in real-time. This to me is a message of expansion and focus, rather than retrenchment and limitations. I heard a great deal about the continual need for data, an almost real-time need to do continuous planning and report on finer levels of granular information in a more automated fashion. The message was clear. BI is tops in priority and destined to gain more mindshare of senior IT executives as the business expands and focuses their growth. To grow and expand you always need Innovators who can do more with less, but also the visionaries who can see the gold amongst the rock.