SU Budget Process And Systems Presentation

  • 1,614 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,614
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Discussion of Stanford University Budget Process & Systems September 6, 2005 Dr. Andrew Harker Director of Budget Management [email_address] 650.725.0666
  • 2. Outline
    • Stanford Financial Overview
    • Stanford Financial Management
    • Changing Role of the “Budget”
    • Financial Information Systems
    • Budget Monitoring/Variance Reporting
    • Demonstration of Systems
  • 3. Financial Overview
    • Fiscal Year: September – August
    • In addition to the University:
      • Two Hospitals
      • Limited Liability Corporation(s)
    • Financial data presented both in GAAP and “Fund Accounting” formats
    • The following are some of the ways we look at/present financial information:
  • 4. 2005/06 Consolidated Budget by Line Item $ in millions
  • 5. Consolidated Budget by Unit Academic Units 61% 2005/06 Total = $2.8B
  • 6. 2005/06 Consolidated Budget by Fund Type $ in millions
  • 7. FY2004 Statement of Activities to Consolidated Budget Crosswalk (in millions of dollars)
  • 8. FY2004 Operating Results vs Budget Consolidated Budget Version (in millions of dollars)
  • 9. FY2004 Consolidated Budget Results by Fund Type (in millions of dollars)
  • 10. FY2004 Consolidated Budget Results by Fund Type (in millions of dollars)
  • 11. Outline
    • Stanford Financial Overview
    • Stanford Financial Management
    • Changing Role of the “Budget”
    • Financial Information Systems
    • Budget Monitoring/Variance Reporting
    • Demonstration of Systems
  • 12. Financial Management Overview
    • Modified Centralized Budget Model
      • Formula Units: Med School, Business School, Continuing Studies/Summer Session
      • Non-formula Units (~30)
    • Funds controlled by budget units
      • Although there also are “University” funds
    • ~30k cost centers; ~10k positions
    • ~200 people responsible for budget entry
  • 13. Financial Management Overview Hospitals LLCs School of Medicine Graduate School of Business Continuing Studies/ Summer Session “ Non-formula Units” (Provost GF Allocations) Auxiliary Enterprises University Stanford Consolidated Financials
  • 14. Annual Budget Cycle
    • Load “9/1” Consolidated Budget into financial reporting system
    • Analyze past year’s financials
      • Tie GAAP to Fund Accounting
    • Variance Analysis of prior year
    • Update LRF assumptions
    • Preliminary budget letters from units
    • Begin budget meetings w/Provost’s Budget Group
    CONTINUALLY WORKING TO DO BETTER THAN BEFORE “ Local Management Budgets”: units rebudget “Revenue/Expense Control” as they choose, to display on fund/expenditure statements; these budgets, however, are “ignored” by Budget Office FALL WINTER SPRING SUMMER
    • Continue budget meetings
    • BoT approves tuition, R&B, payout rate, salary program
    • Determine final GF allocations
    • High level Projections and Variance Analysis
    • Load proposed salaries, endowment income projections into Budget System • Units enter their detailed budgets into Budget System • Preliminary Budget Letters from units • Continue Variance Analysis and YE Projections • Close out fiscal year
    • From Units (“Bottom-up”):
      • 6 month YE projections & Variance Analysis
      • Next year’s Consolidated Forecast
      • Including Formula (“autonomous”)
    • “ Top-down” Consolidated Budget Forecast
      • Formulate Projected Statement of Activities
    • HROs enter proposed salaries for next year
    • Present Budget Plan to BoT for approval
    Provost’s Budget Group
  • 15. Overview of the Non-formula Budgeting Process Compensation Analysis Capital Planning Tuition and Financial Aid Analysis Research Volume and Rate Projections Academic and Administrative Units Develop Budget Plans Analysis of School Balance Sheets and Consolidated Income Flows General Fund Allocations to Academic and Administrative Units Amount of University Reserve Decisions on Major Program Priorities and Initiatives Consolidated Budget Plan – Submitted to Board of Trustees in June New Initiatives Budget Group – Oversight and Advice on Strategic Priorities Budget Office Creates Long Range Forecast Board of Trustees – Policy Decisions on Salary Program, Tuition, And Financial Aid Provost Makes Allocation Decisions
  • 16. How are funds budgeted? “ Pooled” budgets at department and fund type level, at detailed codes OB Auxiliary Service Center Designated Endowed Gifts Grants & Contracts Detailed Budgets, usually to specific cost center and natural account level, and position level Budgeted at combination of specific CC and “Pools” at department and fund type level, at detailed codes University UR
  • 17. Budget Process
    • Org Chart for President (see handout)
      • Finance function reports to President
    • Org Chart for Provost (see handout)
      • Budget function reports to Provost
  • 18. Outline
    • Stanford Financial Overview
    • Stanford Financial Management
    • Changing Role of the “Budget”
    • Financial Information Systems
    • Budget Monitoring/Variance Reporting
    • Demonstration of Systems
  • 19. How has the budget evolved?
    • Until 1991, budgeting focused on “Operating Budget”
      • General Funds plus Restricted Funds supporting on-going operations (mainly endowed chairs) and Auxiliaries
    • Dr. Gerhard Casper became president in 1991; declared intention to focus on all funds – “Consolidated Budget”
    • No systems in place to support this kind of budget development, so for several years stumbled through using Excel to develop high level Consolidated Budgets
    • At this same time, the University embarked on a long-term process to replace “legacy” systems with “market-place” solutions, including budget formulation tool to support new budgeting demands
    • In the legacy system, the “budget” also served a “control”/fund tracking function
      • For unrestricted funds (OB, Aux, SC), the legacy accounting system did not track funds separately by Cost Center
  • 20. Into what has it evolved?
    • The notion of a “static budget”: the 9/1 Consolidated Budget
      • For reporting to the Board, report only variances rather than “revised” budgets
    • Once the budget is set in September, units manage their budgets “locally”, for their own purposes, revising them (or not) at their discretion
      • Variance reporting to the Budget Office is done against the 9/1 version of the budget
      • We developed a custom web application (“iBudgets”) due to limitations/complications of entering budget revisions into Oracle
    • Oracle functionality “freed” the fund tracking role of the budget on unrestricted funds
    • Continual refinement of what we should include in the budget
      • Fund accounting view vs. GAAP view
      • E.g. we don’t budget depreciation, but we budget some expense accruals
  • 21. Outline
    • Stanford Financial Overview
    • Stanford Financial Management
    • Changing Role of the “Budget”
    • Financial Information Systems
    • Budget Monitoring/Variance Reporting
    • Demonstration of Systems
  • 22. Financial Information Systems
    • PeopleSoft (HR & Student Information)
    • Oracle
      • General Ledger (GL):
        • Asset, Liability, Equity, Revenue, and Transfers detail
        • Expenditure summary
      • Grants Accounting (GA): Expenditure detail
      • Fixed Assets, AP, AR, PO, etc.
    • Hyperion (Essbase, Planning, Reports, Analyzer, Master Data Management)
    • Reportmart (reporting portal)
    • Pre-written reports via Portal & DW ad-hoc querying
      • Business Objects
      • Brio (now Hyperion Intelligence)
    • Custom web apps: iJournals, iBudgets
  • 23. History of Budget Solution
    • Pre-1996, all systems were “legacy” (home-grown)
      • Mainframe database, hard-coded reports
      • “ Operating Budget” only
          • General Funds, plus restricted funds supporting on-going operations (mainly endowed chairs)
      • Data managed mainly by staff in Controller’s Office
    • Home-grown salary management and analysis system (“SMAS”)
      • Used for salary planning/setting and turning those plans into salary budget data
    • Push to all-funds budgeting led to conclusion that no home-grown system would adequately support users
  • 24. Hyperion Pillar
    • Stanford has had a strong relationship with Hyperion Solutions since 1995
      • Along with University of Pennsylvania, Stanford first University using Pillar (microcomputer-based product)
      • Pillar used for FY96 through FY03 budget entry
      • 12 different, separate motherships (databases) and administrators due to size & internal management practices
    • Implementation, using Hyperion consulting, took 8 months
      • Adapting to work with facets of fund accounting
    • Started with version 2.0; each year used a new version of software
    • After initial work by Hyperion consulting, all training and documentation done in-house
    • Once completed, Pillar data loaded into University Data Warehouse to consolidate all 12 files and to facilitate data extraction/feed to legacy mainframe batch accounting system
  • 25. Why Move From Pillar to Planning?
    • “ Hit the wall” with Pillar limitations
      • Size issues
      • Reporting Issues (e.g. P&L by cost center)
      • Integrating data from all files for review, analysis, and reporting required loading data into another environment (our data warehouse)
    • Institutional move to Marketplace Web-based financial systems
      • Started evaluation process in 2001
      • Final evaluation between Hyperion Planning and Solver/ Great Plains (Microsoft)
      • Chose Hyperion based on established relationship, track record, and product capabilities
      • Simultaneous conversion from legacy financial systems and chart of accounts caused significant implementation issues
    “ Push/Pull”
  • 26. Pillar to Planning
    • Our experience with Pillar shaped our initial design of Planning
      • Position budgeting: Units x Rates
      • Line-item Detail
      • Reforecasting/Revising budgets
      • Reporting
      • Usability on Macs (initially*) as well as PCs
      • Security/Access
      • Administration/Integrity of metadata
      • Central vs. Distributed Maintenance
      • Integration into Financial/UDW systems
  • 27. Pillar to Planning
    • Technology/Infrastructure paradigm shift
      • From: microcomputer “spreadsheet”/relational database
      • To: server-based, network-configured, multidimensional database with complex computer program interactivity
      • Infrastructure issues rose to the top
      • Substantial reliance on IT support where previously not needed
  • 28. Pillar to Planning
    • Design Issues of paramount concern:
      • Security (user access to data)
        • To allow complex Position Budgeting
        • Design & Maintenance of Forms & Reports
      • Metadata “overhead”: Size of the cubes
        • Org Structure
        • Chart of Accounts
        • Number of Cost Centers
      • Tech Infrastructure unique to Universities
        • Kerberos Authentication vs. “Firewall”
      • Performance (apparent speed to users, control over calculations)
  • 29. Hindsight: Planning “issues”/”growing pains”
    • Hyperion Planning initially an immature product
      • Version 1.6 (then) vs 3.5 (now)
    • We fell short of due diligence in vetting implementation design
      • Did not challenge our model assumptions sufficiently
    • Our initial design constrained use of Planning/Essbase functionality (e.g. security)
      • Created a massive amount of unnecessary grunt work in form and report duplication
    • Unique characteristics of a university technology infrastructure
    • Some initial design specifications could not be met (separate salary planning vs. consolidation cube)
      • Led to change in design to meet salary planning needs
    • To balance cube size and performance: 3 separate apps
    • Oracle Financials implementation difficulties derailed implementation
  • 30. System in Use the first time: A Bumpy Ride
    • System went live with version 3.0 in May 2003 for FY04 Budget formulation
      • Chose a mix of cost-center detail vs. “pooled” budgeting
      • Because Essbase security not enabled, security of data access achieved through form/report design
          • Thousands of forms and reports created
      • Many forms/reports not ready for many users
      • Some user issues with centralized calculations of business rule
      • Some system HTML bugs (screen redraw issues)
      • Analyzer not implemented
      • Integrated workflow not utilized
      • Much more dynamic reporting than Pillar, but no user control/ability to design
      • “ Real-time” central access to data was useful
  • 31. Smoothing out the rough edges: “Growing Up”
    • Revisited system design and assumptions for FY05
      • Utilized Hyperion consulting to vet ideas, verify proposals
      • Add additional metadata (cost centers) for more detail
      • Thorough Hyperion infrastructure review
          • Many software link/install issues resulted from several version upgrades over two years
      • Changed design to enable use of native Essbase security
          • Prelude to use of Analyzer to give users powerful ad-hoc analysis and reporting
          • Significantly reduced number of forms/reports to be created: let the system do the work
    • Version 4.1 for FY07 process
      • Improvements in functionality for administrators and end-users
      • Improvements in performance and stability
    • Import summarized data from three different apps for a Consolidated View
      • This process is more or less programmed to be done seamlessly within the software’s functionality
  • 32. What we have gained: the benefits
    • A web-based budget formulation and reporting system
      • Accessible from home/wherever
    • Better control over integrity of metadata
    • “ Real-time” access to budget entry progress
      • Much greater ability to monitor the budget along the way
    • Better budget process management
    • Much more flexibility in report design than Pillar
    • Better ability to report on Consolidated Budget
      • Including ability to incorporate “crosswalk” to Statement of Activities
    • No software overhead on user machines
    • System stability (no unplanned down time—more or less)
  • 33. Hyperion Products
    • Hyperion Planning for Data Entry
    • Hyperion Reports for canned reports
    • Hyperion Analyzer for “dashboard” and ad-hoc query
    • Hyperion Essbase—an “OLAP” database—is the engine
    • Hyperion Master Data Management (Razza)—a hierarchy maintenance tool; currently used to maintain the “master” university admin org hierarchy
    • Hyperion Business Intelligence (Brio)
    Business Objects Products
    • Business Objects desktop
    • Web BO
    Also used for web portal report writing and user-controlled ad-hoc querying Used for web portal report writing and limited ad-hoc querying
  • 34. Current Resources
    • Hyperion:
      • UBO Staff: ~4 FTE
        • Support & train the users; maintain & enhance the app
      • ITSS (infrastructure) support: ~2 FTE
        • Support the servers, networking, databases
        • Funding incorporated in “Core” system support budget in ITSS
      • Medical School: ~2 FTE
        • Support their own users; configure app for their needs
    • Infrastructure:
      • Hyperion applications: 6 Windows Servers
      • Development, Test/Training, Production environments
  • 35. System Architecture
  • 36. Current State of applications/systems
    • Hyperion applications
      • Target audience: budget officers, finance managers, department managers
        • Not down to the level of the reconciler of the PTA
      • Used by ~ 200 users through the web (Internet Explorer on PC)
      • Used for annual budgeting process (except Sponsored by OSR and Capital projects)
        • those detail budgets are entered directly into Oracle GA
      • Also used by Medical School for current Year-end Projections & tied to next year’s budget
      • Application owned/maintained by UBO; ITSS supports infrastructure
  • 37. Hyperion: A Common “look & feel” of entry forms and reports
    • Budget entry:
      • Users can define the subset of object codes/expenditure types they want people budgeting at
      • Access to data limited by users’ security (maintained in Hyperion)
      • Working towards “standard” views that are compatible with both Consolidated Budget and external Financial Statements
    • Budget Reporting/Analysis
      • A variety of views of the data that show fund type, scenario, year, unit across rows or columns
      • Hyperlinked drill-through capability to “investigate” numbers from a high level down to a certain level of detail
        • Does not store transaction-level detail; ReportMart3 will provide this support through reports that will show detailed transactions that tie to the aggregated data
  • 38. Budget Entry via Hyperion Planning: Portal Screen
  • 39. Budget Entry via Hyperion Planning: Non-Salary
  • 40. Budget Entry via Hyperion Planning: Annual Rate
  • 41. Budget Entry via Hyperion Planning: Percent Distribution
  • 42. Budget Analysis & Reporting using Hyperion: “cross-tab” views
  • 43. Budget Analysis & Reporting using Hyperion: “time series” views
  • 44. Budget Analysis & Reporting using Hyperion: “time series views”
  • 45. Budget Analysis & Reporting using Hyperion: “slicing & dicing”
  • 46. Outline
    • Stanford Financial Overview
    • Stanford Financial Management
    • Changing Role of the “Budget”
    • Financial Information Systems
    • Budget Monitoring/Variance Reporting
    • Demonstration of Systems
  • 47. Goals Moving Forward
    • Use Hyperion for more than just budgeting
      • Load Actuals from EDW
      • Use it for Variance Analysis
      • Enable units to develop Rolling Forecasts
    • Roll-out Hyperion Analyzer
      • Web-based tool that accesses the data stored in Hyperion
      • Works as a “dashboard”
      • Works as an ad hoc analysis tool
  • 48. Current Variance Analysis Process Hyperion (Budgets) Oracle (Actuals) Star Schema Star Schema DSS Bus Objects Collection Bus Objects Query Excel Visual Basic Macro Variance Report Spreadsheets Analysis by Units Units email Excel SS to UBO UBO reviews each SS and then loads into Hyperion
  • 49. Variance Reporting via Excel Spreadsheet
    • (see handout)
  • 50. Future Variance Analysis & Reforecasting Process
    • Stored within Hyperion:
      • 9/1 Consolidated Budget (12 months of data from Budget cycle)
      • Actuals (e.g. Sep ~ Mar of Actuals from Oracle)
    • Goals:
      • To identify and analyze variances from budget
      • To create a Rolling Forecast (Sep ~ Mar Actuals + Apr ~ Aug Budget) with capability to adjust remaining budget numbers
  • 51. Concepts/Rationale for Goals
    • Hyperion is an excellent tool for analysis of summarized data
      • Generates fast results for known retrieval patterns
      • Can present both Consolidated Budget and Statement of Activities views
    • Consolidation of all units is easy
    • Good roll-up and drill-through capability
    • We design standard reports and data entry forms/templates for all the units to use
    • It can facilitate quarterly budgeting and variance reporting
    • Pre-Oracle: from 1995-2003 we had, via Pillar & UDW, a mechanism units used for budget, actuals, and reforecasting analysis; we want to give this utility back to the users
  • 52. Proposal: Hyperion would house most of the budget process Analysis by Units Reportmart3/DSS Hyperion Oracle (Actuals) EDW Since Hyperion will only hold data at a certain level of detail, RM3/DSS can provide queries for analysis when more detail is needed Units enter their analysis/forecasts into Hyperion UBO enters “top-down” forecast/budget into Hyperion Budget, Variance, & Reforecast Reports (printed & on-line) Ad-hoc analysis & reporting
  • 53. Variance Reporting using Hyperion
  • 54. “ Business Intelligence” using Hyperion Analyzer
  • 55. “ Business Intelligence” using Hyperion Analyzer
  • 56. Outline
    • Stanford Financial Overview
    • Stanford Financial Management
    • Changing Role of the “Budget”
    • Financial Information Systems
    • Budget Monitoring/Variance Reporting
    • Demonstration of Systems