Introduction
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.
Tables
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.