Spanning the Reporting Abyss

29
Spanning the Reporting Spanning the Reporting Abyss Abyss A Reporting Strategy A Reporting Strategy using functional tables using functional tables in a data warehouse in a data warehouse UM Reporting Task Force UM Reporting Task Force March 13, 2003 March 13, 2003

description

Spanning the Reporting Abyss. A Reporting Strategy using functional tables in a data warehouse UM Reporting Task Force March 13, 2003. About the Presenter. Art Brooks, Dir ADP UMR 12 years in Admissions and Registrar’s Office 24 years in administrative computing - PowerPoint PPT Presentation

Transcript of Spanning the Reporting Abyss

Page 1: Spanning the Reporting Abyss

Spanning the Reporting AbyssSpanning the Reporting Abyss

A Reporting StrategyA Reporting Strategyusing functional tables using functional tables

in a data warehousein a data warehouseUM Reporting Task ForceUM Reporting Task Force

March 13, 2003March 13, 2003

Page 2: Spanning the Reporting Abyss

About the PresenterAbout the Presenter

Art Brooks, Dir ADP UMRArt Brooks, Dir ADP UMR– 12 years in Admissions and Registrar’s Office12 years in Admissions and Registrar’s Office– 24 years in administrative computing24 years in administrative computing

» 16 years involved with data warehousing16 years involved with data warehousing Participant in the development, implementation and for Participant in the development, implementation and for

several years the support of current SISseveral years the support of current SIS Involved at various levels with SFA, HR, Univ. Involved at various levels with SFA, HR, Univ.

Advancement and other systemsAdvancement and other systems Participant in the design and a user of the data warehouse Participant in the design and a user of the data warehouse

and functional tables.and functional tables.

Page 3: Spanning the Reporting Abyss

Basic PerspectivesBasic Perspectives

1. 1. A core system is a corporate foundation A core system is a corporate foundation NOT NOT an entire solution!an entire solution!

2. Reporting can only be successful when 2. Reporting can only be successful when there there is is a solid database foundation.a solid database foundation.

3. Trying to be the solution to everyone’s 3. Trying to be the solution to everyone’s needs, needs, satisfies no one.satisfies no one.

Page 4: Spanning the Reporting Abyss

Many dimensions of reporting:Many dimensions of reporting:

A. Vendor providedA. Vendor provided– 1. Payroll1. Payroll

– 2. Purchasing2. Purchasing

– 3. Grade reports3. Grade reports

B. External agency requirements (may be vendor supplied)B. External agency requirements (may be vendor supplied)– 1. State mandated1. State mandated

– 2. Federal Mandated2. Federal Mandated

– 3. Grant applications3. Grant applications

Page 5: Spanning the Reporting Abyss

Additional dimensionsAdditional dimensions

C. University-wideC. University-wide

– 1. Budget planning1. Budget planning

– 2. Miscellaneous reporting2. Miscellaneous reporting D. Campus uniqueD. Campus unique

– 1. Phone directories1. Phone directories

– 2. Lists and labels2. Lists and labels

– 3. Miscellaneous3. Miscellaneous

– 4. Ad hoc4. Ad hoc

Page 6: Spanning the Reporting Abyss

Multiple Data SourcesMultiple Data Sources Need to weigh requirement for currency of data, then apply to Need to weigh requirement for currency of data, then apply to

appropriate data source.appropriate data source. A. Real time (small percentage and must be justified) (production A. Real time (small percentage and must be justified) (production

system)system)– 1. On-line registration1. On-line registration– 2. Account balances2. Account balances– 3. Leave information3. Leave information

B. Close of business day (majority of usage) (data warehouse)B. Close of business day (majority of usage) (data warehouse)– 1. Phone directories1. Phone directories– 2. Mailings of any kind2. Mailings of any kind– 3. Standard reports3. Standard reports

C. Frozen data (data warehouse)C. Frozen data (data warehouse)– 1. External agency reports1. External agency reports– 2. Longitudinal reports2. Longitudinal reports– 3. Statistical analysis3. Statistical analysis

Page 7: Spanning the Reporting Abyss

Corporate SystemsCorporate Systems

PeopleSoftPeopleSoft– 1. Finance1. Finance

– 2. Human Resources2. Human Resources

– 3. Student3. Student

Other corporate systems include (but not limited Other corporate systems include (but not limited

to)to)::– 1. Advance (University Advancement)1. Advance (University Advancement)

– 2. fsaAtlas (Sevis reporting) (INS)2. fsaAtlas (Sevis reporting) (INS)

– 3. Loan Management System3. Loan Management System

Page 8: Spanning the Reporting Abyss

Data WarehouseData WarehouseA logical reporting solutionA logical reporting solution

The most logical arena where corporate systems and The most logical arena where corporate systems and campus unique systems can be assembled to support the campus unique systems can be assembled to support the business needs of the organization.business needs of the organization.

Since NO vendor provides an all-inclusive suite of Since NO vendor provides an all-inclusive suite of software for the University’s business needs in totality, a software for the University’s business needs in totality, a data warehouse is the sole solution. data warehouse is the sole solution.

The data warehouse needs to be viewed as the foundation The data warehouse needs to be viewed as the foundation for daily business reporting. (i.e. administrative core for daily business reporting. (i.e. administrative core systems need to be viewed as the source for accurate data, systems need to be viewed as the source for accurate data, a data repository, and the data warehouse the distributor of a data repository, and the data warehouse the distributor of that collective data.)that collective data.)

Page 9: Spanning the Reporting Abyss

Data WarehouseData Warehouse‘Out-house’ over ‘In-house’‘Out-house’ over ‘In-house’(Out of core system vs In core system)(Out of core system vs In core system)

Maintained outside the core system reduces the Maintained outside the core system reduces the ‘politics’ of the data contained.‘politics’ of the data contained.

Allows for the definition to be molded according Allows for the definition to be molded according to the needs of the local entity.to the needs of the local entity.

Provides greater flexibility in structure.Provides greater flexibility in structure. Provides for the potential of local control.Provides for the potential of local control. Makes it easier to incorporate local data/systemsMakes it easier to incorporate local data/systems Keeps consistency in the event of a major change Keeps consistency in the event of a major change

in the core system.in the core system.

Page 10: Spanning the Reporting Abyss

UMR Administrative Systems StaffUMR Administrative Systems Staff1 director, 5 programmers to provide some level of 1 director, 5 programmers to provide some level of

support for:support for:

– Affirmative ActionAffirmative Action

– BookstoreBookstore

– AdmissionsAdmissions

– BudgetBudget

– CashiersCashiers

– Chancellor’s OfficeChancellor’s Office

– Deans officesDeans offices

– Faculty EvaluationsFaculty Evaluations

– Food ServiceFood Service

– GrantsGrants

– Human Resources Human Resources – Institutional ResearchInstitutional Research– International AffairsInternational Affairs– KUMR radioKUMR radio– Registrar’s OfficeRegistrar’s Office– Residential LifeResidential Life– Student AffairsStudent Affairs– Student Financial AidStudent Financial Aid– Student LoansStudent Loans– University University

AdvancementAdvancement

Page 11: Spanning the Reporting Abyss

Summary of UMR’s Data Warehouse ExperienceSummary of UMR’s Data Warehouse Experience

1. August 1986 – initiated the campus data warehouse effort.1. August 1986 – initiated the campus data warehouse effort. 2. January, 1988 – introduced first activity on Gopher. (precursor to 2. January, 1988 – introduced first activity on Gopher. (precursor to

the Web) (electronic class rolls)the Web) (electronic class rolls) 3. Fall, 1998 – functional table concept formulated.3. Fall, 1998 – functional table concept formulated. 4. May, 1999 – functional table concept first applied with University 4. May, 1999 – functional table concept first applied with University

Advancement system. (Advance)Advancement system. (Advance) 5. March, 2000 – impact of PeopleSoft on reporting inventoried 5. March, 2000 – impact of PeopleSoft on reporting inventoried

(applications/reports ceasing to function)(applications/reports ceasing to function)– A. Approximately 3,000 reportsA. Approximately 3,000 reports

– B. 26 applicationsB. 26 applications 6. October, 2000 – began translating PeopleSoft data into legacy 6. October, 2000 – began translating PeopleSoft data into legacy

format.format.

Page 12: Spanning the Reporting Abyss

Functional Table ConceptFunctional Table Concept

A reporting strategy that focuses on formatting the report, A reporting strategy that focuses on formatting the report, NOT selecting the data. It utilizes the creation of ‘event NOT selecting the data. It utilizes the creation of ‘event oriented, functional tables’. oriented, functional tables’.

GOAL – to produce reports with ZERO table joins and GOAL – to produce reports with ZERO table joins and ZERO ‘where’ statements.ZERO ‘where’ statements.

Basic principle – Basic principle – SIMPLIFICATIONSIMPLIFICATION

Page 13: Spanning the Reporting Abyss

Functional Table Concept was developed to:Functional Table Concept was developed to:

1. ‘Empower the users’1. ‘Empower the users’ 2. Simplify the data structure2. Simplify the data structure 3. Reduce report development time3. Reduce report development time 4. Reduce processing time for the server (quicker 4. Reduce processing time for the server (quicker

response)response) 5. Improve programmer efficiency5. Improve programmer efficiency 6. Provide another tool for reporting6. Provide another tool for reporting

Page 14: Spanning the Reporting Abyss
Page 15: Spanning the Reporting Abyss

Basic ProcessBasic Process

User makes request to functional lead, including a draft of User makes request to functional lead, including a draft of the desired report, if possible.the desired report, if possible.

The ‘design team’ (functional lead & programmer) defines The ‘design team’ (functional lead & programmer) defines a unique table that may be a combination of several core a unique table that may be a combination of several core system tables, or core tables and local tables.system tables, or core tables and local tables.

That new table pre-selects data and eliminates the need for That new table pre-selects data and eliminates the need for such selects as:such selects as:– 1. Location (campus)1. Location (campus)

– 2. Effective date2. Effective date

Report is written by user/functional lead/programmerReport is written by user/functional lead/programmer

Page 16: Spanning the Reporting Abyss

Usage with PeopleSoftUsage with PeopleSoft

1. Determined the UMR or UM data warehouse, by 1. Determined the UMR or UM data warehouse, by definition could be viewed as a set of functional tables.definition could be viewed as a set of functional tables.

2. Basic premise – if the legacy data could be converted to 2. Basic premise – if the legacy data could be converted to PeopleSoft, then the PeopleSoft data could be translated to PeopleSoft, then the PeopleSoft data could be translated to a functional table.a functional table.

3. Have NEVER stated 100% of the PeopleSoft data could 3. Have NEVER stated 100% of the PeopleSoft data could be translated.be translated.

4. Perspective – if SOME of the applications or reports can 4. Perspective – if SOME of the applications or reports can be retained, then more time is available for staff to work be retained, then more time is available for staff to work on new requirements.on new requirements.

Page 17: Spanning the Reporting Abyss

MisunderstandingMisunderstanding

‘‘All you are trying to do is keep the legacy system All you are trying to do is keep the legacy system running to avoid a new system!’running to avoid a new system!’

NO! NO! Programming resources are scarce.Programming resources are scarce. Offices MUST keep running in the transition to a new system.Offices MUST keep running in the transition to a new system. NO vendor can supply more than a base set of reports with NO vendor can supply more than a base set of reports with

their system.their system. We are trying to keep our reports running until replacement We are trying to keep our reports running until replacement

reports can be prepared.reports can be prepared. Without their daily reports, offices will either be seriously Without their daily reports, offices will either be seriously

impaired or cease to function.impaired or cease to function. The technique is used with other applications on a daily basis.The technique is used with other applications on a daily basis.

Page 18: Spanning the Reporting Abyss
Page 19: Spanning the Reporting Abyss

Introduction of Hybrid TablesIntroduction of Hybrid Tables

After further experience and discussion it was After further experience and discussion it was realized the functional tables could be hybridized realized the functional tables could be hybridized to satisfy specific reporting needs and to provide a to satisfy specific reporting needs and to provide a transitional bridge to the future.transitional bridge to the future.

Definition – a hybrid functional table is one that Definition – a hybrid functional table is one that has data derived from disparate systems. has data derived from disparate systems. (normally legacy and PeopleSoft)(normally legacy and PeopleSoft)

Hybrid tables can become transitional tables.Hybrid tables can become transitional tables. With time, hybrid tables can become normal With time, hybrid tables can become normal

functional tables. (When the legacy data is no functional tables. (When the legacy data is no longer required, the columns cease to be filled.)longer required, the columns cease to be filled.)

Page 20: Spanning the Reporting Abyss
Page 21: Spanning the Reporting Abyss

In Production -- NEWIn Production -- NEW

1. Admissions reports (on the Web or on demand)1. Admissions reports (on the Web or on demand) 2. Admissions edits (compares PeopleSoft data 2. Admissions edits (compares PeopleSoft data

with legacy to identify discrepancies between with legacy to identify discrepancies between systems)systems)

3. Faculty grant reports on the Web3. Faculty grant reports on the Web 4. Institutional Research analytical tables4. Institutional Research analytical tables 5. Vacation/Sick Leave reporting 5. Vacation/Sick Leave reporting Other uses (non-PeopleSoft):Other uses (non-PeopleSoft):

– 1. Advance system (hundreds of reports)1. Advance system (hundreds of reports)– 2. Miscellaneous reports2. Miscellaneous reports

Page 22: Spanning the Reporting Abyss

In Production -- LegacyIn Production -- Legacy

1 ChemTrack (campus chemical tracking system that 1 ChemTrack (campus chemical tracking system that requires faculty data from HR)requires faculty data from HR)

2 CIS account creation and maintenance (HR data)2 CIS account creation and maintenance (HR data) 3. Graduate Teaching report (legacy data from SIS and 3. Graduate Teaching report (legacy data from SIS and

Cashiers with HR data from PeopleSoft)Cashiers with HR data from PeopleSoft) 4. HR frozen tables.4. HR frozen tables. 5. Miscellaneous lists and labels from HR (required minor 5. Miscellaneous lists and labels from HR (required minor

tweaking for length of line)tweaking for length of line) 6. PRO (new student pre-registration) (in production using 6. PRO (new student pre-registration) (in production using

translated PS data since Jan, 2001)(starting THIRD year)translated PS data since Jan, 2001)(starting THIRD year) 7. UIDS – (HR data. NOT in production, but ready for 7. UIDS – (HR data. NOT in production, but ready for

testing)testing)

Page 23: Spanning the Reporting Abyss

In Production -- HybridIn Production -- Hybrid

1. Affirmative Action (for 2003 report, data came from PS 1. Affirmative Action (for 2003 report, data came from PS 2002 HR and legacy 2001 HR)2002 HR and legacy 2001 HR)

Chancellor’s summer mailing to newly admitted and Chancellor’s summer mailing to newly admitted and currently enrolled students (address data from PS for currently enrolled students (address data from PS for admits and SIS for currently enrolled.)admits and SIS for currently enrolled.)

3. Chancellor’s Christmas cards (HR and Retiree from PS 3. Chancellor’s Christmas cards (HR and Retiree from PS and University Advancement from Advance system)and University Advancement from Advance system)

4. Exam data (PS and SIS)4. Exam data (PS and SIS) 5. SEVIS reporting (Admissions data from PS and enrolled 5. SEVIS reporting (Admissions data from PS and enrolled

data from SIS)data from SIS) 6. Web phone directory (HR from PeopleSoft and student 6. Web phone directory (HR from PeopleSoft and student

from SIS)from SIS)

Page 24: Spanning the Reporting Abyss

PeopleSoft Modules InvolvedPeopleSoft Modules Involved

1. Admissions – in production1. Admissions – in production 2. HR – in production2. HR – in production 3. SA – 3. SA – still testing and developing. Have been able to get results still testing and developing. Have been able to get results

from over 150 legacy reports.from over 150 legacy reports.

Page 25: Spanning the Reporting Abyss

Disadvantages to Functional TablesDisadvantages to Functional Tables

1. A nightly refresh window MUST be considered and 1. A nightly refresh window MUST be considered and tactical decisions made.tactical decisions made.

2. Documentation may be more difficult to establish and 2. Documentation may be more difficult to establish and maintainmaintain

3. Knowledge of the base system is lost (blind faith on 3. Knowledge of the base system is lost (blind faith on programmer creating the table)programmer creating the table)

Page 26: Spanning the Reporting Abyss

Advantages of the Functional Table StrategyAdvantages of the Functional Table Strategy

1. Simplicity in data presentation and development.1. Simplicity in data presentation and development. 2. Reports run significantly faster.2. Reports run significantly faster. 3. Changes in data standards much more adaptable (One 3. Changes in data standards much more adaptable (One

place to make changes in data interpretation and NOT in place to make changes in data interpretation and NOT in every report.)every report.)

4. Provides a transitional bridge from legacy to new 4. Provides a transitional bridge from legacy to new systemsystem

5. Provides a greater potential to ‘empower the users’.5. Provides a greater potential to ‘empower the users’. 6. Reporting accuracy improved and many potential errors 6. Reporting accuracy improved and many potential errors

removed.removed. 7. Reporting consistency is greatly enhanced7. Reporting consistency is greatly enhanced

Page 27: Spanning the Reporting Abyss

PlusPlus

8. Shorter learning curve (no requirements on the part of 8. Shorter learning curve (no requirements on the part of the report writer to learn the core system data structure or the report writer to learn the core system data structure or methodology)methodology)

9. Allows for continuation of longitudinal studies9. Allows for continuation of longitudinal studies 10. Allows for the creation of hybrid tables and thereby 10. Allows for the creation of hybrid tables and thereby

creating a TRANSITIONAL BRIDGE to SPAN the creating a TRANSITIONAL BRIDGE to SPAN the REPORTING ABYSS.REPORTING ABYSS.

Page 28: Spanning the Reporting Abyss
Page 29: Spanning the Reporting Abyss

Questions?Questions?