1. Integrated Reporting Student Foundation Release 1 Business Requirements Document Confirmation

2.  IR Process and Methodology  Business Requirements  Student Revenue Analytics  Admissions  PAIR  Non-Functional Requirements  Open Items Agenda

3. This information is still in “draft” subject to feedback from:  You  Other Stakeholders  Other Working Committee members  IR Program Team Disclaimer

4.  The Business Requirements Document (BRD):  articulation of what the business needs  facilitates the process of understanding  Business -> Development  Input into the next step :  Plan & Analyze -> Design & Build IR Process and Methodology: Expectations Design/Build User Acceptance Test Plan & Analyze Test Go Live BRD

5.  BI is iterative, so things evolve and change  Process needs to be capable of handling  Open Issues  Mechanism to track issues and risks  e.g. program team might find during design that a particular requirement is not feasible  Requirements Traceability  Each requirement identified by a number  If a requirement changes we can manage impact and trace it  Delivery times  Resources  Or re-write the requirement Process and Methodology: Expectations

6. Common Background and Context  Current Environment  Planned Solution: Tools, Platform, Solution Architecture  Planned Approach – Self Service BI

7. Common Background and Context  Current Environment  Planned Solution: Tools, Platform, Solution Architecture  Planned Approach – Self Service BI

8. Current Environment

9. Common Background and Context  Current Environment  Planned Solution: Tools, Platform, Solution Architecture  Planned Approach – Self Service BI

10. Planned Solution: Foundation R1

11. Common Background and Context  Current Environment  Planned Solution: Tools, Platform, Solution Architecture  Planned Approach – Self Service BI

12. Self Service BI – What does this mean?  Doesn’t mean: Everyone starts writing their own reports

13. Self Service BI – What does this mean?  Does mean: Right tool for the right skill set  IT: deals with complexity  data management  complex content dashboards & reports  Power Users:  analysts/SMEs  build their own dashboards  build content to share within their area  General users  view pre-built reports, leverage interactivity features to customize views  provided tools to help understand the reports that are available  centralized access to UBC information  Governance!

14.  Student Revenue Analytics (SRA)  Admissions  PAIR Student Foundation BRD: Functional Scope

15. Student Revenue Analytics

16. Student Revenue Analytics Stakeholders StakeholderRoleSubject Areas of Interest Comptroller, Ian BurgessProject SponsorStudent Revenue, Faculty Funding Model, Student Registration Director of Finance, Enrolment Services, Allison See Architect and Keeper of the Faculty Funding Model. Responsible for the correct assessment of student revenue. Responsible for the correct delivery of student revenue accounting information to FMS. Student Revenue, Faculty Funding Model, Student Registration Faculties, represented by the Faculty Finance Directors As the faculty representatives who are responsible for liaising with central Finance regarding their funding allocation and responsible for managing these funds within their respective faculties Faculty Funding Model, Student Revenue, Student Registration Central Finance, including the Budget Office The budget office has an operational role in overseeing the delivery and management of the funds allocated to the faculties according to the model. Student Revenue, Faculty Funding Model, Student Registration Carla Waters, Director Finance, UBC-OResponsible for allocation of funds within UBC-O Student Revenue, Student Registration PAIRProject sponsors responsible for the enterprise-wide view of information at UBC. Student Revenue, Faculty Funding Model, Student Registration

17. Student Revenue Analytics Functional Context  Faculty Funding Model  UBC-V Faculty Funding Model (FFM) has been recently refactored  Current FFM is built in Excel and uses custom flat file extracts  Faculties would like more insight into the details behind the result  All would like to improve ease of access to data  Ad hoc analysis of student information can be challenging  e.g. registration, tuition assessments  Aside from the Faculty Funding Model  Information that ties to the FFM  Based on the same data the model is based on  Not the data generated by the model  Disparate sources of information currently

18.  Faculty Funding Model  Build the FFM on the Integrated Reporting platform  That matches the current model  Faculty dashboard that is Faculty view of the FFM (allocation) :  Same information as the current FFM  Added ability to drill down on the basis for each driver  Model needs to be managed and transparent  Versions, history  Ability to see algorithms, business rules  behind the drivers and basis values  Current Model stays in production this fiscal year Student Revenue Functional Requirements

19.  Ad hoc Analysis of Student Information for Faculties  Analysis of student enrolment  Analysis of student tuition and fees  UBC-O Student Revenue Analytics requirements  Unfettered access to information  In a central, reliable, timely, managed place  Available in a self-service manner Student Revenue Functional Requirements

20. Admissions

21. Admissions Stakeholders StakeholderRoleSubject Areas of Interest James Ridge, RegistrarBusiness owner for Admissions, Registration and Records, Student Finance Admissions, Student Revenue, Faculty Funding Model, Student Registration Fred Vogt, Deputy Registrar, UBC-OBusiness owner, Admissions, Registration and Records, Student Finance, UBC-O Admissions, Student Revenue, Student Registration (UBC-O) Andrew Arida, Director, Undergraduate Admissions Business owner for Undergraduate Admissions, International & Domestic Admissions, Student Registration Karen, McKellin, Director, International Student Initiatives Business owner for ISIAdmissions, Student Revenue, Student Registration Carleton Ng, Manager, Business Development & Strategic Operations Business manager for ISI Recruitment Admissions, Student Revenue, Student Registration Anne Marie Hague, Director, Student Recruitment & Advising Business owner for Student Recruitment - Domestic Admissions, Student Registration Stephanie McKeown, Director, Research, Planning and Analysis, UBC-O UBC-O information analyst responsible for the UBC-O view of information at UBC. Admissions, Student Registration (UBC-O) EMC membersResponsible for enrolment management for their faculty/area Admissions, Student Registration PAIRProject sponsors responsible for the enterprise-wide view of information at UBC. Admissions, Student Revenue, Faculty Funding Model, Student Registration

22. Admissions undergraduate admissions funnel prospects applicants admits accepts registrants arrivals starts application November 1

23. Admissions Functional Context  Current analysis processes are far too manual, slow and resource intensive  Power users are senior staff spending far too much time manipulating data  Standard reports, widely used  For example:  EMC reports  Application Volume reports used by admissions staff  “outgrown” the current implementation  Broader appetite for more interactive analysis capabilities  Operational SIS data less than optimal for analysis  Gaps filled by power users doing custom analysis + support from Information Systems team

24. Admissions Functional Context Power Users:  Focus of analysis: monitoring undergraduate admissions funnel  Currently work from a common data set  Referred to as “merged file” or “flat file”  Daily snapshot of “the funnel”  200 + data fields  Unwieldy, vulnerable to failure, security  Generate some standard views for decision-making  Ad hoc analysis on demand  Share as required

25.  Funnel data managed in the Enterprise Data Warehouse  Managed, automated, timely, clean, centrally accessible, safe, secure  Readily available to power users for analysis  Consider and analyze all of the current admissions content:  Application Volume reports  EMC Reports  ISI Enrolment Summary Report  Various ad hoc reports  IR Program Team to support new dashboard and analysis creation  to migrate necessary functionality from current to IR  avail it to users for self-service Admissions Functional Requirements

26.  Not be included in Student Foundation Release 1:  Awards data  EZ Recruit data  Post-baccalaureate, graduate admissions  Not in SIS – managed in different systems  Planned for future releases Admissions Not In Scope

27. PAIR

28. PAIR Functional Context  Thought leaders in the definition of the enterprise-wide data terms and metrics  Provides enterprise-wide view of information  Both internal and external audiences  Combining information from a plethora of UBC and external data sources  Source of official UBC-wide statistics, internal & external performance indicators, Place and Promise performance indicators, research indicators, ministry reports  Advanced analytics and modeling using tools such as R and SPSS  Would like to replace/update/improve their current infrastructure  Both presentation tools and data management infrastructure  To increase efficiency  Would like to adopt University-wide infrastructure (IR)  Not replacing the advanced analytics and modeling

29.  Active, leadership role in data governance is natural  Use OBIEE to build PAIR content  audiences both internal to UBC and external  Data to support PAIR content (i.e. data in the current PAIR DW):  to be housed in the IR infrastructure  distinct from IR data structures for now  look for opportunities to merge PAIR/IR  acknowledged complexity in linkage to non SF-R1 data sources  data subject areas: student, surveys, employee, research, finance  Not implementing advanced analytics in IR  may import some results (TBI) PAIR Requirements

30. Conformance and Integration Requirements  Design and implementation acknowledges requirement for conformed dimensions  Examples include:  Person  Time: academic calendar, financial calendar, …..  Organization: academic vs finance …..  Curriculum  Need for Governance  People  Process  Data Cookbook

31.  Data Conversion and History Requirements  Self Service Reporting and Governance Requirements  Security, Access and Privacy Requirements  Performance and Availability Requirements Non-Functional Requirements

32. Non Functional Requirement: Data Conversion and History  Historical scope will vary across and within data sets  Student Revenue Analytics  FFM requires 2013S forward  Analysis requires end of session snap shots back to 2003/04  Admissions:  80% of analysis requires 2-3 years detailed history;  The balance: monthly snapshots for 10 years  PAIR  10 years history, 3-5 snapshots per year; 20 years archived  Consider sources outside enterprise databases  PAIR archives  Flat files

33. Non Functional Requirement: Self Service Reporting And Governance  Guidelines and infrastructure are required to govern official content  Governing bodies will be Working and Governance Committees  PAIR will have a significant role  Guidelines need to be developed for content creators both within and outside UBC-IT  Data Cookbook will facilitate:  Understanding of reports and terminology by users  Governance of metrics, terminology and report request  Training and Change Management will be an integral part of this process

34. Non Functional Requirement: Security Access and Privacy  Have Engaged  Paul Hancock, Information Privacy and Access Manager  Larry Carson, Information Security Management  Liana Leung, Information Security Officer for Student  Internal Audit  Creating a Privacy Impact Assessment  Following UBC Information Security Manual

35. Questions?