Questions Pertinent to UI-Integrate's Effects on the UIUC Electronic Directory

This document is an edited version of an early in-house effort to outline the issues created by the coming changes to data sources for the Electronic Directory. For more information, email Mike Grady at m-grady@uiuc.edu.

 

Overview

CITES' principal concern is an uninterrupted transition to the new data sources concurrent with the decommissioning of the existing payroll system in December 2003.

We are giving attention to future needs of both CITES' downstream consumers and our own internal operations, and to the eventual replacement of our directory services infrastructure. However, the primary focus will be on the needs of our present operations as they are affected by the UI-Integrate transition. However, due to its early position in the UI-Integrate rollout schedule, the payroll/HR conversion will be the first component of UI-Integrate to directly affect the CITES directory services area.

Briefly, the processes that maintain the UIUC Electronic Directory use the following general categories of data from the University's administrative systems, which will be replaced by UI-Integrate.

• Demographic data such as name, gender, date of birth, addresses, and telephone numbers for both students and employees, though at present the two originate from distinct data sources.
• Structural data describes the University's organizational hierarchy as expressed by today's codebooks: campus/college/department, campus/college/curriculum, and so on.
• Employment data such as campus/college/department affiliation, and the type and status of employment for UIUC employees.
• Appointment data such as the campus/college/department, title, and rank/class code associated with an appointment for UIUC employees.
• Enrollment data such as the campus/college/curriculum of major field of study, registration status, and part/full time status for UIUC students.

The data serves two purposes. First is the directory's role as a white pages service or online directory to help locate UIUC people. This is the principal role of the demographic data, but also applies to employees' titles and the name of the employing department(s) and to students' major field of study.

The campus/college/department codebook and the campus/college/curriculum codebook both play an important role in deriving consistent English-language descriptions for the various units and curricula appearing in the authoritative data sources.

Second--and no less important--is the directory's role as an authorization system for many core campus services operated by CITES (and by other units). In this context, the directory is used to associate people with one or more campus units with which they are affiliated.

In the case of employees, the most obvious authorization function involves associating people with the units that employ them as well as with the college and campus above them in the organizational hierarchy. Other types of employment-related information, such as employee type and rank/class code, currently affect the set of services and resources available to an employee. Students' curriculum and the department and college under whose auspices the curriculum is offered play a role in student access to various services and resources.

Data Issues

Because of shortcomings with the existing data, several questions regarding data issues come to mind. With the Payroll/HR conversion to UI-Integrate closely approaching, I will dedicate this list of questions to employee-related issues, or issues that are pertinent to the Payroll/HR conversion.

Structural Data Issues

• How do we determine a person's affiliation within the University hierarchy? We currently affiliate based on home campus/college/department as well as on a per-appointment basis. The UI-Integrate system of organization codes is much more complex, and we need to be able to determine a person's position within the hierarchy as at present.
• The present campus/college/department and campus/college/curriculum codebooks have a hierarchical structure, which permits determination of a unit's affiliation with a particular campus and college, or a curriculum's affiliation with a particular unit within a campus and college. Access to a variety of centrally or departmentally funded services are restricted to employees who have an employment relationship not only to a particular unit but to the college to which that unit is subordinate. We thus need to continue to be able to determine an employee's relationship to campuses and colleges within the UI organizational structure. Similarly, once the student conversion is complete, we will need to be able to determine students' affiliations with a particular field of study so as to control their access to services whose target community is restricted to students enrolled within a college or curriculum.

Demographic Data Issues

• How is employee home address/phone suppression handled? Which address/phone types should be handled specially when the confidential indicator is set?
• How do we identify which types of addresses and phone numbers are conditional on employment and determine when these addresses are usable?

Employment and Appointment Data Issues

• We need to identify the basic concept of target community--namely, a subset of all UI employees who have some affiliation with the Urbana campus.
• We need to be able to identify which "organization" within the UI hierarchy is the "controlling organization" for a given employee, that is, the Banner equivalent of today's home campus/college/department code from the paymaster.
• We need to be able to identify each organizational affiliation for a given employee based on the Banner "job" and "position" structure. This is equivalent to the per-appointment data in today's paymaster.
• How do we deal with employees on part-year appointments (such as academic employees on nine-month plan) during periods in which they aren't working?
• Around the beginning of the academic year, data in the present payroll system is unreliable--the appointments of all academic employees are shown to have terminated on August 20. Until some weeks later when the system stabilizes, we don't have usable data to identify the status of employees. Are there means with which we can distinguish continuing employees whose contract renewals are pending from employees who are not being processed? Have the departmental procedures changed to eliminate the limbo period, or will there still be a period in which employee data needs to be taken with a very large grain of salt?
• How will we be able to tell whether employees become inactive due to retirement vs. other types of separation from UI? At Urbana, certain services are extended to retirees after separation from the University, but not to other employees. We need to be able to validate an individual claiming to be a past retiree. This would assume being able to query historical employee records; is this possible?
• Will rehired retirees be identified in ways similar to how they are identified at present?
• How are incoming employees handled? At what point in the hiring process will various data elements be available for incoming employees? (Note: This affects CITES' NESSIE new hire application.)
• How do we identify employees on disability leave? How about other types of leave?

--Jon Roma