Serving Students Well Serves Us Copyright CAUSE 1994. This paper was presented at the 1994 CAUSE Annual Conference held in Orlando, FL, November 29- December 2, and is part of the conference proceedings published by CAUSE. Permission to copy or disseminate all or part of this material is granted provided that the copies are not made or distributed for commercial advantage, that the CAUSE copyright notice and the title and authors of the publication and its date appear, and that notice is given that copying is by permission of CAUSE, the association for managing and using information resources in higher education. To copy or disseminate otherwise, or to republish in any form, requires written permission from CAUSE. For further information: CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301; 303-449-4430; e-mail info@cause.colorado.edu SERVING STUDENTS WELL SERVES US Vice Chancellor W. Russell Ellis Tim Heidinger Bjorn Solberg University of California Berkeley, California VICE CHANCELLOR W. RUSSELL ELLIS: The first two years in my position as the head of student services on the Berkeley campus I was focused on the issues and concerns of Undergraduate Affairs and its relationship with the campus as a whole. I eventually turned my attention to technology because we were confronted by a number of forces that challenged our traditional methods of providing service to students. My contribution to the implementation of technology within the Division has been to focus the collective expertise, energy and money. Looking back on it now, I see that the forces which came together in the early 1990s forced the evolution of the roles and partnerships between Undergraduate Affairs and Student Information Systems as we wrestled with adversity, change, and technology. Let me tell you a little about our setting. The University of California, Berkeley, is the oldest campus in the nine- campus University of California system. Situated across the bay from San Francisco, we have a rich legacy of tolerance, diversity, student activism, faculty governance, and independence as exemplified in the decentralized nature of computing on the campus. The campus organizational chart shows the complexity of the administrative structure. I had been a Professor of Architecture before becoming Vice Chancellor for Undergraduate Affairs, a division which consists of 21 service and administrative units that support the educational mission of the University. These services include administrative activities such as admissions and record management as well as programs providing tutoring, student orientation, summer activities, and teaching improvement. The division works closely with its diverse collection of client groups: faculty, undergraduate and graduate students, staff, and the campus administration. The division's highest priorities are to invigorate students' educational experiences and to facilitate their academic progress, from developing their interest through early outreach, to optimizing their ability to perform in the classroom, to helping to prepare for graduate school or careers. But by 1991, the campus and Undergraduate Affairs was besieged by a number of trends which I anticipated would become more intense and which could not be ignored. * budget cuts * increased student fees * staff decreasing rapidly as a result of early retirement programs and layoffs * the general societal environment was becoming less friendly towards the university * basic changes in K-12 education due to inadequate financing, overcrowded classrooms, the array of social problems, cuts in college preparatory curriculum and high school counseling services which was having its effect on what and how the university provided services I knew that we had to use technology as a tool for making significant strides forward. Technology had been used for years to automate many of the processes associated with selecting, financing and registering students. We had been making progress at providing students and staff with accurate and timely information, but my vision of technology was not automation. My desire was for students and staff to incorporate technological advances into their view of their roles and positions in a changing world. In the Fall of 1990, I appointed a Divisional Computing Committee with four objectives: * Establish a set of goals and directions for Divisional computing to achieve during the next five years * Establish priorities for use in allocating computing funds during the annual budget process * Increase the level of awareness by Division managers about computing issues * Create a division wide commitment to address student service computing needs The following spring, the committee completed a report about issues and computing priorities for the division. Another committee charged with implementing recommendations of the first committee was appointed. At about the same time, I implemented an overcut in the division's budget to create a computing reserve in order to fund computing initiatives. In January of 1993, I appointed the Computing Implementation Group, consisting of five persons, chaired by Tim Heidinger, who at that time was the lead programmer in the Office of Admissions and Relations with Schools. My instructions to Tim were to: "translate the various reports. . ., the needs of the Division, and other developments on the campus into specific projects which will guide our computing efforts in the immediate future and provide the framework for changing the way we work in the division." Basically, I wanted divisional staff to be better prepared to provide quality service to students in an increasingly technological world and to work smarter, better and faster. TIM HEIDINGER: I accepted the assignment as Chair of the Computing Implementation Group with great anticipation. However, because all my previous computing experience centered around meeting the needs of a single office, I made a few erroneous assumptions. First, I assumed the Vice Chancellor for Undergraduate Affairs, who after all was my boss's boss's boss, would have much more authority over the Student Information Systems, the department which was synonymous with computing for student affairs units. The second assumption I made was I understood the nature of the assignment. In fact, the reconciliation of the Vice Chancellor's vision for technology with the operational realities of providing service to students is something that challenges me to this day. On the Berkeley campus the Office of the Registrar, the Financial Aid Office, and the Office Undergraduate Admission rely on centralized computing support for their functionality. Student Information Systems (SIS) provides this support with a combination of mainframe systems development, training, consultation and standard and ad hoc reporting. The offices of the Registrar, Financial Aid and Undergraduate Admission report to the Associate Vice Chancellor for Admission and Enrollment, who in turn reports to the Vice Chancellor for Undergraduate Affairs. SIS on the other hand, reports to the Vice Provost for Systems and Technology under the Provost for Research. As a result, the application of technology to the delivery of service to students has always meant collaboration and dependence between people who do not share a common boss, who may not have the same priorities and who face different organizational cultures and pressures. The relationship between UGA and SIS is not unlike the relationship between a popular restaurant and its customers. When customers in the Division have computing needs they look to SIS to fulfill the needs. The menu and the number of tables that SIS has to offer however is not limitless and much of the time there is a wait for a table. The relationship works most effectively with advance planning, either in terms of making a reservation or anticipating how long the wait usually is. I have never liked the idea of waiting for tables at restaurants, even really good restaurants, so early in my life I resolved to learn to how to cook. Not unexpectedly then, when I arrived at Berkeley I quickly became very uncomfortable with how computing support was structured, especially given the volatile nature of the admission process at the time. I started looking for ways to gain more control over my dining options. I reported to the Director of Undergraduate Admission whose main concern was the timely delivery of management and operational information, not the method by which they were delivered. At the time however, SIS was making preparations to replace our out dated Tandem admission system with a new system that was part of an integrated student database on an IBM mainframe. Naturally during this transition, resources for new development on the old platform were scarce. In the true spirit of collaboration and while SIS was looking the other way, I began to implement new functionality on the Tandem mainframe. The mainframe functionality that was added, however, was only the routine delivery of raw data, local desktop machines did all the necessary manipulation. With direct access to the kitchen we now had the option to wait in line and be serviced or do our own cooking. In addition, we were much better able to satisfy our craving for between meal snacks. and dishes which were not on the regular menu. The idea of using desktop machines to manipulate student data was not unique to the admission office or new to SIS. In fact, SIS encouraged the use of extracts and was providing them upon request. In addition, SIS was making plans to further exploit this trend by making all student data available with client/server technology. Not withstanding the technological issues of this new client/server environment, the Division was ill prepared to benefit from it. Never the less, the model was successful in the admission office and I assumed that it was that success which lead to my assignment as the chair the Computing Implementation Group. In preparation for my first meeting with the Vice Chancellor, I envisioned a discussion about the delivery of a system. A system to provide all the offices in the division with the reports, lists, and labels they needed to provide more efficient and accurate student services. Much to my surprise, the Vice Chancellor was not interested. His concerns were electronic communication, positioning for the future and implementing the recommendations of the Divisional Computing Committee. While I understood what the Vice Chancellor wanted, I could not see how it would help the division provide better service to students. In hindsight, I was expecting the Vice Chancellor to embrace the idea of opening a fast food restaurant. A different type of restaurant from the one provided by SIS, one which delivered meals much faster and cheaper, but a restaurant never the less. Vice Chancellor, on the other had, did not want his staff to remain customers. He wanted a staff of cooks, believing this to be the best solution to the problem of satisfying their hunger. "Teachers perform the strange magic of doing something important while doing nothing tangible." (Stuart Serman, "Time and teaching, teaching in Time," The University of Chicago Magazine, October 1994: 31) Indeed, given the direction of technology to a client/server orientation, a new partnership needed to be formed between SIS and UGA. In this new client/server world SIS would no longer be the restaurant, it would be a grocery store. SIS would not be providing meals but the food stuffs necessary to create the meals. It was imperative then, that UGA follow the vision of the Vice Chancellor and learn how to become cooks. Over the last almost two years now, the Implementation Group has struggled with ways to prepare the division for its new partnership with SIS. Two constraints we had to work under were: * We had responsibility but no authority. We could recommend, we could discuss, we could train, we could set standards, but no one had to do any of the things suggested. * We had some money but no staff Given these constraints, here is a brief summary of the types of activities the Computing Implementation Group has pursued: * Make recommendations about hardware and software standards as well as providing a central point for questions, referrals and review of departmental technology proposals. * Implement policy to fund network access for all offices * Implement policy to fund software training courses for all staff. * Foster communications by maintaining division wide and specific e-mail reflectors. * Identify and coordinate the usage of all new types of computing resources available on campus. Coordinated specialized training session with the office responsible for computer training. Coordinated implementation of divisional usage of e-mail and gopher serviced offered by new central UNIX computer. * Occasionally, develop something which does not/cannot exist elsewhere on campus. For example, a way to update our gopher server with email. * Investigate the application of new technology. For example, we have been fostering the development of World Wide Web servers within the Division. * Explore the security and confidentiality issued involved with the new client/server access method. * Foster collaboration between the computing staff within the division. As a result of these activities, the Division hopes to foster an environment where effective conversations about computing can occur, collaborative decisionmaking and sharing of information about computers can be promoted, and the Division can become an effective lobbying group for campus computing. Additionally, with a competent staff who know how to be cooks as well as customers, we look forward to a new partnership with SIS. - each partner accepting responsibility for their part in the world where computing will be delivered within a client/server architecture. DIRECTOR BJORN SOLBERG: POISED FOR THE FUTURE: TECHNOLOGICAL ADVANCES IN CENTRAL SYSTEMS While Undergraduate Affairs was undergoing change in the computing area, SIS was also in the middle of a major shifting in frames of reference and our relationship to the campus. And, although one of SIS' biggest clients, Undergraduate Affairs was only one of several constituents which we were trying to serve. Currently, at the University of California at Berkeley central student systems are well positioned to meet current and future campus computing needs. Student data are consolidated in an integrated IDMS Student Database. All systems reside on a single hardware platform. Central student systems are interactive and widely used on campus. All central student data are stored in the IDMS Student Database, and most central student systems use this database. From a user perspective, we have a single image system, with data being sharing between systems and virtual elimination of system interfaces. This was not always so. Dramatic advances in upgrading and improving campus student systems has occurred in the last seven or eight years. How Things Were Central student systems used to be fragmented, reflecting a lack of overall planning. Systems were developed in response to the needs of individual central student service offices. Systems didn't interact effectively, because interfaces were not emphasized in the original designs. The systems were essentially stand-alone systems that were meant to serve a narrow function. Each system had its own files, and there were inconsistencies and redundancy in data between systems. Data were collected by individual systems, requiring students and staff to enter the same data multiple times. At least four different student identifiers were used, complicating interfaces between systems. Systems operated on more than one hardware platform, making it necessary to ship data back and forth between different computers to synchronize data in different systems. There was disagreement about the future direction of student systems. Proponents of the Tandem minicomputer wanted student systems to operate on the Tandem, and others argued for consolidating student systems on the campus IBM mainframe computer. Student systems operated on both machines, making it necessary to establish a two-way communication between the two machines in order to try to synchronize student data. There were numerous problems associated with this arrangement, including data inconsistencies, confusion about where the most accurate and up-to-data was stored, and the need to do a lot of processing that was aimed strictly at trying to synchronize the data on the two machines. The feelings on both sides were intense, culminating in the equivalent of a religious war on campus about computing. The dispute interfered with planning and was an impediment to progress. Two different committees reviewed campus administrative computing and issued critical reports. There was dissatisfaction with central administrative systems. The Student Information Systems (SIS) Department was created as a result of a reorganization of campus administrative computing. When SIS was formed in 1987, we recognized that things had to change in order for the organization to be viable. We attempted to learn from the past mistakes of the central administrative systems department and made the following changes: * Encouraged collaboration with users * Emphasized the service role of our department * Improved productivity by emphasizing development and shifting resources from maintenance * Initiated a long range planning effort in partnership with users * Changed the governance structure for student systems giving users the authority to set work priorities for SIS projects SIS management devoted much time and effort consulting with users about student systems planning and attempted to build a consensus for student system projects. Efforts to Achieve Consensus A needs assessment conducted by SIS and representatives of user offices in 1987 concluded that current systems reflected a lack of overall planning. In order to remedy this problem, SIS and Undergraduate Affairs began to do long range planning for student systems. As a result, in 1990 the Student Information Systems model was published, in 1991 the Five Year Systems Plan was issued, and in 1993 the Five Year Systems Plan was updated (available from the CAUSE Information Resources Library-CSD0924). We are working on the 1994 version of the Five Year Systems Plan, which will be published in December. SIS's strategy for getting agreement on a long range plan consisted of documenting current problems, preparing an objective assessment of current systems, and preparing a plan that was realistic and would solve major system problems. Our plan called for developing an integrated IDMS Student Database, consolidating all central student systems on a single hardware platform (IBM 3090 mainframe computer), and converting to a single student identifier. New Governance for Student Systems In 1989, while working on the development of a new on-line add/drop enrollment system, we started using a new governance structure. A project steering committee chaired by a faculty member (Dean of the College of Letters & Science Advising) and comprised of representatives from affected offices, faculty, and students was established. The committee was large and had broad campus representation. The steering committee was responsible for determining system requirements and setting work priorities for the SIS project team. This model was very effective and has been used on subsequent system projects. This approach is now always used on systems that have campus-wide application. SIS has benefited from this governance structure, because we are getting clear directions about what is wanted by the campus. Collaboration of SIS and Users One major reason for our success and progress with student systems is the strong support we have received from users. Early on, the Associate Vice Chancellor for Admissions and Enrollment offered encouragement and support for our planning activities and system proposals. He recognized that a partnership between his units and central MIS had the potential of benefiting the campus. He encouraged other units on campus to participate, leading to the involvement of the College of Letters & Science. We have learned that the combination of the central computing organization and the major student service organizations on campus has been effective in getting campus support for new student service initiatives. The combination of different offices has been more effective than individual offices acting alone. Evidence of this is provided by the fact that the campus approved this fiscal year approximately $612 K in funding for three campus student service initiatives: Tele-BEARS (the touch-tone telephone based enrollment system), DARS (a new degree audit reporting system), and Bear Facts (Berkeley's version of the Mandarin technology based system developed by Cornell University). New funding is hard to get when the campus is facing overall budget cuts. New Directions for Campus Student Systems DARS is a new system that SIS is in the process of implementing. This system is based on a application system package purchased from the University of Miami at Ohio. We are working on integrating the Miami package into the Berkeley student systems environment. For example, we are creating an interface to the IDMS Student Database to obtain student transcript, profile, and enrollment data for the audit report. Degree audit reports will be available on-line as well as in printed form. Since degree audit reports are now prepared manually, the implementation of this system will save much staff work and improve service to students. We are aiming to go into pilot production with this system next summer. Bear Facts, Berkeley's newest student system, is being developed using the Mandarin technology created at Cornell University with funding from Apple Computer and IBM. In our version of the system, student data will be extracted and downloaded from the IDMS Student Database to a server machine running ORACLE. The downloaded data will be stored in a relational database using ORACLE, and this database will shadow the IDMS Student Database. The server database will be refreshed on a nightly basis. Students will be able to access their data on the server database using Macintoshes or PC's. Screens providing information about various deadlines, locations of student service offices, transcripts, final grades, billing status, financial aid applications, and current enrollments will be offered to students. Initially, limited updating (e.g., student addresses) will be supported. Most activity will be to display data, with an option to print on a connected printer. Bear Facts will provide a new way for students to access central student data and will supplement the access to central student data provided by our touch-tone telephone system. It will also provide SIS with a new alternative for future systems development. As we gain experience with the client/server environment, we will assess whether we want to add functionality to the server-based system or shift functions from the IDMS system to the server. We are seriously thinking about the possibility of migrating some services from IDMS to the server machine. We are excited about the prospect of experimenting with different options. This offers us the opportunity to try out a client/server architecture in a situation where risk can be minimized. Computing technology is developing at a rapid pace. Distributed computing is growing, and this is reflected by the increasing numbers of programmers in user offices. A campus survey completed last year indicated that only about 43% of the staff holding programmer classifications work in the central computing organization. Most programmers are now working in departments. Much of the departmental activity is dependent on using centrally stored data. SIS encourages user offices to extract and download centrally stored student data, minimizing duplication of work that already has been done. For example, departments do not have to collect data from students since it is already stored in the central database. The central IDMS Student Database continues to be the official student record for the campus, containing the most up-to-date and accurate information. The new ORACLE database will provide a new and more convenient way for users to access central data. We plan for users to access the ORACLE server database to generate their own reports. Point and click types of front- end tools that generate SQL queries to generate reports will be used by our customers. A convenient means of generating ad hoc reports has been missing in the IDMS mainframe environment, so we are excited about the prospect of being able to offer this new service to our users. WHAT DID WE LEARN? * Technology in and of itself cannot resolve "computing" problems; communication and dealing with people effectively are the key to managing this area * Ask users to help define the problem, issues and solutions * Working in collaborative partnership can be very effective * New environments require new adaptations * In order to move forward, we need both tangible and intangible goals * By achieving the goal of serving students well, we eventually also serve ourselves