PeopleSoft White Paper: Integration
Introductiwon

integrate, v. to put or bring (parts) together into a whole; to unify

Websters New Universal Unabridged Dictionary, 1983

The integrated HRMS/SA PeopleSoft product offers many advantages to colleges and universities seeking to enhance and upgrade key administrative functions. While either module may be implemented separately, they were designed to be an integrated system. This paper discusses the realities and implications of that integration at a high level. While references are made to technical documents which offer detailed information, this paper is not a complete technical guide to integration.

These issues are pertinent for schools who are planning to implement both HRMS and SA simultaneously, or who have already implemented HRMS and will now add the SA modules. In order to effectively plan for and implement the integrated system, administrators will want to have a thorough understanding of the technical, functional and organizational issues at hand.

The somewhat non-traditional pairing of HR and SA systems may, in some cases, cause concern as to why and how the two are integrated and what that means for each organization and the institution as a whole. This paper seeks to address those concerns and to educate the reader on basic technical and operational facts and features of integration. Among this most basic information are the facts that HR functionality has not been altered, the modules are upgraded together and "personal data" is shared. The shared database is the most basic tenet of integration.
Integration, as a broad strategy, (technical or otherwise) is usually employed to achieve efficiencies by leveraging like-processes and eliminating redundancies. It typically offers significant long-term benefits with some up-front work and investment. Additionally, integration may yield unanticipated efficiencies based on the new practices and relationships which result. For instance, in preparing for the implementation of an integrated system, institutions will often and necessarily undertake some redesign of their current processes.

For schools which have chosen this integration strategy (which is profound but not complex) and will implement the HRMS and SA products, they can expect to realize the following primary benefits:

Elimination of Multiple Interfaces

The population and maintenance of data for many existing HR and SA systems requires multiple interfaces. For instance, the student administration system may be running an interface to the HR system with information on student employees. Likewise, the HR system may provide an interface to the SA system with information on employees taking courses. Integrating the two eliminates the need to interface because the data are already unified. Clearly, implementation of one segment without the other would necessitate development of interfaces from current systems to the PeopleSoft product.

Elimination of Redundant Data Entry

For all members of a university community who have reason to be resident in both the HR and SA system, their data are usually entered multiple times. Redundant data entry is clearly inefficient and jeopardizes the accuracy and integrity of the data. Additionally, there is usually a great amount of effort spent trying to keep these databases "in sync" by reconciling records, and correcting errors; these activities can be time-consuming and costly.

Improved Customer Service

Among the customers of the integrated PeopleSoft HRMS and SA system are students, employees and academic/administrative departments of an institution. Users can provide enhanced service to these customers by virtue of the data which are more accurate and more readily available. It is not difficult to imagine the efficiencies in the process realized for a customer who no longer has to go to two or three offices, can update some data elements on their own and for whom business transactions are faster and more convenient. For example, a single "service deliverer" could process an employee who is taking a course and needs to register and process tuition exemption forms. These transactions, formerly handled by back-and-forth processing and data entry at HR, the registrar, the bursar and the employee's academic and administrative departments could be effectively handled at one point of service.

Enhanced Data Availability and Reporting Capabilities

Reporting capabilities are greatly enhanced by the sheer volume of data available from the integrated system and by the fact that all of the data are resident in one physical place. The integrity of the data is far greater due to the use of common data definitions. Divisional and departmental administrators from HR and SA as well as offices of Institutional Research will have, at their fingertips, an enormous amount of current data for reporting. In addition, many more data elements will be available for cross-referencing and more in-depth analyses. Institutional reporting and planning functions will be, as a result, more efficient and effective.

As previously mentioned, the implementation of this powerful, integrated system requires a complete understanding of the associated technical, functional and organizational issues. This paper addresses those issues by discussing the realities and implications of integration. The realities section presents the four primary shared business processes which result from the integrated system and defines certain data structures and terminology which are critical to understanding technical aspects. The implications section explores some of the organizational considerations for institutions preparing and planning for implementation.

Realities of Integration

Shared Business Processes

Four primary shared business processes result from an integrated HRMS/SA system. These processes can now be handled jointly by users of the system, rather than being solely the responsibility of one unit or the other. The shared business processes are:

Maintenance of Personal Data

Maintaining up-to-date basic, demographic information ("personal data") such as name, address, social security number, birthdate, gender, etc., on members of a university community is a core business process. The data are dynamic yet critical to record keeping and transaction processing. Problems frequently occur because the data are maintained in multiple databases by multiple identifiers and changes to the data are not always communicated. In the integrated HRMS/SA system, each campus community member has one core demographic record and one key identifier. Users of the system, therefore, always have the most up-to-date, accurate information and changes are posted directly to the "official" record. While both HR and SA users benefit greatly from this centralization of demographic data, they must also understand each of the data elements, agree upon data values and appreciate the impact of changes to the data.

Student Employment

As employment becomes a more predominant source of financial support for students, the volume of student employees and student employment transactions will increase at institutions. The integrated HRMS/SA system allows both HR and SA staff to "hire" and "pay" people based upon the user's security. These functions, once handled by parallel processes for faculty/staff employees and student employees, are now standardized and streamlined. Additional benefits are realized by the institution's ability to track a person's comprehensive work history and to broadly utilize recruitment features of the system such as job posting and candidate screening functions.

Student Payments/Refunds

The processing and payment of student refunds is also integrated with the HRMS/SA system. Payments to individuals are processed through the HRMS Payroll functions. The Student Financials module determines the amount and timing of a student refund, and generates payment transactions. This then is processed by Payroll which calculates taxes, cuts a check (or completes an electronic deposit) and generates all necessary taxation information and forms. (Payments to organizations are sent to the PeopleSoft Accounts Payable system for processing).

Faculty Workload Tracking

The ability to track and report on faculty workload is another significant shared business process. Faculty workload volumes can be accurately established by class schedules and roster records. This allows for easy monitoring and analysis of items such as student/faculty ratios, advising assignments, and grading history.

The streamlining of these four shared business processes offers significant opportunities for improved service delivery to all campus community members.

Data Structures

Another critical piece in understanding and appreciating the realities of integration is the comprehension of some of the basic data structures and technical terminology.

Single System

The most important underlying principle is that the HRMS/SA system is a single system, not two merged systems. The HR and SA functionality and features are fundamentally intertwined. Differentiating them denies the potential of system integration. SA was built upon the design principles and data tables of HRMS to produce a single product which serves a larger set of business processes. Certainly there are panels, functions and tables which are clearly segmented and utilized predominantly by HR or SA, but effectively, the system and all of its data and functionality are available to all users. Although SA was built on HRMS, HR users have begun to request use of functions developed for SA. The challenge for the institution is to methodically sort out security settings and data "ownership" assignments so that while the data are widely available and open, it is also secure and accurate.

Fully leveraging the integrated database requires that institutions view business processes institution-wide versus by department. The institution-wide view of processes is enabled by the technology. For example, student and employee data are contained in the Campus Community section of the HRMS/SA system. This data, as its name suggests, is common to all users and represents core data to which all users have needed access. The Campus Community data are not HR data or SA data, they are, simply, institutional data about people and organizations.

Tabless

A key concept which is essential to understanding the realities of an integrated system is the concept of a "table" and whether it is "shared" or 'referenced'. By "shared" we mean that both HR and SA store data in the table. There exist two categories of tables: 1) People tables and 2)Prompt table

Data in Shared Tables

While the "table" may be shared by both HR and SA, the application data (People data and prompt data) may be "shared" or it may "coexist". Shared data may be referenced and manipulated by numerous users in HR and SA. While data that "coexists", is referenced and manipulated only by its respective owner (HR or SA).

Data in Referenced Tables

The data in referenced tables is owned and manipulated by either HR or SA but is used by both. In general, the integrated system allows for all of the tables to be used as reference tables.

People Data Tables

Campus Community includes people data tables which are "shared" by different functional users. By "shared" we mean that the application data resides in the same table. However, the application data itself may be "shared" by different functional users or it may "coexist" on the same table but only be accessible to a specific functional area. Since Campus Community tracks the demographic information about all members of the institution, like students and employees, whenever a person belongs to several functional areas the data about that person is then "shared". An example of such a table is the personal data table where information such as name and address are stored by both HR and SA users. Because the data is shared, up-front conversation and coordination between the HR and SA implementation teams is required to ensure that all users understand the data and how it will be used. A "referenced" table on the other hand, is a table containing information owned and maintained by only HR or SA. For example, a table containing course unit and GPA data would belong to SA but HR may "reference" it for recruiting purposes or a table containing position data would belong to HR but used as "reference" by SA.

(Although over-simplified, you could draw a file cabinet analogy viewing the integrated system as a file cabinet with certain types of drawers. The Campus Community data are kept in one joint file drawer to which HR and SA staff both have access. The filing system and file maintenance for this drawer must be agreed upon and understood by both divisions. In addition, both HR and SA each have their own filing drawers for other files pertaining to their business processes. These files may be accessed with permission, but no changes to the filing system would be made by the other division.)

Prompt Tables

Prompt tables are pre-set tables of data values which feed fields that have predictable or specified values. For example visa type codes can be pre-loaded and whenever a visa type has to be entered, the data are always consistent and pre-determined. The values in prompt tables are often viewed in a "pull down" window or through F4 which reveals all of the valid values for that field. Responsibility for the assignment of those values is determined by whether or not the data for the prompt table is "shared", "referenced" or "coexists". An example of a "shared" table is the Bank table, where the banks may be defined on a campus wide basis for the Institution. Revisions to shared prompt tables values will have to be agreed upon and communicated on an ongoing basis.

In the case of referenced tables, continuous communication ensures that the values continue to be useful to all functional area. An example of an HR table that is "referenced" by SA is the department table. In general, the Institutional department table is maintained by HR and will only be referenced by SA.

The final example is where both HR and SA may have unique values, thus the values "coexist", in the same table. The Holiday table is an example where both HR and SA may have different Holiday schedules used to populate their panels.

Here is a chart to highlight some examples:

Tables

Shared*
Referenced#

PeopleData
Personal data
Job

Admission Application data

Prompt tables
Bank Table
Department Table

GPA Type Table

* "Shared" tables store data for both HR and SA.

# "Referenced" tables store data for one module that is used by the other.

Data in Shared Tables

Shared*
Coexists#

PeopleData
Personal data
Personal data

Prompt Tables
Bank Table
Holiday Table

* "Shared" data is used by both HR and SA.

# Data that "coexists" resides in the same table but is used independently by HR or SA.

While the distinctions between these definitions are sometimes fine, understanding the differences thoroughly will result in effective planning and implementation decisions. Several PeopleSoft reference materials exist which illustrate and explain these issues in greater detail. Administrators should familiarize themselves with:

--Visio Data Design charts identify the parent/child relationship of data tables.

--"Table Load Sequence Documents" is a technical document providing the direct relationship between application data and the required "prompt" tables.

-- Student Administration Shared Table highlights the tables used to begin HR/SA integration planning.

Security Features

The system's security features, which can be customized by each institution, are tools which will protect the data and segment it appropriately. Security profiles can be set by division, department or individual and can control screen and field level data so that it is changeable, "read only" or invisible. The System currently provides several examples of search criteria to assist the Institution in reviewing different security options. Three of the search views are :

1. PEOPLE_SRCH which provides access to the personal data of all members of the campus community.

2. PERS_SRCH_US is a standard search view for personal data around employees.

3. STUDENT_SCRTY is a search view for personal data about prospects, admits and students

Implications of Integration

Aside from the technicalities of implementing an integrated HRMS/SA system, there are significant organizational implications which should be given adequate consideration.

Organizing for implementation is critical. While the functionality of the system is not impacted by sharing, the basic principles of integration imply the need to structure implementation teams which are also integrated and coordinated. HR and SA working groups which are convened need to have appropriate membership as well as appointed liaisons and a coordination plan. Membership in each group should be comprised of key administrators, process owners, service deliverers and technical experts from each area. Although there are many ways to structure the coordination between the groups, multiple joint planning sessions to educate each other on processes, determine prompt table values and search criteria, discuss shared application data and determine security settings and profiles will be required. These data review sessions represent a significant investment in time, but are also representative of the process of integration itself. For instance, the fundamental decision regarding which "common ID" will be used must include both HR and SA representatives and must involve a thorough discussion and decision-making process.

As previously mentioned, the implementation of any new information system requires some review and redesign of process so that the system and the process can be as closely matched as possible. The degree to which an institution chooses to evaluate/redesign its HR and SA processes alongside the implementation will vary, but any process redesign should be documented and communicated to both HR and SA so that the integration is not just on the technical side. For example, both HR and SA need to understand the "hiring" process.

Coordination does not end at implementation. There will be an ongoing need for coordination long-term. Relationships and processes developed for implementation should be developed with an eye to the future. Responsibility for this coordination should be adequately articulated and delegated so that productive relationships are maintained.

The larger picture surrounding these issues of technical, procedural and organizational integration reflects the current commitment to new philosophies and attitudes regarding service delivery, "student as customer" and a general rethinking of traditional administrative relationships. The integrated HRMS/SA system represents a step towards the "one-stop-shopping" model that so many campuses are implementing in so many ways. It also incorporates the concept of viewing campus community members as having a life-time of relationships to an institution by allowing for concurrent statuses and seeing that life-cycle as on-going and progressive rather than as discrete phases. These philosophies indicate that decisions are being made more often at the university-wide level with an expanded frame of reference. It also means that departments and divisions are more dependent upon one another.

Conclusion

With an enterprise wide view of HR and SA processes, the new integrated PeopleSoft HRMS/SA system can fulfill its substantial potential. Leveraging the institution's software investment may require rethinking some traditional administrative structures and processes. From the outset, key stakeholders including HR and student functional process owners, key customers (students, faculty and staff) and IT staff must work collaboratively to ensure successful implementation. A proactive approach utilizing informed planning, educated implementers and cross functional working groups will enhance the benefits made technically possible by the integrated PeopleSoft HRMS/SA application.