University Student-Centered Commitment

A critical part to the official University affirmation states, "Pepperdine, as a Christian University, affirms that... the student, as a person of infinite dignity, is the heart of the education enterprise... the quality of student life is a valid concern of the University."

In the recent years, concerted efforts have been made to re-design the processes to make them more student-centered. The OneStop initiative was begun to create a centralized means of triggering effective workflow processes, allowing for a more integrative delivery of student services. In addition, the definition of "users" has been redefined to include the students as a critical user group, who need access to the information systems 24x7 rather than only during "normal business hours."

Information Technology (IT)'s Mission Statement

The mission of the Information Technology Division is to provide the best possible leadership and support to academic and administrative units of Pepperdine University to ensure the advancement of technology through coordinated efforts with the Pepperdine University community.

For the purposes of this technology review, I will focus my attention on administrative systems and technology services that directly impact the delivery of student services at Seaver College, the liberal arts college of Pepperdine University. Information for this review came from interviews with the Chief Operations Officer of Information Technology, Student Adminstrative Staff, and selected Seaver College students. In addition, my work with the Steering Committee for our University's Enterprise Resource Planning project has also given me some critical insights into the technology situtation at our institution today.

The philosophy of student services is based on the student-centered mission of the university. Therefore, the review will focus on how our current technology is supporting such philosophy. The main areas I have chosen for this review include:

• Administrative Systems to support student services
  • Enterprise Resource Planning (ERP) Suite
    • Student Information System (SIS) - Special attention will be given to this module, since this is the backbone system which supports our current processes of student services.
    • Human Resource System (HRS) and Financial Resource System (FRS) will be reviewed to the extent that they interface with SIS in the student services processes.
  • Peripheral systems:
    • Housing Information System (HIS)
    • Convocation Database
• Self-service Technologies
• "Web For Students" - software which integrates data from the ERP suite, "translates" mainframe data to be able to be used via the web.
• Portal - providing for student access to self-service web services (i.e. registration, payments, view grades, student accounts, financial aid, etc...)
• Intranet - connecting students to adminstrative offices via the Internet.
• Touchnet - web payment system
• Britevoice - Voice response system (VRS) for both payment and online registration

• Communication Technologies
• Webmail Exchange for students
• Unified messaging system
• Directed messaging via portal

Administrative Systems to support student services

Background & History

The current ERP suite was first purchased in 1986 and has been upgraded with various releases from our vendor. At the time of the purchase, the end users of the ERP were considered to be administrative university staff, housed in specialized areas with specific functions. Each area functioned within its own silo, often reporting to different vice presidents overseeing distinctly different areas of the university. For example: Student Accounts reported to the VP for Finance; Registrar reported to the VP for Academic Affairs; Financial Aid reported to the Vice President for Enrollment Management; Admission reported to the Dean of the college. Each functional area maintained its own set of data within its own operational as well as informational structure; its tasks were clearly defined and closely guarded. The business processes were designed to ensure a high level of accountability and efficient tracking of such accountability. The division of labor and the separateness of information storage and maintenance assured that such efficiency of process tracking could be achieved.

Within such an environment, the ERP was built and developed with distinct and unconnected informational databases. As the need for information within each area surfaced, new and more layers of databases and information files would be created and maintained. The redundancy of information input and storage is a built-in feature of this system. Since the databases are not connected, sharing information is often a difficult and tedious process. Information does not "flow freely" nor transfer from one database to another. As the need for shared information increased, "bridges" were built for information to travel from one functional area to another. These "bridges" were built via complicated COBOL computer programs that were written to aid in the customizations of the various modules of the ERP suite. These customizations need to be maintained and adjusted with each new upgrade released by our software vendors.

The users of the adminstrative systems were trained specifically to access the system for specific purposes. Most of the administrative staff learned a specific series of non-intuitive steps to perform specific functions. Most often, the understanding of the whole systems and information flow was limited to the immediate task. As functions and adminstrative needs evolved, more layers and parts were added to the original ERP suite. The "vehicle" which we currently use to deliver critical information needed to provide effective service to our students resembles a Gypsy Wagon from which many seemingly disconnected but all vitally important parts hang.

The current system was originally designed with the administrative functions and staff at its core. It is built to support a system which is process-centered. The processes were traditionally designed to support the disparate nature of the functional areas. The evolutionary development of functional areas occurred within the context of themselves rather than the integrated evolution of the whole enterprise. The inflexible nature of the non-relational information databases structure became much more cumbersome to manage as the University changed its adminstrations and adjusted its organizational structure. As functional areas were moved outside of its originally-based silos, ad hoc programs were written and developed to allow them access to information that was now inaccessible to them. The lack of information sharing built into the system also required that the students who needed administrative support were often forced to engage in a complex web of activities involving travelling to multiple offices, re-authenticating themselves and re-telling their stories. Area-specific information was often incomplete, requiring multiple steps of confirmation and reconfirmation between and among offices before an adminstrative transaction would be complete. For example: A student who needed to order a transcript would have had to begin the process at the Registrar's Office, go to the Student Accounts Office to receive financial clearance on the system and on paper, pay at the Cashier's Office (and return to the Student Accounts Office if the payment was to clear the account), and bring the receipt back to the Registrar's Office before a transcript could be produced.

Critical Affordances

• Stable system
• Current staff very familiar with systems
• Current IT staff has developed extensive interface programs, allowing for more sharing of information among functional areas.
• Software vendors have provided timely upgrades to meet governmental reporting demands as well as regulatory changes to critical areas such as Financial Aid and tax reporting laws.
• Additional softwares have been purchased to use current legacy systems to provide web access to students
• Information segregated by functional areas, providing for more security.

Critical Limitations

• Lack of integration of information creates for disconnected functionalities among departments
• Redundant data storage increases the chances for inconsistent and incorrect data
• Programmers are required to be hired in adminstrative areas to develop programs to produce what should be simple/straightforward reports. Currently these reports can take days or weeks to produce.
• Extensive dependent on IT staff to generate reports, create linkage programs among various databases, and debug programs, creating huge backlogs.
• Lack of what-if capabilities within system makes academic planning for students extremely difficult. In addition, planning for class offerings and curriculum development is done through ad hoc reports and heavily reliant on manual processes.
• Housing Information System (HIS) does not automatically integrate with SIS. Updates from one system is not automatically fed to the other. The cross-systems update process is cumbersome and ALWAYS requires manual intervention by one specific staff person. If this staff person is unavailable, the systems are out of synch. This is a MAJOR risk area.
• Convocation system is designed and maintained by Student Life area and is difficult to integrate with SIS.
• Reliant on batch processing to complete adminstrative transactions involving multiple information modules. Batch processing requires the "freezing" of information systems; thus not allowing for continual availability of information system to users. Such processing also requires multiple layers of information verification and confirmation. Programs are written to check other programs that are written to check the results of other programs, etc... This is an extremely inefficient process. For example: a student payment may post to the student account in the morning one day, but it is not booked to the University accounting databases until the next day. The reconciliation among accounts then is done manually through the accountant's review of reports.
• Very few people within the University understands the structure of data storage and information transference process. Information appearing on one SIS screen comes from disparate databases. Changes to the information screen structure requires extensive COBOL coding which can take up to several months of dedicated IT staff time to accomplish.
• Lack of holistic view of student financial information. System requires multiple series of "screen hopping" to gather data and then an adding machine to calculate numbers that should be able to be calculated through the information systems.
• Bio-demographic information are stored in disparate information modules (i.e. student information must be separately maintained in SIS as well as in HRS if a student is also employed within the university whether as a staff person or as a student worker.)
• "Correcting a mistake" within a systems requires extensive coding and adjustments of multiple databases.
• Such lack of integration and data redundancy often results in poor customer service (i.e. providing conflicting information)
• System unable to accurately track pre-requisite and co-requisite components to curricula.
• Non-intuitive systems requires extensive training and memorization of disconnected steps in order to complete a simple adminstrative task. This increases training costs and create an environment in which flexibility is a rare commodity.

Self-service Technologies

Background and History

In the late 80's, when the current administrative information system was installed, the complex nature of technologies available made it necessary for staff intervention in the process of providing for administrative services to students. The simple act of making an address change required the students to engage the assistance of a member of the staff to complete this task. Since the system did not have the ability for self-check or information confirmation, data had to be entered in a specific manner, according to specific processes. A student could not be expected to learn and remember all those requisite steps. Therefore, they were not "trusted" to be able to self-serve when it came to administrative matters.

The development of the internet changed the view of technology. Students came to us having experienced the convenience of self-service through the affordances made available by the technological change. Our extensive investment in the legacy system and its inflexibility provided for a conflict of interest between what we could provide and what the students wanted us to provide. Our software vendor came up with a short-term solution by designing several self-service screens from SIS that would be available to the students via "kiosk" computers located in the lobbies of the administrative offices. At the kiosks, the students were able to view their student account history, view their grades, check the availability of classes, check their addresses as recorded in SIS,and check whether or not their financial aid had been posted. The "self-service" functionality amounted to no more than checking historical data.

In 1998, our software vendor released their "Web For..." products, which allowed us to push the student information out to the students via the internet, allowing them to do more than just view historical data; rather, it allowed the students real-time access to current data and register online. It also provided a more user-friendly view of grades and other student information rather than the old "green screens" that are trademarks of our legacy information system. A casualty of this new product, however, was the student account information. This new product only allowed the student to see the account balance rather than the view of the whole account history as they previously had. At the same time, we contracted with another vendor to allow for a voice response system, allowing for registration via telephone. Two years later, we added the online as well as automated telephone payment systems for the student accounts.

At around the same time, we partnered with a new company who developed a prototype of a portal which wrapped around our administrative systems, making the self-service components much more user-friendly and comprehensive than what the "Web For..." products could provide. We became a beta site for the the testing of this prototype. The portal became know as PepperdineXpress. This portal provided the "skin" which covered the Web For... functionalities as well as bringing together all of the disparate peripheral systems needed to serve the students' needs.

Critical Affordances

• Students are able to register online.
• Registration adjustments (add/drop) are also able to be conducted without staff interventions.
• Controls are put in place to meet advising requirements
• Class availability is update live.
• Payments are made directly to the student accounts.
• Grades are submitted by the professors and posted to the students' records within seconds.
• Students take more control their own adminstrative processes.
• Academic progress is maintained online. Students can have view to their records without having to go to the administration center.

Critical Limitations

• Portal is still quite non-intuitive. Students are still required to go through at least five layers of screens before reaching the administrative services screens where they can perform their adminstrative tasks.
• Portal is set up to follow the university reporting structure rather than the students' usage needs.
• System requires multiple levels of authentications, involving Student ID Number, PIN, Password... Each level requires a different combination.
• Changes in PIN's and passwords cannot be processed live. In fact, changes in such critical information will preclude student access to the system for up to 72 hours.
• Disparate peripheral systems require even more complicated authentication verification from the students.
• Staff does not have access to the student screen; therefore, without having gone through IT first, it is almost impossible for administrative staff to answer questions that students might have about a self-service process.
• Lack of student account information via the web creates a real frustration for the students.
• Unable to post student bill to the web. Still reliant on regular mail to send bills to students.
• Still unable to check on critical financial aid information via the web.
• Lack of live data processing within the ERP suite prevents the web components to be available 24 x 7. This is a critical area of exposure for our entire information systems. The need for continual access to information by students, staff and faculty has shrunken the window for systems upgrades, batch processing, and maintenance.
• The portal and Web For products are basically "band-aids" and temporary fixes to a system not designed to be used by large number of untrained users, such as students.
• Changes to processing requires extensive time commitments by IT staff.
• Departmental web pages are not consistently maintained; thus, providing for inconsistent and sometimes incorrect information.
• Lack of e-commerice license does not allow for payment via e-checks of credit card payments for departments outside of student accounts.

Communication Technologies

Background and History

The history of email at Pepperdine is indeed a colorful past. It was only in the last 5 years that we have all migrated to one integrated email system, Exchange. The one system has provided for a much better communication flow among the staff members. Each student is also given a Pepperdine email address and is expected to maintain its content on a regular basis. The global address list and the contacts function within Exchange are effective elements of the email system. From the students' side, however, the global address list is not available. The sign in to web mail is also not as streamlined as it is from the staff side.

The most major struggle with the institutional email is that at least 60% of the undergraduate students do not regularly check or maintain this email account. Although they have been told that all official university correspondence will be sent to their Pepperdine address, a large majority of our students still use their own personal email accounts. The only time that the students will consistently use their Pepperdine email accounts is when they need to send an administrative request or directive to a university office which requires their "e-signature." Their Pepperdine email address currently serves as that "e-signature."

The portal has the capability to allow for directed communication to specific groups of students, based on their attributes as recorded in SIS. In addition, the portal is an effective place to post general announcements for the whole student population. Currently, such communiques must be submitted to one of two people who maintain the portals. The goal is to eventually give access to message updates to directors of functional areas who can post their own messages.

Within this last year, we have migrated to a unified messaging system which connects our voice mail with our email. This has allowed for students to access their voice messages via their web mail accounts. In doing so, it is hoped that on-campus students will yet have another reason to use their Pepperdine email account.

Critical Affordances

• E-mail has become a ubiquitous form of communication. It is efficient and timely.
• Portal communications allow for tailored messages to reach specifically intended audiences quickly and consistently.
• E-mail has allowed for students to reach administrative offices and personnel more effectively, thus reducing the need to stand in line. The Pepperdine email accounts, which are proprietary and secured to specific students, allow for identity verification needed for many adminstrative functions.
• Unified messaging is making communication with students more convenient, for students who choose to use this feature.
• Email and web access have assisted in the connection of students located throughout the world.

Critical Limitations

• Current system unable to "woo" students to fully use our communication channels.
• University philosophy still based on "requiring" students to use Pepperdine email without fully understanding the reason why students are resistant to its compliance. (For example: Most staff people assume that students' access to the email system is the same as the staff's access. Very few staff members use web mail, but they expect the students to use what they are less than willing to use themselves.)
• Lack of students' use of system significantly reduces the effectiveness of the email system.
• Unified messaging is only effective for those who use it.
• Our current technology does not allow for us to use the students' personal email accounts automatically.
• Portal communication is extremely limited since it requires intervention by university technical staff. Administrative offices reluctant to involve other people in the communication process.

Overall, the technologies available to us today requires much human interventions. The university is heavily dependend on IT personnel to provide support and programming expertise to accomplish the simplest of tasks. The system does not support automated workflow needed to streamline the delivery of student services. The change in student services delivery process is an attempt to build workflows using our disparate systems. Traditional models of service delivery required the students to engage in a complex web of activities designed to support the information systems. The student-centered model of service delivery requires that we streamline the processes to deliver the service to the students rather than making the students go to the services. New technologies are currently available in the marketplace that would better support our student-centered mission. They are, however, extremely expensive and will require significant changes in business processes. The University is currently undergoing an extensive search and evaluation process for such technology and determining the implementation process. Slowly but surely, we are heading in the right direction.