DATA WAREHOUSING AND REPORTING Kuali Financial

Date Warehousing and Reporting Bill Overman – Indiana University Dylan Cooper – University of Arizona Susan Moore – University of California, Davis

Date Warehousing and Reporting Agenda Overview of approach taken by each school Hints on important data Technical hints Demonstrations Note: These applications do NOT come with KFS

Indiana University Datagroups Important fields to consider Both GL and reference tables Denormalized Important fields to consider Returns data to spreadsheet

Datagroups from GL tables General Ledger Entry Transaction level detail Includes a description General Ledger Balance Summary by accounting string

General Ledger Entry Balance Type Code – budget, actual, encumbrance University Fiscal Period Code denotes month Object Type, Amount and Debit/Credit Flag work together to determine positive/negative sign

General Ledger Balance Balance Type Code Buckets for monthly balances Other buckets Account Line Annual Balance Amount Financial Beginning Balance Amount Contract and Grant Beginning Balance Amount

Denormalizing Account Name Fiscal Officer Organization Expiration Date, Closed Indicator Sub-Fund Group  Fund Group Higher Education Function Code

Denormalizing Object Code Object Level Code Object Consolidation Code Reports to Object Code

Datagroups from Reference Tables Account/Organization Datagroup Object Code Datagroup Sub Accounts Sub Object Codes Year End Snapshots

The University of Arizona Dylan Cooper 520-626-5214 dacooper@email.arizona.edu Introduction of self and UA   Hi.  I’m Dylan Cooper from The University of Arizona. We are founding partners for both KFS and KC and are in the process of implementing both, although we have not set official go-live dates at this time. -Display PowerPoint Notes-

KFS DW/BI Team Doug Hester – Senior Technical Dylan Cooper – Senior Technical Nargis Memon – Junior Technical Ned Tomsheck – Accountant Nevil Pozholiparambil – Masters Student/Junior Technical   We have a team of five (more or less) working on DW/BI side of the KFS go-live. SKIP: We have two senior tech people (Doug Hester and myself), one recent MIS Masters graduate from UA (Nargis Memon), one current MIS Masters student (Nevil John) and one accountant who has been at UA for over 20 years (Ned Tomsheck). Much of the work I am showing here was done by the other people on the team, especially by Doug Hester. My primary role has been to architect the warehouse.  I have also trained our team on data warehousing topics, created template data structures and ETL jobs., and done a lot of modeling and ETL programming. I’ve also done a bit of BI modeling/content and will be turning more attention to it as we progress.

UAccess Analytics The University of Arizona Basics Front end: Oracle Business Intelligence EE Plus ETL: IBM DataStage Back end: Oracle (PeopleSoft EPM) Data Star schemas Data Marts (in development) - General Ledger, Chart of Accounts, Labor Ledger, Capital Assets and Purchasing We will go live when KFS itself goes live. SKIP: Since our existing warehouse is old school and built on completely different data sources, we’ve started over with all new technology. For the front end, we are using OBIEE+. I’ll show you a little of that in this talk. SKIP: That’s basically the old Siebel Analytics dashboard tool and Hyperion’s Interactive Studio ad hoc query tool bundled together. It also includes some other stuff stuff. For example, we’re using the old Oracle BI Publisher tool to deliver PDF files. We’re doing all our ETL work with IBM DataStage. SKIP: We are intentionally not using Oracle MV or CDC stuff because I wanted to keep the skill set required for ETL development self-contained. Our back end is Oracle. We are integrating our Kuali data into a PeopleSoft EPM warehouse that we just took live in September. SKIP: This warehouse has HR data in it and will soon have student data as well. Unlike Indiana and UC Davis, we are creating a dimensional warehouse where everything is organized into facts and dimensions. I did teach a five session dimensional modeling class and workshop to help get the team started with that. Lastly, since KFS doesn’t have much by way of built-in reporting, we are focusing first on operational reports that provide the same sort of information (more or less) that the functional offices and business managers are used to getting from the FRS system.

Trial Balance Report Start out by showing one of these reports and then drilling back through the BI and DW layers to show you how it was built. This report shows activity by fund group. It is based on our FBM061 report in FRS. I know you can’t really see it but the next few slides zoom in. I have the full thing up so you can see it has three parts: a drop-down at the top for selecting the fiscal period you are interested in, a trial balance report, and a net monthly activity report. SKIIP: I’m showing screen shots because, not being live, I don’t trust our system to be up and working when I need it to. Let me zoom in so you can see something…

Trial Balance Report I should point out that this is development data and you shouldn’t draw any conclusions about UA’s finances from this. For example, when I do testing I tend to give myself million dollar bonus. SKIP: The drop-downs for selecting the period default to the current period. When you change it, both the report I’ve zoomed on here and the period net activity report below it update with the results from that period. I’ve also set up some drill downs in the report. For example, if you click on the “State” fund group.

Trial Balance Report Drilled down from State fund group to the sub-fund level. This automatically uses the KFS sub-fund sort code when displaying the sub-funds. SKIP: I originally drilled from fund to sub-fund type but we have not configured useful categories in that yet so I skipped over to sub-fund. From sub-fund you can drill down again…

Trial Balance Report Drilled down to account. So that’s a basic report in our system. We do have more complicated ones but I wanted to stick to something I could show quickly Once everything is set up, making such a report is really easy in OBI. Basically you just drag and drop columns into your report, set filters if you want any, drag in any drop-down you need, and change any formatting you don’t like. Our idea is that a whole lot of people in the campus community can make reports themselves and do not need to rely on IT staff to do it. To help make that happen, we have two people who have been providing OBI training to campus and have had over 500 people through the classes. It seems to be working out well. To do the setting up that makes this so easy, we use the OBI Administration tool…

OBIEE Administration Tool This is where you set up the joins, drill-down hierarchies, calculated columns, metadata and names and groupings that users see when creating and running reports. I’ve opened up the account dimension in the repository here. On the right side is where you import table definitions from the warehouse. The left side is where you tweak the display characteristics. Middle is where you do most of the work. I’ve opened the drill-down on fund/subfund/account. This is where I set up the sort for the sub-fund sort. (SKIP: There is one drill-down for the fund name that goes to sub-fund name and another for the fund-code that goes to sub-fund code.) SKIP: We’re doing this work in our group because 1) it is more difficult than the other OBI work 2) the multi-developer coordination on OBI could be a lot better and 3) a bad model can produce wrong results and/or bring the database to its knees. Of course the real complexity in reporting is in setting up the warehouse so that the data that people need is easily available. So I am going to drill into our warehouse design…

Summary Account Activity Star Dimension Fiscal Period Dimension Account Activity Fact This is the star schema from which the example report was built. How many of you—just a show of hands--are either doing dimensional modeling or are familiar with it? IF LOTS OF PEOPLE NOT UP ON DIMENSIONAL MODELING: dimensional modeling is just a way of setting up your data in the warehouse. It is built around facts and dimensions. Facts are things you measure, like amounts on the GL or hours entered in payroll. Dimensions are the attributes that give those facts context, for example, account number or fund group description. The central fact table in this star contained all the amounts displayed in the report. We pre-calculated those in our ETL process so people could drag and drop them into reports. The dimension tables provide the context to describe those amounts. In our example, the fund, sub-fund and account all came from the account dimension table. The drop-downs at the top of the report used the fiscal period dimension. Our report didn’t use the object code dimension. SKIP: I intend to add a project dimension. To make this a bit more concrete, let’s look at the fact table… Object Code Dimension

One row for each account, object code and fiscal period Account Activity Fact Keys for Dimensions Summary Table One row for each account, object code and fiscal period combination Month Net Measures YTD Measures This is a summary fact table. It is summary in two ways. First, it only contains transactions for actuals, no budget or encumbrance. Second, it has only one row for each account, object code and fiscal period combination in the general ledger. This helps performance but more importantly, provides the right level for pre-computing a lot of useful values. For example, in addition to the net activity for the month, we create a set of columns with YTD information. The example report used the YTD columns. Additionally we have prior month and prior year columns to allow easy comparisons, graphing, etc. Moreover we explode out the amounts columns in each of these sets into useful categories… Prior Month Measures Prior Year Measures

Account Activity Fact Transaction Data Pivoted Data Account Acct Category Amount Income Expense 10.00 100.00 50.00 500.00 12345 ABCDE Account Income Amt Expense Amt 12345 20.00 200.00 ABCDE 100.00 500.00 For example, instead of having just one YTD amounts column, we make a separate one for each KFS basic accounting category. That way we have separate columns for fund balance, assets, liabilities, expenses, income, etc so that people can just drag those into their reports. In my diagram I’m showing just income and expense due to space constraints. I don’t have time to go into the details of our data model, but if you’re interested just find me later on or send me an email. I’d be happy to talk to you about it. I think we’re doing things in a way that is really working out. SKIP: Of course, this summary table is built from a detail fact table. The detail table has one row for every entry in the GL and has more dimensions such as balance type, document type, and origination code. We aggregate the actuals from the detail table to make the summary table. Now lets turn our attention to a dimension table…

Account Dimension Chart Info Slowly Changing Dimension Organizational Unit Info Tracks changes in account information Account Type Info Fund Info The account dimension table brings together all the data about accounts into one place for reporting. We pull data from over 30 tables to make this dimension. It is implemented as a slowly changing dimension, which means that we track changes to accounts in this table as they occur over time. For example, if an account moves from one organizational unit to another because the PI switched departments, we would make two records in the account dimension. All the transactions from before the move would be reported with the first department and all the transactions from after the move would be reported with the second department. For those of you familiar with dimensional modeling, we are using primarily Hybrid Type 1-2 SCDs. Of course to build the facts and dimensions, we need to pull data out of KFS and that is the last step I will show you here… Account Info Sub-Account Info

KFS Staging Area Staging Tables COPY OF KFS CHANGES History Tables FACTS & DIMENSIONS Report Tables We first copy almost all the KFS tables into the data warehouse on a nightly basis--after the batch jobs have run. Then since KFS has little tracking of changes built into it, we compare the current day’s data to the previous day’s data and record all the changes we find into history tables. We then use the changes to bring the fact and dimension tables up-to-date. SKIP: Lastly we record any errors we find – e.g. invalid user id in account supervisor column – into error tables. I should note, we store the complete history of changes so that we can rebuild the dimensional tables—or create new ones—at any time without losing any information. SKIP: To avoid a whole lot of work and maintenance effort, we built generic ETL jobs that use the ORA_ROWSCN pseudo-column and the OBJ_ID column in each table. This allows us to identify rows easily—by OBJ_ID—and detect changes by comparing ORA_ROWSCN values. The details of this are outside the scope of this presentation but feel free to ask me about it later.

Conclusions Dimensional Warehouse vs. Traditional Warehouse Specialized Tools vs. General Purpose Tools So that was a 15 minute tour of how we are building our reports for KFS at The University of Arizona. We started by looking at a report and then diving down through the BI and DW layers. The two points that most stand out for me in our approach are that we are creating a dimensional warehouse and that we are using specialized ETL and BI tools. I have worked on both dimensional warehouses and more traditional ones where you denormalize the operational tables and use snapshots for history. The main advantage of the dimensional approach, I think, is that you create a much richer data set that is easier for your users to access intuitively, especially with a tool such as OBI which removes many of the technical hurdles. It also sets you up very well for more in-depth analysis. The drawback is that it involves more of an up-front investment in both time and expertise. In order to build the data structures you need to understand both the data itself and the business processes involved as well as the dimensional modeling concepts. Once again feel free to grab me any time during the conference to talk about this stuff. But before I end, I would like to mention…

KFS Decision Support SIG Tuesday: 6:15 – 6:45 Conference Room 17 Wednesday: 11:00 – noon Conference Room 12 James Singleton Cornell University jim.singleton@cornell.edu Tina Golini Jessee Indiana University cgolini@indiana.edu We have recently organized a Kuali Reporting SIG. Jim Singleton (from Cornell) and Tina Jessee (from Indiana) are the co-chairs. Get them to stand up or wave. The SIG is meeting right after this presentation in Room 17. Please come. Now it’s my honor to introduce Bill Overman from Indiana University, whom you probably all know at least from the listserve. He is tremendously knowledgeable about how KFS works and is very helpful in sharing his knowledge. He will talk about Indiana’s reporting solution…

University of California, Davis

UC Davis Decision Support Decision Support Basics Front end: Cold Fusion Bank end: Oracle Data Source - General Ledger and reference tables Denormalized data Month end snapshot – ensures reports are reproducible

UC Davis Decision Support Access Broad campus access Few access restrictions Account type limits budget provisions Payroll detail limited to user’s organization

UC Davis Decision Support Output Options

UC Davis Decision Support Demonstration Demo: 1. Scheduling queries 2. Floating buttons 3. Advanced Criteria 4. Sort options 5. Data Options: pending transactions, encumbrances C&G History balances 6. Balance report 7. Transaction report 8. Reference reports 40 - documents initiated 211 – documents approved 9. Custom object groupings 10. Annual schedules –schedule B (uniform accounting codes and academic discipline)