This article was published in CAUSE/EFFECT journal, Volume 22 Number 3 1999. The copyright is shared by EDUCAUSE and the author. See for additional copyright information.

Simultaneous Process Reengineering and System Replacement at Rice University
by Thomas J. Hochstettler, Barry P. McFarland, Andrea Martin, and Joseph A. Watters Jr.

In late 1996 Rice University launched a plan to replace its aging student information system with a more up-to-date and flexible model. Simultaneously, Rice undertook an ambitious project to restructure its business processes for undergraduate admission, financial aid, student registration, student accounts, and overall record management. How it achieved both objectives at the same time--developing a streamlined, client-responsive set of student services while replacing an antiquated information system with a state-of-the-art model--provides an edifying case study in how sweeping changes, when properly managed and carefully staged, can lead to extremely positive, cost-effective results.

In 1996 the most compelling reason for Rice to undertake replacement of its student information system was the approaching millennium crisis. Rice�s old student system had been purchased in the 1980s from Administrative Information Management Systems, AIMS, and ran on a still reliable but dangerously out-of-date Prime computer. AIMS was no longer in the student information business, and replacement parts for the Prime were becoming increasingly scarce. A survey of the landscape of available new student information systems revealed that there were a substantial number of excellent products then available and that any one of them would provide functionality far superior to that delivered by our old system.

The decision, then, to purchase a new system that would be, among other things, millennium-compliant was by itself easy to make. The decision to redesign business practices in tandem with the replacement of the existing information system was not so clear-cut. Indeed, on the face of it there was in the summer of 1996 no compelling reason for us to undertake major adjustments in our business practices. The usual emergencies that drive universities to contemplate dramatic changes in student services--financial exigency, loss of market share, a rising chorus of student and faculty complaints--were singularly absent at Rice. The university was in splendid financial shape. Our endowment had passed $2.5 billion and was rising, tuition was lower than that of any of our peers, faculty salaries were highly competitive, the university was debt free, and we had absolutely no deferred maintenance. Our students were not complaining about the level of service they were receiving, and the faculty were by and large comfortable with things the way they were.

In the end, the incentive for change came from the top. As successful as Rice seemed to be, our senior management in 1996, and especially Rice�s provost, perceived that we were missing opportunities for improvement in several important areas. Although the overall quality of Rice students was on the upswing, so too were the number of applicants for admission, both undergraduate and graduate. The sheer increase in information flow and paperwork associated with an expanding pool of applicants had placed unprecedented strains on our business processes. Turnaround time for responding to requests for information from prospective students was growing longer year by year, and anything resembling an executive information system was utterly lacking under the old system. In September of 1996 the provost convened a process redesign steering committee, consisting of himself as chair plus the three senior vice presidents, to oversee the replacement of the old AIMS system and to launch process reengineering within the office of admission, the registrar�s office, the office of financial aid, and the cashier�s office. An Enrollment Management Task Force made up of the principal managers in each major student service office was convened under the associate provost. Also in the group were the information technology director and the student information project manager, who would be responsible for the installation and maintenance of the new student information system.

Beyond this team of managers, a whole range of other experts and ancillary users would in the course of time become involved in the project. Figure 1 shows the general lines of responsibility as the project moved forward.

Figure 1: Lines of responsibility for the Enrollment Management Task Force

Figure 1

Defining the Problem

The Enrollment Management Task Force decided on a simple process to analyze workflow in the area of student services. Each of the offices involved in processing student information was charged with describing two scenarios with regard to how they conducted their business: �what is� and �what should be.� Using work-flow diagrams and process maps, each office set to work describing how work was currently getting done, from the first intake of information, through the processing of that information, across the full range of possible transactions, to the final disposition of the last bit of data. Having described the existing processes, each functional area was then asked to engage in a visioning process of �what should be.� The �what should be� scenarios would be critical not only in giving shape to the reengineering process but also in guiding the selection process for the new student information system.

�What is� scenarios

The �what is� scenarios were enlightening. It turned out that there was much duplication of effort among the departments engaged in this exercise. Certain types of data were being entered two or three times each semester for each student, whereas a single repository would have been easy to implement, even using the old student information system. Students were being asked to fill out their addresses and basic demographic data so frequently during the course of registration each term that a pair of clever undergraduates appeared one day in the registrar�s office with large rubber stamps containing their critical personal information. Point made!

At the same time, many processes continued to generate work and outputs that no one truly needed any longer. Manual tabulations were being done that could have been more readily accomplished on the computer, and paper copies of information easily obtainable from the terminal screen were clogging filing rooms and taking up valuable space.

�What should be� scenarios

The task force imposed two constraints on those putting together the �what should be� scenarios. First, each office was enjoined to examine workflow patterns first and foremost from the perspective of the student, our primary client. Our goal from the outset was to build new processes that would be fundamentally oriented toward service to students rather than toward the administrative service providers. The second constraint in the visionary exercise was that the new processes be Web-based. We believed from the start that students--as well as faculty and staff--would benefit from being able to access records and to transact business over the network.

Contriving �what should be� scenarios was hard but rewarding work. For many staff members, it was sometimes difficult to switch their perspective and examine their jobs as students and other constituencies saw them. Nevertheless, the process quickly bore fruit. We soon discovered, for example, a serious shortcoming in our admission process. Although virtually every call that came into the admission office contained some inquiry about financial aid at Rice, we had no immediate means within that office for responding with any degree of sophistication to questions dealing with issues of student aid. Clearly, prospective students and their parents were losing valuable time because of our lack of responsiveness on this basic issue. Everyone would benefit if we could provide more detailed information concerning financial aid right from the initial call or letter requesting information. Such discoveries helped to focus us on better ways of doing business as we began designing process solutions.

The key is simplification

From these conceptual exercises--�what is� and �what should be�--the task force arrived at a major decision--that simplification should be the central component of process reengineering. Simplification meant that processes should be redesigned so that they were simpler for students and other �customers� to use. In the most fundamental sense, simplification meant providing a single point of contact for students with the administrative systems. �One-stop shopping� was already a byword for process simplification, and we had seen versions of this concept at work at other institutions, notably at Carnegie Mellon and MIT. Our decision at Rice was to proceed even further on this continuum. For us, the ultimate goal would be �no-stop shopping,� whereby virtually all routine requests for information and simple transactions would be accomplished on the Web. Face-to-face contact between students and administrators would take place only when the Web-based system could not solve the particular problem and when a human intervention was needed.

Addressing Cultural Issues

As we moved into the design phase for reforming the enrollment management process, we needed to be careful not to compromise the distinctive culture that defines Rice. Our goal was to enhance that culture, not to change it fundamentally. The key component of the Rice culture has always been one of personalized service. Students at Rice matter. They are our reason for being. Thus, we wanted to ensure that any changes that we undertook would have as their ultimate outcome improved service to students.

Of course, the term �students� defines an ever-changing commodity. In the first instance, it refers to the great mass of undifferentiated prospective matriculants who, by and large, have little or no firsthand experience of Rice. Our first contact with the prospective student must be a positive one since this is our opportunity to begin to develop a client relationship with that student that could eventually grow into a lifelong commitment. To optimize that all-important initial contact, it is important for Rice to present itself as a welcoming and hospitable environment. The culture at Rice is student-friendly to a degree not found at most research universities, nor indeed at many liberal arts colleges. While the admission office has always been very careful to emphasize this �warm� aspect of Rice culture, other offices have in the past tended to be more businesslike in their dealings with prospective students, an approach that has contrasted sharply with the picture of an open and inviting environment that our admission officers try to convey. A major concern of the task force, therefore, was to develop business processes in all service areas that would be consistent with the Rice culture as welcoming to prospective students and responsive to their needs.

The term �students� also refers to our currently enrolled students. These students have needs that are substantially different from the prospective student. At the heart of the Rice culture for undergraduates is a residential college system, where students have immediate, day-to-day access to faculty members, who themselves are associate members of the colleges. Many problems facing current students--personal problems as well as those involving their schoolwork--are resolved in informal relationships through their residential college system. On the other hand, Rice students exercise substantial control over the conduct of their personal and academic life. The Rice honor code, for instance, is administered and adjudicated entirely by students. Students are encouraged to create their own majors, mixing and matching courses from different disciplines to create a program that is consistent with their individual life goals. With this level of independence as the standard in the culture, students have come to expect the organs of administration at Rice to be very responsive to and respectful of their needs. A second concern of the task force, then, was to evolve new student service processes that would enhance rather than harm the distinctive �student-empowering� culture that we have at Rice.

Designing Process Solutions

Three major changes emerged from our study of processes.

First, we decided to redesign our recruitment processes in terms that prospective students could understand rather than in terms of administrative units. Students interested in coming to Rice as undergraduates do not care that we have an office of admission, a financial aid office, and a cashier. They want information about a wide range of issues--a catalog, a view book, a financial aid form, a statement of charges. When they call Rice, those are the things they ask about. Thus, a first change that we undertook was to consolidate into a single location those functions that meet the needs of prospective students. Most significantly, we created the position of associate director of admission and financial aid, an admission officer who would also be expert in aid issues and who would be charged with packaging freshman financial aid.

The second major change to emerge from our process assessment was the fusion of the registrar�s operation with the office of financial aid into an Enrollment Center. We discovered that the sharp distinction that we as administrators drew between the functions of the registrar and the director of financial aid were to students at best opaque; at worst, irrelevant. If a student has trouble registering, it is of utterly no concern to her that the problem is one of incomplete paperwork in the financial aid office as opposed to an unsigned advisor�s form in the registrar�s office. What matters is that she cannot register. One solution to this problem was to meld the registrar and financial aid operations together, empowering the staff in each of the former units to transact business across the spectrum of student problems. In a further step, we made it possible for students to pay their bills straightaway at the registrar�s office rather than having to traipse over to the cashier�s office and stand in line to do so.

The third major change that was undertaken was the consolidation of a broad range of support tasks from admissions, student records, and financial aid into a central operations center. Within all of the traditional offices dealing with student enrollment are many tasks that can best be described as backroom operations, such as file compilation, telecommunications, data input, and processing tasks. When we reviewed the �what is� situations, we identified a large array of tasks common across the offices. There also appeared to be a seasonal complementarity among the staffs in terms of their workload. By consolidating these staffs into an administrative nerve center, we found that we could provide better service to the current and prospective students and at the same time improve the overall job satisfaction among the staff.

Up until this point, we had been moving toward the one-stop shopping model that exists at other institutions. The next phase of the reengineering process was to develop a no-stop shopping environment. In this new environment, all routine inquiries for both current and prospective students could be handled seamlessly through an electronic environment. The medium of choice would be the Web, but it would also include telecommunication, e-mail, and other modes of communication. After the processes were implemented, the staff would deal only with the exceptional problems. All routine clerical tasks would be performed over the Web. The staff would be free to focus on those interactions with students where there is real value added by a one-on-one consultation. In one critically important example, academic advisors would be liberated from the clerical tasks of signing registration slips so that they could provide meaningful advising to students about their personal and academic futures.

Choosing the software system

To make the best use of this brave new arrangement of processes for student information services, we needed to acquire a very special information system, one that would work well within a student-centered service environment. With some knowledge of the systems currently on the market, we set about finding the one best suited to our needs.

Our approach to the vendor selection process was two-tiered. The first tier was to get from each potential vendor as much information as we could so as to winnow down the field of candidates to only a few. The tool for eliciting this information was a Request for Information or RFI. Once the RFI had yielded a relatively small number of vendor candidates, we would move on to the second tier and issue a regular Request for Proposal or RFP, which would lead us ultimately to the best vendor for the project.

The Request for Information

The RFI served the purpose of identifying those vendors who had the full range of functionality that we needed to implement our proposed process changes. In writing the RFI, we made several strategic choices:

The Request for Proposal

After reviewing responses to the RFI, we selected a limited number of vendors to enter the next round of discussions. Only these vendors received an RFP from us. The RFP that the task force wrote asked for the normal technical information that one would need in analyzing a project of this type. The new system would need, among other things, to be compatible with existing systems at Rice with which it would need to interface, such as the financial system and the alumni record system.

An innovative feature in our RFP was the use of scenarios as a way to determine if and how well each of the vendors could suit our purposes. There were two good reasons to use scenarios for the RFP. First, it saved a lot of paper. In a traditional RFP, every conceivable exigency is laid out and explained in terms of what functionality the new system would need to provide. The respondents to the RFP must then answer in agonizing detail the exact nature of the functionality that is incorporated into their product. In the scenario-based RFP, however, we simply stated what it was that the system needed to do. From our point of view, functionality itself was not the issue. Completing the tasks laid out in the scenario was all that mattered. Period.

The second reason that we preferred a scenario-driven RFP was that the actual product that we were about to buy probably did not yet exist. In the same way that we as a client had gone through a visioning process relative to our preferred futures, we expected that our partner-vendor would be going through exactly the same kind of exercise relative to creating a Web-based, robust relational database system that would take advantage of new and emerging technologies in an innovative but reliable way. By giving our potential vendors a list of scenarios, we were, in effect, educating them about us and about how we expected to do business in the future.

For prospective students, then, sample scenarios included the following:

For currently enrolled students, a scenario might explore how a student would do these things using the Internet:

More complicated sets of questions required the vendors to think creatively about problem-solving from the university administrator�s point of view:

A student wishes to register for add/drop courses for an upcoming term online or via the Web. Describe how your system would handle the following scenario:

Because she did not provide a 1040 for financial aid, her aid has been held up and she has an outstanding balance due. How does your system explain this to her? Can she easily send e-mail to the appropriate office for more details? Can your system help her clear the hold on her account temporarily, pending receipt of the 1040?

The RFP was issued to a group of vendors, and responses were reviewed for technical, functional, and cost considerations. We also examined the technology and business risk associated with each proposal. The following considerations guided our thinking:

1. Vendor product must minimize hardware and database risk. We wanted mainstream technology solutions--a database engine with a proven track record and established server hardware and desktop solutions.

2. Vendor product must be low maintenance and easy for end users to master. To help us maintain a lean project team, we wanted a product that did not require extensive maintenance or training.

3. Vendor must know the culture of the small, highly selective research institution.

The top four vendor candidates were invited to campus to demonstrate their product�s responses to the scenarios. At the conclusion of the review, we awarded a contract to Exeter Educational Management Systems, Inc. for their Student Information System.

Implementing the New Processes

By early 1997 we had already developed our reengineering plan and were vetting it with many constituencies: students, faculty, the college masters, academic advisors, administrative staff, and the provost�s steering committee. We had conducted numerous focus groups, testing and confirming that our proposed integrated, no-stop shopping proposal was both feasible and desirable on the part of our various constituencies. We pressed forward with our changes.

For starters, we recruited an associate director of admission and financial aid to work within the office of admission to train staff and to work with prospective students in their pursuit of financial aid. As noted above, this person was given the responsibility of training the admission staff to effectively handle most financial aid questions and to be the prospective students� focal point for financial aid information. The new associate director was also placed in charge of packaging awards to new undergraduate students and negotiating, where necessary, adjustments to the original offer based on updated information and changing student circumstances.

To provide an environment where current students could go for all of their enrollment questions, new offices were created to house the financial aid, registrar and student billing, and cashiering functions in a single location. The remodeling required the registrar�s staff to move to temporary facilities while their space was renovated to allow the financial aid staff and registrar staff to be collocated physically. At the same time that this collocation was taking place, we created a new organization from existing staff to consolidate the backroom functions. The enrollment management operations center was developed and staffed. A new position to manage the operations center was created and filled. The operations center was the first group to test each of the new technologies and business practices as they have evolved.

As each group moved into its new physical space, we swapped out the old computer platforms and provided new workstations and training on the new information system. We modernized the telephone systems for most of the staff. We also put together teams of users from across the offices to establish the configuration tables for each of the new computer system modules. We established a student information users group which reached out across the campus and gave a much wider set of users--from the department of athletics to the faculty club, who use the student information system for billing purposes--a chance to learn what new was happening and to share solutions to common problems which might occur on the legacy system as well as the new system.

For the staff, a major part of the implementation was simply coping with the fact of change. We were very careful from the beginning to state explicitly that the goal of the reengineering project was not to reduce positions, but to provide better service. Within the staff there were periodic meetings to provide updates and occasional retreats to talk about change and to deal with the frustration and anxiety that change engenders. A number of position descriptions were rewritten based on new responsibilities, and staff members were integrally involved in the process of redefining their own jobs. Setting accurate expectations was critical in managing the staff as they moved ahead in this process. We also strove to manage the expectations of our in-house clients as well: faculty, students, departmental administrators, and senior officers.

Implementing the New System

In implementing the new student information system itself, we took care to sequence the installation of the four modules. We decided to use the Student Marketing System (SMS) module as a prototype to help us learn the new system and to tailor the installation process. The Student Services System (SSS), Student Aid System (SAS), and the Student Billing System (SBS) would each follow later in its turn.

Our very deliberate choice in selecting a vendor for this project was to find a well-established firm with a willingness to innovate along with us as we combined process reengineering with system design and implementation. Exeter filled that bill exactly. Although Exeter has a long track record in providing student information services to schools very much like Rice, they were just in the process of developing an Oracle-based system that would fulfill the needs that we at Rice had set out in our RFP. Accordingly, the process of installing the Exeter suite of student information modules was an iterative one in which Rice served as a beta test site and provided feedback to the vendor on what did and what did not work.

This way of doing business, of course, is fraught with risk. Whenever a deadline was missed in the delivery of a component piece of software, the task force leaders would convene for an emergency meeting to develop contingency plans. Whenever a bug emerged in a piece of code, visions of disaster danced across our monitor screens. But on balance, we believe the anxiety of being among the first customers to implement this product line was more than made up for in the quality of the product that we ourselves helped to design.

In terms of hardware, we built a computing infrastructure of Sun equipment for the central servers with an Oracle Enterprise Server as the database management system and Microsoft Windows NT on the desktop managed by Windows NT servers. In March of 1998 we began the installation of Windows NT on the admission desktops. This involved replacing Macintosh computers with PC computers, migrating data, and providing user training. In April the SMS pre-release software arrived so that we could begin to test features and provide feedback. From May through June we installed 58 NT desktops in the key administrative departments and scheduled the first of the end user SMS training sessions, which were useful in providing additional feedback to Exeter.

By the end of June of 1998 we had completed the pre-release test for the SMS, and the end users began working with production release 1.0 in learn-and-play mode. With SMS 1.1 scheduled to arrive in mid-July, we anticipated migrating operations to the Exeter Student Suite in August. One unanticipated problem that slowed us down in the implementation phase was our own lack of familiarity with the Oracle database management tools. To the extent that we were unfamiliar with Oracle, we could not readily perform quick fixes and program our way around problems. By fall of 1998, however, we were fully engaged in testing new releases of the SMS product. In the meantime, we revised our desktop client deployment strategy so that the new client is loaded on an NT shared partition, avoiding the need to touch 70 desktops every time a profile is changed or upgraded. In October we migrated the admission prospect data to the Student Suite from our legacy system.

Simultaneously, the SAS and SSS products arrived on campus and went into test-and-refine mode. The SAS (financial aid module) was relatively easy to implement, test, and place in service, due in large measure to the relatively straightforward algorithms that govern the administration of financial aid. The registrar�s system, SSS, however, proved to be more difficult to implement since many of the business rules that underlay the student record keeping and management had never been articulated in a way that programmers could use in producing code. True to our pattern of collaborative management, a work team got busy--meeting as often as two or three times a week--to write the rules that would ultimately become the backbone of the student academic record, advising, reporting, and degree audit structure. By summer of 1999 all suites were fully functioning, and the Web developers were moving ahead with the creation of the interactive interface that would permit our dream of no-stop shopping to become a reality.

Summary and Lessons Learned

The approach of the millennial doomsday provided the initial impetus for process reengineering and system replacement at Rice University. In the end, however, what we accomplished far transcended the simple problem of accommodating the switch to four-digit date fields. What we achieved was the thoroughgoing reform of our thinking about the way we do business and the role of technology in adding value to traditional processes. Without the new technological solutions, and especially the flexibility that comes with the World Wide Web, our student-centered approach to process reengineering would not have been possible. Essentially the lessons we learned can be summed up in three key areas.

Communication and managing expectations

The most important lesson that we learned in terms of process reengineering was the need to keep open the channels of communication with all constituencies while still maintaining a reasonable control over expectations. Internally, this meant that those engaged within the project had to have immediate and full-time access to the project managers so that those managers could triage emergencies and troubleshoot problems efficiently and effectively. Weekly meetings kept the front-line staff abreast of developments. Project management also met once a week for lunch to discuss developments and tactical concerns. Occasional all-hands meetings were called at those points in the process when major changes were about to be implemented. Externally, our communications strategy was to keep our constituents apprised of our progress--and of our problems as well--as we moved through the process. The provost�s steering committee received reports from the task force on a monthly-to-quarterly basis. Other groups were brought into communication with the process--through focus groups or information-sharing sessions--as critical junction points approached so that those groups could become part of the dialog about how to proceed and therefore become co-owners of the project itself.

New ways to manage data

In terms of system administration in this new environment, we discovered that the management of the new many-user information system would require us to develop radically new ways of managing data. We needed, for example, to abandon our traditional mindset about system updates and database backups. We developed a method of running client files from the Exeter modules on a Windows NT shared partition, which allowed us to deploy new versions of the Exeter client software with minimal overhead and no loss of time. As a beta test site, we needed at times to switch out entire modules every few days. Similarly, we used mirrored disks to maintain database availability. Full backups of the database were accomplished by breaking the mirror and backing up one copy while the other remained active. When we reconnected the mirror, the database images automatically synchronized. Using this procedure requires only five minutes of user downtime.

No dichotomy in administrative processes

One final lesson that we learned in this process was that no real dichotomy exists any more between the technology of administration and university administrative processes per se. What we used to call student services--admission, registrar, financial aid, student accounting--have in fact become manifestations of information management. Student service officers today are information managers who happen to be experts in recruitment, aid administration, or a whole range of other activities that are, at base, information driven. To that extent, the management of those functions has become inextricably intertwined with the collection, presentation, dissemination, and general management of pieces of information. In most institutions, this much has been understood for the better part of the last two decades, if not longer. What is different today is the rate at which change in technology is driving change within administrative processes. Institutions that do not recognize this simple fact will sooner or later lose ground to those that do.

At Rice, we are confident that, at least for the time being, we have been able to take advantage of technological solutions in ways that are creative and yet consistent with the culture that uniquely defines our institutional life.

Thomas J. Hochstettler ([email protected]) is associate provost, Barry P. McFarland ([email protected]) is dean for enrollment administration, Andrea Martin ([email protected]) is director of User Services, and Joseph A. Watters Jr. ([email protected]) is project manager, Students Systems, at Rice University. the table of contents