Introduction
Background
Defining the Problem
Designing Process Solutions
Choosing the Software System
Implementing the New Processes
Implementing the New System
Summary and Lessons Learned
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--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.
The most compelling reason for Rice to contemplate replacement of its student information system in 1996 was the approaching millennium crisis. Rice's old student system had been purchased in the 1980's 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 difficult to acquire. 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 to which we had become accustomed with our old system. The decision, then, to purchase a new system that would be, among other things, millennium-compliant was by itself an easy one 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 complaints and faculty discontent--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 market share for students was growing, as Rice pushed out beyond its traditional Texas hunting grounds and onto the national scene, marketing itself as a highly selective university with a superb faculty and a campus located in a city where a day in January is considered cold if the temperature only reaches seventy-five. Our students were not complaining about the level of service they were receiving, and although the faculty had some perennial concerns about the course schedule, by and large the instructional staff were very 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 David Auston, 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 paper work associated with an expanding pool of applicants had placed unprecedented strains on our capacity to process applications for admission and financial aid in a timely fashion. Turnaround time for responding to requests for application forms and information from prospective students was growing longer year by year. By the peak of the spring, 1996 admission season, the delay between the point when an initial call was logged and the response was mailed out had grown to more than a week.
Anything resembling an executive information system was utterly lacking under the old system. Status reports and data for special studies were extremely difficult to obtain from the old system, so that senior administrators received spotty information at best on the status of the admission process. Yield statistics for admitted students at the beginning of the academic year were slow in coming from the system, as were the number of actual new matriculants during orientation. In the area of graduate studies, the old AIMS system provided virtually no capability for analyzing the pool of prospective students or for scrutinizing enrollment trends. Academic advising at both the undergraduate and graduate levels was carried on in a virtual information vacuum. Moreover, our competitors were not standing still while we groped along. All other things being equal, the best students were more likely to apply to and attend the school that was most attentive in responding to their needs for timely information. In these circumstances, Provost Auston in late 1996 mandated a serious program in process reengineering so as to take advantage of the anticipated upgrade in technology in solving some of the chronic problems that plagued our student services in those areas under his jurisdiction.
In September, 1996, the Provost assumed the role of Project Sponsor and convened a Steering Committee, consisting of himself as chair, plus the three other senior vice presidents of the university, namely the Vice Presidents for Finance and Administration, Student Affairs, and Information Technology. The stated purpose of the Steering Committee was not only to replace the old AIMS system but also to launch process reengineering within each of the key offices that used that system to accomplish their work. These included the Office of Admission, the Registrar, the Office of Financial Aid, and the Cashier. Accordingly, the Associate Provost was appointed to head an Enrollment Management Task Force of the principal managers in each of these offices plus several others besides, including senior people from the Graduate Studies Office, Academic Advising, and Institutional Research. To all of these were added the Information Technology Director and the Student Information Project Manager, who would be responsible for the care 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. The following chart shows the general lines of responsibility as the project moved forward.
Beginning its work in fall, 1996, the Task Force decided on a simple process to analyze work flow in the area of student services. In an effort to educate ourselves and each other about what we did and to begin mapping our preferred futures, 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 of the offices represented in the Process Team 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.
The "What-is" scenarios were enlightening. It turned out that there were many instances of 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 enterprising undergraduates appeared one day in the Registrar's Office recently with large rubber stamps containing their critical biographical statistics. Point made. At the same time, many processes continued to generate work and outputs that no one any longer truly needed. 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.
The Task Force imposed two constraints on those putting together the "What-should-be" scenarios. First, each office was enjoined to examine work-flow 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 offices that were providing service. 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 tremendously from being able to access records and to transact business over the network.
Contriving "What-should-be" scenarios turned out to be very hard work. Despite the agony of trying to envision a preferred future, however, this exercise proved to be even more valuable than the "What-is" exercise. For staff members who have worked for years in relatively isolated processes, 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, an obvious shortcoming in our admission process. Although virtually every call that came into the Admission Office contained some inquiry about the availability of 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 start, beginning with 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.
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 by-word 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.
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 for students and administrators alike. Our goal was to enhance that culture, not to change it fundamentally or to destroy it. 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 result improved service to students. Moreover, we wanted to make certain that the changes were compatible with student expectations about their Rice experience.
Of course, the term "students" defines an ever-changing commodity. In the first instance, it refers to the great mass of undifferentiated prospective matriculants, that is, high school students who, by and large, had little or no first-hand experience of the Rice culture. They needed to be wooed and won. For these students, the primary need was for information, lots of information. From our perspective, the first contact with the prospective student was our opportunity to begin to develop a client relationship with that student, a relationship that could eventually grow into a lifelong contact as the prospective student became an applicant, an admitted student, a matriculant, and finally a graduate and alumnus. All aspects of this process needed a single, unifying Rice voice. This voice was not necessarily the same voice one would use with a current student, alumnus or faculty/staff. The offices that traditionally deal with prospective students are admission, financial aid, and student billing. Each has its own language and set of values--in short, its own culture, and those cultures were not historically mutually consistent in terms of their interactions with prospective student.
The term "students" also refers to our currently enrolled students. These students are intimately familiar with and indeed a part of the Rice culture. Their needs 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 members of the colleges in their role as faculty advisors and college associates. Students expect to have immediate access to faculty and staff through the colleges, as well as through their academic work in the classroom and lab. Many of the problems facing current students--personal problems as well as those involving their schoolwork--are resolved in informal relationships through their residential college system.
To a degree not found in many other research universities, Rice undergraduate and graduate students are empowered to make many of their own decisions. Rice has, for example, a strong honor code that 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 all organizations of administration at Rice to be very responsive to their needs. Simply stated, students are capable of completing the numerous administrative tasks related to enrollment without major problems or handholding. But when they have special needs or requirements the university must provide the resources to help them solve the problem in the quickest and most efficient manner possible.
Three major changes emerged from our study of processes. First, we decided that we should 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 type of issues that they ask about. Thus, a first change that we undertook was to consolidate into a single location those functions that have to do with admission. The most important change in this regard was the creation of 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. Moreover, that officer was also charged with training other staff within the admission office in the rudiments of financial aid, so that virtually anyone in the office could provide informed responses to incoming calls concerning student billing practices and 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. From our survey of students, it became clear that the sharp distinction that we as administrators drew between the functions of the registrar and the director of financial aid were at best opaque, at worst, irrelevant. If a student has trouble registering at the beginning of the year, 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 two operations together, empowering the staff in each of the former units to transact business across the spectrum of student problems. It was also decided that the cashiering operation should also be incorporated into this mix, and at a future point, that amalgamation is also contemplated. For the time being, we gave the staff in the new Enrollment Center the authority to accept payments for tuition and fines.
The third majorchange that was undertaken in the course of process reengineering 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 back-room operations. The tasks performed as back-room functions include clerical, 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. Thus, when admission functions were heaviest, it was frequently during a slower time for registration, financial aid or student billing. There remained however, a number of times during the year when there were just not enough resources to meet the demands of each office in a timely manner. By selectively implementing complimentary technology and a small cadre of temporary staff, we thought we could provide better service to the current students, prospective students and improve the overall satisfaction among both the professional and clerical staffs.
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 system. In this system 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, email, 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 valued 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.
As these processes were developed within small working groups, they were shared with the full Task Force, with the clients and with focus groups within the university. Many ideas were found to be lacking reasonableness, some would have changed the culture in undesirable ways, and some seemed to provide the results we wanted-- providing better service to our clients and enhancing the positive aspects of the university. In the end, we kept what worked within the Rice environment and rejected solutions that might have been perfect in theory but unworkable in fact.
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 and issue a regular Request for Proposal or RFP, which would lead us ultimately to the best vendor for the project.
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:
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 single exigency imaginable is usually 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 the information management 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. We as the client therefore needed only to sketch out the scenario and the potential vendors had only to tell us whether and how they would fulfill the tasks that it contained. Period.
The second reason that an RFP based on scenarios was desirable 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 in the future to do business. We hoped through the scenarios to get them to think creatively about our student-centered work processes and about how their system might fit into our way of operating. 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 a web interface. Describe how your system would handle the following scenario:
She has failed to provide a 1040 for financial aid, hence 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 email 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. We were careful in our final review to pay particular attention to several critical considerations:
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 Suite.
All of the pieces to this puzzle came together at about the same time. We had already developed our reengineering plan by early in 1997. We had spent a considerable amount of time and energy vetting the proposed changes in procedures with many constituencies: students; faculty; the heads of the residential college system, the College masters; academic advisors; administrative staff; and the Executive Committee, headed by the Provost. We had held exhaustive focus groups to test whether our proposed one-stop shopping proposal was feasible and if so whether it was desirable. The resounding answer came back that the changes that we proposed were indeed both feasible and desirable, and we pressed forward with our changes.
For starters, we recruited a first-rate 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 tasked with 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 circumstances on the part of individual prospective students.
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 physically collocated. At the same time as this collocation was taking place, we created a new organization from existing staff to consolidate the back-room functions. The Enrollment Management Operations Center was developed and staffed. A new position to manage the operations center was created, and we were fortunate to find a strong advocate of change and efficiency to fill it. This person has been key to managing the change process for the staff in that area. The operations center has been the first group to test each of the new technologies and business practices as they evolve.
As each group moved into their new physical space we swapped out their old computer platforms and provided them with new workstations and training for 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.
As the implementation process evolved, there were of course a number of interim steps as the project leaders sought to manage the expectations and anxiety of the staff and the community. For the staff, a major part of the implementation has been 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. Feedback from the staff on changes to business practices and critiques of the new system have been encouraged. Both formal and informal meetings, email, memos and phone calls have provided the implementation team helpful feedback and have served as an important barometer of staff concerns. A number of position descriptions were rewritten based on new responsibilities, and staff members have been integrally involved in the process of redefining their own jobs. Setting accurate expectations has been critical in managing the staff as they move ahead in this process. We have also worked to manage the expectations of some of the in-house clients such as faculty committees, departments, and administration. Key groups have been provided with periodic updates and queried as to their own changing requirements. We have been careful to proceed cautiously in terms of managing expectations, since we wanted to show our constituencies some real options rather than just discussing what might be. We have also provided the student community with updates through the student newspaper and select student committees. As one would expect, the students have embraced the changes.
Implementation of the new information system is still a work in progress. For the new student information system itself, we planned to stage 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 follow later as a group.
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 hasa 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 in some cases indeed as an alpha 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 in the final analysis, we at Rice have enjoyed the tremendous advantage in the development of the Exeter systems of being the beneficiary of a great deal of customized programming and made-to-order solutions. On balance, we believe the anxiety of being among the first of Exeter's customers in the implementation of this product line was more than made up 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. (See the Appendix for details on the equipment configuration.) In March, 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 other key departments (Registrar, Financial Aid, Graduate Studies, Cashier, Academic Advising), 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, 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 perform quick fixes and program our way around problems as readily as we might otherwise have done. Ultimately, we also experienced slippage in the delivery and installation dates. By fall 1998, however, we were fully engaged in testing new releases of the SMS product complete with communications tracks. 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. By October, we were able to migrate the admission prospect data to the Student Suite from our legacy system. Simultaneously, the SSS and SAS products arrived on campus and went into test-and-refine mode. Our target date to have the entire suite up and running is early 1999, when the web-interface phase of the project will begin in earnest.
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.
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 trouble shoot problems in an efficient and effective manner. Meetings were held at least weekly with the front-line staff to keep them abreast of developments. Those engaged in 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. Accordingly, 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 co-owners of the project itself.
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 new ways of managing data that were radically different from our earlier patterns of behavior. We needed, for example, to abandon our traditional mindset about system updates and data base back ups that we had inherited from our earlier mainframe existence. After some false starts, 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. Because we were a beta test site for the software, there were occasions when we needed to switch out entire modules every few days. Similarly, we learned to use mirrored disks to maintain database availability. Full backups of the database are 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. This procedure allowed us to create a full database backup with only five minutes of user downtime. Without developing new strategies for back-ups and file management, we would have had considerably more difficulty in proceeding with the conversion.
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, albeit in service to the members of the university community. Student service officers today are information managers who happen to be engaged 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 of change in the technology that is driving change within university administrative processes. Institutions that do not recognize this simple fact will sooner or later lose ground to those that do. We at Rice are confidant 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.