March 16, 1999

Under the legacy Student Master File, unit leaders who wanted collective information about students were dependent on a few resources to get the information. There were two reasons for this tight centralization: having fe w people writing reports helped establish data integrity (a role Carol Griesbach served for many years), and the legacy computer system could only be queried by EZTrieve, a program few on campus could master.

With the movement to the PeopleSoft Student Information System we have an opportunity to reconsider report generation on campus. A working group headed by Greg Wypiszynski did an initial assessment of the campus report structure. That assessment has been followed by the work of a second report group (Debra Matulle, Leon Harder, Greg Wypiszynski and Bill Wresch) which looked in more detail at reporting issues. This plan is the work of that second group.

For the purposes of this plan, student information will be categorized at two levels: individual and collective. Individual student information is distributed through the legacy system with both students and advisors able to access certain academic record information. The PeopleSoft Student Information System will continue this practice with students and advisors able to use a secured on-line screens or web-based interfaces to look up individual records.

Collective information is gathered and distributed through reports. Reports take two forms: scheduled reports, or ad hoc requests. Examples of scheduled reports would be lists of all students who have been assigned a room in the residenc e hall (automatically printed daily or weekly), or all the students who have deposited $100 as part of the admission process (printed weekly). IT wrote programs that produced scheduled reports for units (getting approval to be included in these scheduled reports was known as the "90 day cycle").

Ad hoc requests are usually one-time looks at information, such as the retention rates of students in a particular major, or the enrollments in a particular class over time. To get ad hoc requests, units turned to two experts -- Leon Harder or Carol G riesbach. Both scheduled reports and ad hoc requests are being reviewed during our move to the new student information system.

One of the hopes arising from the installation of a new student information system is that new models for the flow of collective student information could be established. These models would make collective information mor e generally available across campus. For example, the Data Book for Planning might be posted to web sites, or scheduled more frequently so that information is more current. Ideally campus information would also be available in such a way that decision m akers could create their own requests. Such access might let program heads, for example, ask such questions as, "How well do our majors do when they take courses in other majors?" or "What kind of students sign up for our summer offerings? "

While the ability to access and interact with collective student data will be available under the new system, it is constrained by several factors.

1. PeopleSoft SIS produces few reports of collective student information. The program is sold nation-wide to many campuses, each with its own reporting requirements, so, unable to satisfy all users, it has chosen to respond with a very small number of b uilt-in reports.
2. Generating large reports while the system is being used for business processing, (e.g. asking for a printout of students by major while students are using the system to register for courses) tends to overload the system and make service very slow.
3. The tools built into the system for ad hoc reporting are difficult to use, and if misused will severely degrade the system.
4. The programming language needed to generate scheduled reports is very powerful and sophisticated and designed for use by professional IT programmers.

As a consequence of these constraints, the campus will need to develop a reporting mechanism in two ways. The first approach will be to have professional programmers write the code necessary to create the campus’s schedul ed reports. The reports will be generated at a time of the day and week when they can be created without reducing the speed of service to students and faculty using the SIS system. Ordinary users will not have access to the production reporting tools an d will be dependent upon IT staff. In short, the methodology for producing scheduled reports will look and feel very much as it has in the past.

The second approach will be to create a second set of data on another server. Initially this second dataset will be created by IT programmers developing reports based on their best understanding of user needs. The determination of which reports to wr ite and which datasets to send to the second server will need to be made on a priority basis much like our current 90 day cycle. Once data has been moved to the second server, program heads will be able to extract data in a report-format according to the ir reporting needs.

This second, generally-accessible server will gradually mature to become a campus "data warehouse." The most common function of data warehouses is to collect historical data so that users can look for trends or for interesting interactions b etween data elements. In our case, we will be creating a warehouse to serve several functions.

1. By pulling "snap shots" of data into a warehouse, we will have data on a different machine from the main production database. By isolating data onto a second machine, heavy use of the warehouse will have no deleterious impact on the product ion server.
2. Tools to do analyses of data warehouses are simple enough so that many users will be able to create their own ad hoc reports. And again, since the data is isolated from the production data, if they make a mistake, they won’t disrupt class registratio ns or other daily tasks.
3. When the warehouse is fully "populated" with data from multiple years, program heads will be able to make significant chronological comparisons and ask more sophisticated questions than is currently the case.

Each approach to reporting will have its own timeline for implementation. Detailed timelines for each approach are provided in Appendix A.

February 1- November 1 – Replacement of Scheduled Reports. During this period, main functional units (admissions, housing, financial aids, cashier, registration) will determine what information is provided automatically by PeopleSoft SIS and wh at new reports will have to be programmed. IT staff will determine how best to create those new reports. Reports will be created on a priority basis. This effort will be headed by Ken Splittgerber in the IT office.

April 1 to December 1 – Creation of the second "data" server. Based on the report analysis done during February and March, IT staff will determine which datasets can most usefully be moved to the data server and will write queries to do so. Requests for additional queries will be handled on a priority basis. This effort will be headed by John Berens in the IT office.

July 1 to December 1- Creation of a Data Warehouse. During this time a proper data structure for warehouse information will need to be determined, a transfer and analysis tool purchased, and a schedule of information transfer determined. Then the warehouse will have to be implemented and tested. Bill Wurzbach and Bill Wresch will oversee this activity.

December 1, 1999 to December 1, 2000 – Use of the Data Warehouse. Initial use of the data warehouse will be by selected representatives of Institutional Research, Registration, Financial Services, and Admissions. After these representatives ha ve developed expertise in the use of the warehouse, use will be extended to the college level and ultimately to the department level. The data warehouse manager will oversee this activity in cooperation with Bill Wurzbach.

Production of scheduled reports has always been the function of IT and will continue to be the case during and after this conversion. During the six month period (April to September) when most of the rewriting of programs will be occurring, it is certain that additional consultants will need to be brought in to help with the programming work. The number of consultants needed will be determined as the main functional units determine and prioritize their reporting requirem ents. An individual in IT will need to be identified to oversee this work.

The data server and data warehouse will need to be staffed by a full-time manager. This person will write reports to move data sets to the data server, schedule and accomplish the importing of data from the SIS production system to the warehouse, will maintain meta-data information and data integrity in the warehouse, and will train users in information access strategies.

The campus community will notice little difference in how scheduled reports are produced. Scheduled reports will still be written by professional programmers and will be scheduled to run at times that will not adversely a ffect the University’s business processing. Beginning in December 1999, academic program leaders will gradually be given more access to ad hoc reporting and will eventually have a new vehicle – the data warehouse.