Oracle Planning solution for collecting sparse data sets across many dimensions.

1. 1 How to Collect Budget Data Across 20-30 Dimensions Curtis P. Neumann, AT&T

2. Agenda 2 Introduction Problem Initial Solution Final Solution Tips and Tricks Conclusion

3. 3 Intro: Mergers and Financial Process Synergies Mergers create opportunities to review financial processes and determine cost synergies. Antiquated financial processes don’t meet the increasingly demanding and technology savvy financial users. My role at AT&T Finance is to spearhead opportunities to use System 9’s capabilities to add value by converting outdated financial software tools and processes into “Best Practice” states. Getting more granular detail to decision makers quicker allows them to make important operational decisions sooner, thus capitalizing on opportunities to grow profits. Our budgeting and reporting systems are centralized into a group called MR2020 (Management Reporting 2020).

4. 4 Intro: New Opportunities to Migrate off Finance “One Offs” In many cases, acquired companies have similar processes as the acquiring company. AT&T Inc. was formed in 2005, when "Baby Bell" SBC Communications Inc. purchased former "Ma Bell" AT&T Corporation. Although Ma Bell had great products, there was less attention spent on best practice budgeting and reporting practices. At Ma Bell, several financial processes were built on large MS Access databases and numerous Excel applications. The “Single Version of the Truth” principle is important. One-Off verses Central Reporting Timing Issues Definition Differences Incomplete Data

5. 5 Intro: Interested in Migration Projects? This presentation deals with the specific need to migrate from a very sparse (detailed) data set in a relational database to Hyperion Planning, an OLAP planning tool. A textbook design in Hyperion Planning won’t always accomplish this migration requirement, if the relational database has more than 20 dimensions. I will detail an example of this instance.

6. 6 Problem: Ma Bell Product Forecast Needs and the Legacy Process The Ma Bell subsidiary that was merged into SBC in 2005 is now called the AT&T Business Solutions (ABS) Unit. Various ABS organizational financial modelers need to forecast these products volumes and their characteristics in order to perform: Operations Expense Forecasts Capital Spending Forecasts Product Profitability Analysis A feed of ABS products into the AT&T Consolidated Budget Solution (CBS) –“Single Version of the Truth” A “home grown” web tool connected to an MS Access database was the process used to gather, approve and report out on forecasted product volumes. This was the legacy process, called the ABS Volumes Database (VDB).

7. 7 Problem: The Legacy Volumes Database (budgeting) Requirements A process to gather volumes around the business was the primary need in order to provide data modelers input data to load their driver based models. The original budget volumes gathering process had the following objectives: Users needed to load data to standard templates easily prepared in Excel. Provide different levels of security for administration related tasks. A process to create high level target volumes that volume suppliers could use as a guide to submit lower level detail. A template submission and approval process. A repository that could hold very sparse data across 21 or more fields. A reporting process that could summarize the volumes collected and provide lower levels of detail. Overall, the process had to be fairly dummy-proof and repeatable every quarter. The process did not need to: Run any calculations during the template data input task, except rollup of months to a total year column where necessary. No immediate reporting of totals across templates. A process could be run manually to create total reports.

9. Driver

10. Speed

11. Period_Activity

12. Hand_Off_Group

13. Template_Type

14. Row Number

15. Service_code

17. 10 Problem: Why a New Solution was Needed After the Ma Bell merger, IT was reshuffled and the developer maintaining the solution was reassigned. This is a risk of “One-Offs”. Because they are not part of a centralized set of tools that are maintained by a group of IT professionals. When the only developer maintaining the customized solution departs, all of a sudden the process becomes unsustainable. In addition, this process was identified as a synergy project that needed to be halted to reduce expenses. It took several people to maintain the templates, train the sixty users, change the MS Access scripts and tables, and maintain the website. This multi-vectored process significantly increased the cost to run the process verses a self contained off-the-shelf-solution. As we studied the legacy process, it became apparent that there was a packaged solution that could perform the same functions. Better yet, we believed we could cut the cost by half and maintain a better process. That solution we recommended was Oracle Hyperion Planning 9.3.1. We started working on this solution in February 2008.

18. 11 A First Attempt at a Textbook Hyperion Planning Application By coincidence, the Oracle Hyperion Planning architecture resembled the legacy VDB process in that there was a web-based workflow management module and a separate link to a database. Hyperion Planning is very similar, except that the data repository is a BSO cube, not a relational database. Figure 2 illustrates the high level system architecture of Hyperion Planning:

19. 12 Essbase Scale Limitation Having built several BSO cubes previously, my first concern was to test the calculation time of a BSO cube (plan type) with 20 dimensions, the allowed limit. Before going to Hyperion Planning, we proceeded to build a BSO cube with 15 dimensions, including the NPSC (product) dimension which had 1,000 level zero members. We loaded test data to the Essbase test cube and started a simple default calculation. Basically, we were testing the scalability of this very sparse (detailed) dataset by aggregating it. Did it finish calculating? We don’t know, because I stopped the calculation after three hours. It became clear to us, that our outline was simply creating too many potential blocks. There were few optimization steps remaining after we set Accounts, Period and Year to dense storage settings. We were also using four processors, so that should have provided enough horsepower.

20. 13 Multiple Plan Type Option We did look at the idea of using more than one plan type (cube), because up to three plan types are allowed per Planning application. But, that didn’t seem like a good idea when we thought about how the data forms would need to be set up. It would have been more work for the inputter to potentially have different forms. Also, the plan types would need to be consolidated using partitioning. Trying this with a replicated partition using the same outline achieves little from the original approach. We would have ended up with lots of sparse volumes data in one cube with the need to roll it up. We didn’t explore the use of transparent partitions either, because the retrieval times would have been unacceptable, if we could get it to work.

21. 14 Initial Conclusion and Next Steps Our initial conclusion was that we could not use Hyperion Planning for a “textbook” application that required more than 15 to 20 stored dimensions, depending on the number of members per dimension. After realizing this, we needed some help. I called my colleague, Chris Werle of Key Performance Ideas (KPI). He and his team met with me and came up with a very unique and innovative solution utilizing Hyperion Planning that captured data and reported it out into one cube with 21 stored dimensions.

22. 15 Final Solution: Part I of II. Hyperion Planning’s Strength – Collection Hyperion Planning’s strength is data collection, if Smart Lists are used extensively. This was the main idea that made this project a success. The key here is to utilize the relational table relationships to the BSO cube to store the data intersections. The Smart List intersections are stored as values within the Accounts dimension. Given that capability, the number of possible data intersection combinations has no impact to the stored dimensions in the cube. All that is required are the required stored dimensions and one extra stored dimension we called Row Number. Figure 3 shows the outline in the administration console: However, with this design we could only load to level 0 members.

23. 16 Final Solution: Part I. How does the data form look? From a user’s standpoint, the form looks like a super model; No navigation and no flipping of drop downs. The forms in Smart View were prepared in advance for users to look very close to what the users had under the legacy process. See Figure 4. The Smart List drop down functionality shown in column C makes changing the intersections a breeze. Normally, users would have to navigate a huge form when this number of dimensions (fields) are involved.

24. 17 Final Solution: Part I. Plan Type Design with Smart Lists Looking at the plan type (cube) in Essbase, it definitely looks different. There is virtually no analytic capability available in this cube because the Smart List members are stored as values. Again, all we were trying to do for this part was to store the data, then report it out. For those that are curious about how that data looks, Figure 5 shows a retrieval from Smart View with a connection to the plan type directly, (i.e. direct connection to the Essbase server) thus, no translation of the Smart List ID’s back to the Smart List Labels.

25. 18 Final Solution: Part II. Utilize Essbase for What It Does Best – Reporting Once the data was residing in the plan type (cube), we needed to build an Export/Transpose/Load (ETL) process to report it out. KPI advised us to flow the data from Hyperion Planning to an Essbase Aggregate Storage Option (ASO) cube. That translation as done in SQL server. Utilized the Smart List flat files, used to load the Smart List members into Planning, to convert the data from Smart List ID’s back to the Smart List labels. From here, we created an ASO cube that could easily hold 21 dimensions of data and loaded the translated (“ETL’d”) data to that ASO cube. See Figure 6.

26. 19 Final Solution: Part II. ASO Reporting Cube Although, this represents some ETL work, the beauty of this process allows for parents to be represented in the ASO cube. Therefore, we went from a flat structure in the Planning cube to a parent/child hierarchical structure in the ASO cube. Fortunately, this design worked well because there was no immediate need to report aggregated data in Planning. Figure 7 shows the ASO outline in the administration console. The CBL dimension in Figure 7 has parents at level 1. These are not in the Planning load, but are not required. It’s certainly possible to extend this beyond 30 dimensions, but I’m not aware of when that would ever be needed. Usually, budget data is collected at a higher level than actual data is reported.

27. 20 Tips and Tricks Loading Smart Lists from a Flat File If any one Smart List is more than 100 ID’s, the manual entry process should not be used. With the 9.3.1 version we were using, after ID 200, the refresh time between ID entries took several minutes. So, KPI came up with some SQL loads to the Planning Enumeration table on the Oracle server. This was another fantastic idea and was supported by Oracle. I recommend that Oracle Support be involved in any back end loading. INSERT INTO [HP_???].[dbo].[HSP_ENUMERATION_ENTRY] ([ENUMERATION_ID],[ENTRY_ID],[NAME],[LABEL]) SELECT 6,1,'NA_BU','NA_BU' UNION ALL SELECT 6,2,'S002 ','BCS' UNION ALL SELECT ETC……………… List all 1,000 or more entries here…..GO What about Budget Data Users that don’t have the Smart View Client? For this project we were able to create pivot tables into Excel by using Hyperion Financial Reporting to extract the data from Planning and create a raw dump into Excel. Hyperion Financial Reporting converts the Smart List ID’s to labels, so that’s not an issue. This is a low tech but a practical solution.

28. 21 What Could be Done Differently Try to Negotiate Fewer Dimensions with the Users What About Using a Planning (BSO) Plan Type and Not Aggregating It? Some may believe that this could have been accomplished with a BSO cube because there would be no need to aggregate the Planning BSO cube anyway. Here are the following reasons why that would not be practical: Forms would open very slowly. We’re talking at least several minutes. Navigation to the appropriate intersections would be slow. Would require lots of scrolling down a large form or selecting page drop downs. Cube would not be very compact. Lots or irrelevant intersections would exist. We would have had to ETL this over to an ASO as was done in this solution anyway. Sometimes different approaches work. We were looking for the least painful route.

29. 22 Conclusion This presentation drives home the fact that Oracle Hyperion tools are more flexible and scalable than the training classes and administration manual might suggest. In the case of Oracle’s Hyperion Planning product, the relational table structure and the resulting Smart List capabilities effectively extend the scale capabilities of Essbase. Look for the BSO to ASO integration capabilities in future versions of Hyperion Planning, as we are working with Oracle to better the product for use by larger customers. See Appendix A for a diagram of the entire VBD process. Thank you very much. You may contact me at curtis.p.neumann@att.com or 925/803-6144. If you would like a copy of my Hyperion Solutions 2006 presentation entitled “Hyperion Essbase at AT&T Long Distance: Utilizing Key Aspects to Run Finance in Sixth Gear”, please email me your request. Key Performance Ideas contact info is as follows: Chris Werle’s Office: 408/960-7400 | Cell: 408/930-6061 or cwerle@keyperformanceideas.com

30. Q&A 23

31. 24 Appendix A