Return to the Integrated Systems Project Home Page


University of Virginia

Integrated Systems Task Force

Study Group #1

Final Report

October 21, 1996


December 20,1996

ISTF Study Group 1
Executive Summary of Findings

Study Group 1 is composed of representatives from the University's academic and administrative units. Its charge was to identify strengths and weaknesses of the existing administrative systems and to recommend a replacement order for them. Data were collected from steward, end user, and technical support focus groups organized by system (HR/Payroll, ISIS, and Financial). Members of the Group also contributed to the systems assessment. The summary below is responsive to the charge; it also identifies selected issues that arose in the Group's discussions that, although not covered explicitly by the charge, are important to bring forward as the University continues its evaluation of administrative systems.


- The systems work: the high degree of system integrity (data security, operational integrity, and system policies) yields many benefits, such as meeting management standards, increasing autonomy from the state, and allowing decentralized transactions.

- Integration is good: to the extent that system integration exists, for example in ISIS, it is viewed as a positive and useful attribute. Instances of integration, however, are few and far between.

- People: the people who program, maintain, and support systems and the users of the systems are competent and resourceful.


- Data are inaccessible: in general, system data cannot be maintained, accessed, or manipulated at users' desktops.

- Technical dis­integration: the multitude of platforms on which systems currently exist and the modifications made over time to source (proprietary) code make system maintenance and integration costly and inefficient ­­ and, in some cases, impossible.

- No common interface: the lack of a common "look and feel" and the "un­user­friendliness" of most interfaces reduces productivity, increases training costs, and complicates the move toward a paperless environment.

Order of Replacement

(1) HR/Payroll. The Group did not assess whether to continue work on HRS (at an accelerated pace) or to replace the system. It is clear, however, that the burdens and inefficiencies imposed by maintaining the current hybrid system demand immediate attention.

(2) Budget and Departmental Accounting Systems. A replacement for CUBS and a departmental budgeting and accounting system are considered essential to managing in our ever­changing and complex environment.

(3) ISIS. Improvements are needed, but system replacement was not viewed as a high priority in this context.

[4] Other issues such as the cost of interim "fixes," the effort required to make systems Year 2000-compliant, and the priorities for process simplification should also be factored into the final decision on the order of replacement.

Ancillary Issues

- The University has a generally first­rate workforce that is, unfortunately, often working with less than first­rate tools.

- We are managing too many complicated projects with too few people over too long of a time. We acknowledge, however, that many promising projects ­­ process simplification, electronic forms, information warehouse, on­line employee transactions ­­ have the potential to make dramatic improvements to business processes and in the quality of work when they are functioning fully and when users have been trained thoroughly in their use.

- Systems should be implemented only when fully developed and tested. These processes must include significant end-user input from the design stage forward.

- System flexibility is an asset that comes with a price. Our ability to meet many user and steward needs often is limited not by the system but by policies and resources.

- Real business requirements that are not accommodated within existing systems are behind most uses of "shadow" systems. Most UVa operating units manage by using data contained in the shadow systems. If a goal of integrating administrative systems is to reduce the dependence on these complementary systems, then these needs must be addressed during system development.

- The costs and benefits of developing systems for multiple end-user platforms and of moving to client­server­based systems must be assessed comprehensively and rationally. There [is] may be a trade-off between inherent system functionality and the number of client platforms on which it must operate.


Study Group 1 of the Integrated Systems Task Force was composed of 14 members representing many of the University's schools as well as several administrative and support offices (for a complete list of Study Group 1 members and affiliations, see Appendix A). The charge to this study group was as follows:

This Group is charged with identifying the strengths and weaknesses of the University's systems in the following mission-critical areas: Financial Systems, Student Systems, and Human Resources Systems. The analysis will be based on the Study Group's own perspectives as well as information gathered through interviews with department heads (or their representatives) and technical project leaders. In addition, this Group will recommend a logical order of replacement of current systems.

Study Group 1 felt that there were three broad constituent groups that should be queried about each of the three systems identified above. They include I) the stewards of the systems, II) the technical representatives in ITC as well as in the central administrative departments that shoulder the burden of technical up-keep and maintenance, and III) the users of the system at the school, department, and administrative level. Further, the Study Group felt that the term "system" should be defined broadly to include not only the high-tech hardware and software systems involved, but also the human component that might be represented by the less technical aspects of manually filling out forms, running to "drop boxes" to submit completed forms, etc.

Given the above foundations, the following methodology was adopted by Study Group 1. Focus group participants, representing each of the three clientele groups (stewards, technical reps, and end users), were identified through the corporate knowledge of Study Group 1 members. They were in turn asked to participate in these focus groups and were sent a group of questions designed to stimulate their thinking prior to the meeting. These questions were generic in nature in that they did not address a particular system group (i.e. Financial System, Human Resources System or Student System), but they were carefully crafted to focus on the function, efficiency, timeliness, redundancy, control, input/output, maintenance, and integration of the University's systems as a whole. Study Group 1 was then divided into three sub-groups of four members each, and each was assigned a University system to evaluate: Financial Systems, Human Resources Systems, and the Integrated Student Information System. After attending a seminar given by Shelley Payne of Organizational Development and Training on how to prepare for and conduct a Focus Group, each system sub-group then held three separate Focus Groups - one each for the system stewards, the technical representatives and the systems' end users. Each focus group had a designated facilitator, moderator and note-takers. After the focus groups were completed each system group prepared a summary and analysis of their findings which was discussed by Study Group 1 as a whole, and which served as the basis for Study Group 1's conclusions and recommendations.

The members of Study Group 1 are grateful for having had the opportunity to gather this information and to report on the strengths and weaknesses of the three systems that were studied. The group would like to point out, however, that the work of the group consumed a tremendous amount of time, both of the group members, and of the many individuals who participated in the focus groups. We estimate that in excess of 500 hours of people time (including the Study Group and the Focus Group participants) were committed to this undertaking. The people interviewed as part of this process demonstrated that UVa is indeed fortunate to have many first-rate employees, who, unfortunately, often must work with less than first-rate systems and tools.

Integrated Student Information Systems

End users, technical experts, and stewards agreed that the current integrated student information system is performing satisfactorily. Its greatest strength is derived from its original design: the system performs exactly as it was designed to perform, because we (users, stewards, and technical experts at the University of Virginia) designed it. All three groups voiced a need for a more friendly, Windows-style graphical interface. The technical and end user groups both raised questions about the impact that internal policies and decisions have on system performance, especially with regard to data access versus confidentiality of data. Although ISIS contains a queriable database, few individuals are permitted to run queries against it.

There was consensus in all groups that the systems are reliable, and all expressed confidence in the security of data. The integration of data from the registrar, bursar, admissions, and financial aid areas was a noted strength. Integration promoted common business rules and common data definitions, and it minimized redundancy.

End users were generally pleased with ISIS. Frequent users experience very few problems using the system; however, using ISIS is much more difficult for the occasional user. Data are entered once into ISIS. Any duplicate data entry occurs between ISIS and shadow systems, not within the modules of ISIS itself. In terms of data entry, the end users we met with have no problem with the current practice of having most data input done by others, but they could and would accept increased responsibility for inputting data and monitoring its accuracy.

Users felt that the information held within the system was comprehensive, but not easily accessed.

Complaints about the system generally fell into one of two categories: 1) the accessibility of data, and 2) the ability to make changes to the system. With respect to the accessibility of the data it was noted that information is not always available at the time it is needed, especially in critical times such as during registration and degree certification periods. Also, some of the data included in ISIS are not available to all users. The data that are available cannot be retrieved or manipulated easily, and requests for reports often take weeks to process. Members of Study Group 1 observed that some of the "inflexibility" described here has been caused by internal policy decisions rather than by deficiencies within the ISIS system itself. With respect to making changes to the system, focus group participants observed that modifications to the system -- screens, data fields, etc. -- are managed centrally, and that there is a backlog of requested changes. The ability to make changes -- and the speed with which they can be made -- appears, to the study group, to be primarily a matter of resource allocation or resource availability. However, a number of user concerns might be dealt with effectively if users were able to meet periodically with the stewards of the system to discuss their needs and concerns.

End users pointed out that ISIS does not track all of the information that they need, nor does it accommodate all of the variety of needs among schools. This results in a proliferation of shadow systems. These systems meet real business needs, and to a large extent they don't duplicate ISIS, but complement it. Study Group 1 saw this as a critical point. Although it is a "best of breed" system, designed largely in-house, ISIS clearly does not alleviate the need for school or departmental shadow systems.

The technical experts with whom we met noted that the system was designed to meet the needs of the University and it does. According to this group, ISIS is not an inflexible system. Rather, policies, procedures, and the high cost of technical support are what make it inflexible.

This group estimated that a "best of breed" system off the shelf would meet 40 percent of "real" business needs of the University -- the "must-haves." The group also noted that "flexibility is an asset that comes at a price." In the context of the discussion, this is interpreted to mean that we can achieve greater than a 40 percent match to the University's multiplicity of business needs if we are willing to pay the price and spend the time. The group surmised that integration of administrative systems could result, under certain conditions, in more shadow systems.

The system can be altered with a reasonable amount of knowledge and effort. Primary deterrents to modification are the lack of sufficient resources -- people and dollars -- to make approved changes and the code, which, because it is proprietary, makes maintenance and integration more difficult and time-consuming. Mandated changes seem to take the majority of the resources allocated for ISIS maintenance and enhancement.The technical group suggested that a middle ground between best of breed and single vendor partnership -- "technical integration" -- be considered by the ISTF.

The stewards of ISIS were very happy with the present system, because it was developed with input from users. They stated that among the system's greatest strengths are its design and the manner in which it was implemented (put into production). It is home grown, and it meets the needs of a diverse constituency. The system's stewards meet monthly to discuss issues concerning the system.

The stewards unanimously see no compelling reason to implement a new student information system now or in the near future. Nevertheless, the ISIS stewards are constantly looking for new ways to improve the services they provide and have several new projects in progress including a WWW interface to student information and the extension of voice-response registration to DCE and Summer Session.

Financial Systems

The following financial systems were evaluated: the financial accounting system, accounts payable, purchasing, the university budget system, the office of sponsored programs, the fixed asset system, and departmental accounting systems. The overwhelming issue cited by the users of the financial systems is the lack of training available. The financial systems, especially FAS, are generally very stable and contain most of the information that might be required by an end user. It is this stability, coupled with the fact that "it just works" and is well designed, that has allowed the University to keep up with state and federal mandates over the past 20 years. This, in turn, has helped with decentralization. However, in past years it has been necessary to have knowledge of SAS programming, or know someone who does, in order to generate reports that contain useful information. This is beginning to change with the implementation of the Information Warehouse. The major drawback cited by users of the Information Warehouse is that the system contains only summary data. End users felt that it was important to include all data --detail as well as summary -- in the warehouse so that customized, useable reports could be generated. The technical experts were questioned about the feasibility and suitability of, in essence, maintaining two systems (FAS and the Warehouse). The general consensus is that it would not be a problem, since only FAS would be maintained and feed the Warehouse, whose role would be to function as a static reporting tool.

In general, the financial systems maintained on the mainframe were not designed to meet the needs of the end users. In fact, when the respective systems were bought and installed at the University, the convention was that such systems were designed to service the areas of central administration. "Front end" systems were designed and built by the University in order to provide acceptable end user access. It was a general consensus of the stewards that most of the systems on the market today are still marketed mainly to central administrative offices, and not for the more unique decentralized system prevalent today at the University of Virginia. Both stewards and technical experts are concerned that customization will make future upgrades and modifications more cumbersome.

Although most purchase requests are submitted on-line to Purchasing (which provides the end-user with an apparent paperless system), information entered cannot be manipulated on-line, and paper documents must be generated to process orders. CAPPS is old technology and is not compatible with Graphical User Interfaces (GUI). The system is not user friendly, and multiple screens are required for the simplest transactions. Extensive training is required for purchasing staff using the system. Other deficiencies of the system include the following: no EDI (Electronic Data Interchange) capabilities; no automated bid system; no payment tolerance by purchase order; and the system does not allow for document scanning, forcing both departmental and central administrative users to process multiple paper documents. As the number of departmental users increases, system response time slows measureably. This fact limits the number of decentralized departments which can be added. Ask Jeannie to clarify last sentence.

CAPPS has only limited reporting capabilities, which requires the stewards to maintain staff with knowledge of the SAS programming language in order to retrieve data. End user departments have no reporting capabilities. Several departments have expressed an interest in generating their own CAPPS reports.

There was consensus on the part of the users, stewards, and technical experts that CUBS, the University's central budgeting system, should be replaced as soon as possible. The inherent flaws in the initial design of the database mean that it is virtually impossible to "patch" CUBS so that it will provide the University with the necessary tools to budget and forecast.

There are also deficiencies in the departmental accounting packages in use by the end user departments. AMOPRO is, by far, the most used tool. However, the system has not been maintained and developed to keep pace with our changing environment. It is imperative that the University provide a comprehensive departmental accounting package that will allow the end user community to not only interface with the central systems, but also be able to generate detailed report information that cannot be obtained from the central financial systems. It is also important that any departmental accounting package be customizable to accommodate differences between end user departments. For instance, many end users wish to track information by faculty member or by program type. There is currently no way, without a departmental shadow system, to track such information. This problem could be solved by utilizing user-defined fields (such as the reference field in FAS) so that expenditures could be tracked within account.

The sponsored program track file, built in-house, captures most required information, but data entry is cumbersome, there are no edits (so that data entered frequently does not match FAS), data must be entered multiple times in multiple places, and effort reporting is problematic - it is a paper-based, substantially manual process. The inclusion of track file data in the information warehouse has improved access to information and the ability to generate needed reports, especially for end-users in the departments. Nevertheless, the current system is extraordinarily inefficient and cannot take advantage of recent developments by the sponsoring agencies to automate through a WWW interface the grant process from submission of application to award of funding.

The fixed asset system currently in place at the University is a pc-based system with limited reporting capabilities. The system does not interface with any other system at the university.

Many of our financial systems rely on aging technology. It is only a matter of time before this aging technology becomes obsolete and renders the system useless.

Since our financial systems rely on mainframe technology, some user-friendliness is sacrificed. None of our systems have a common look and feel, and many users feel that they must exert a lot of effort to learn how each system works. In addition, the University does not have a comprehensive training program to ensure that users can obtain the data they need in order to conduct business every day. Remote access to mainframe applications is also a real issue in the user community. A practical case in point: most users are unable and/or unaware of how to print snapshots of financial reports at their local printers, and end up abandoning this important tool. Many of these issues can and will be addressed through the new World Wide Web (Web)-based technology.

Human Resources and Payroll Systems

Personnel costs constitute more than 70% of the university's state­funded education and general budget, and the percentage is as high as 90% in some academic units. The processing of employee transactions, including hiring, paying, and recording changes in status, involves large numbers of employees throughout all units of the university.

One recent change in the procedures used to process employee transactions has produced substantial efficiencies for both central administrative offices and "end­user" departments. The on­line employment system for posting and hiring into classified positions has reduced noticeably the time, effort, and volume of paper required both in the hiring department and in the department of human resources.

In addition, the university enjoys a high rate of success in paying its employees correctly and on time. Over the past year, however, maintaining that level of success has demanded a considerably greater effort on the part of a significant number of people. While acknowledging the potential benefits of a well­designed and fully­functioning on­line appointments/payroll system, end users representing most of the schools as well as the library, summer session and the division of continuing education were quick to describe the difficulties engendered by the hybrid human resources (HRS)/ payroll system operating at the university today. In the view of most of the end­users we met with, working with the current systems ­- defined as the HRS, the on­line appointment system on the AS400, the PPY, and the interfaces written to make the old and new components work together -­ is more cumbersome and time­consuming, more susceptible to errors, and more difficult to correct than the manual paper driven processes were. Why? A partial list of concerns includes the following:

1. The steps required to enter transactions, cycling through a multitude of screens rather than a single one­page form, are more complex, less intuitive, do not fully accommodate all options needed, do not provide complete summary information in a format that can be reviewed easily and printed out, and cannot be corrected without backing up through the screens or, even, rejecting and returning to the initiator. Repeatedly, end­users asked why they were not consulted when the on­line system was designed.

2. It is very difficult to track the progress of an employee transaction. Rejected on-line entries in need of correction slowly cycle back to the originator through all the layers of approvers with no notification that a problem exists. There is still much communication by telephone between human resources, payroll, and end­users to "see what has happened" regarding a particular transaction. (Parenthetically, it is important to note that end users had overwhelmingly positive things to say about the dedication and helpfulness of the employees in HR and payroll in working through all of the problems users are experiencing with the current "hybrid" system. End users expressed sympathy and concern that the recent changes in the HR/payroll interface had also complicated the work of the staff in those departments.)

3. Data is being rekeyed somewhere down the line after initial entry by the end­user, so that errors can be -­ and are -­ introduced.

4. Users cannot extract from the HR/payroll systems the information they need or the formats they require. Virtually all units maintain extensive shadow systems, each unique and each requiring extensive effort at the unit level. The inadequacy of the systems in generating reports and providing summary information is a widespread complaint.

5. The systems can not process transactions until the month in which they take effect. This creates huge backlogs to be processed, particularly in September, December, and January, producing unreasonable workloads and deadlines for affected employees, significantly increasing the likelihood of errors, and giving no opportunity to correct errors before pay has been deposited to bank account.

6. Many of the end users with whom we spoke noted that it actually takes more person­time, and more time of management personnel at the level of the operating unit, to process a transaction in the current environment than was the case with paper forms.

Users also pointed out that other decisions made centrally, understandably intended to streamline processes and save money, such as direct deposit and the move to a delayed bi­weekly wage payroll schedule, have produced completely unanticipated complications that have increased the workload not only for end­users' departments but for central administrative offices as well. The steadily increasing administrative burden imposed on units by recent changes in systems and operating practices was poignantly illuminated by the end­users' complaint that the on­line system is not accessible to them after 6:00 p.m.! How many employees are working past 6:00 p.m. on a regular basis in order to keep up with the increased administrative workload?

It is worth noting that end-users displayed a high degree of receptivity to electronic processing and a willingness to learn new ways. Their frustrations stem from the inadequacies of the systems to address unit needs while complicating their work. The clear message we received was that 1) when new systems are designed or business procedures are modified substantially, end­users should be active participants in the design process and the evaluation of the impact of those changes, 2) new systems should be more, not less, efficient than the systems they replace, and to insure that they are, 3) new systems should not be put into production before they work with a high degree of satisfaction on the part of all constituents involved.

The technical experts with whom we met are experienced long­term employees with detailed and intimate knowledge of the PPY (some helped to install it in 1976!) and the HRS systems. In our meeting with them, they echoed and clarified a number of the concerns raised by the end­users.

While the on­line transactions system in HRS has created operating efficiencies for the department of human resources ­- significantly reducing the need for key­punch operators in ITC, speeding processing time within HR, enabling HR employees to be cross­trained to handle all types of transactions -­ the payroll department has experienced an increased workload and greater complexity and frustration generated by the need to work with both systems (HRS and PPY). Payroll employees must now refer to HRS screens and printouts as well as payroll microfiches. Multiple transactions with a single effective date can be entered into the HRS simultaneously, while the PPY requires each change to be entered and processed in separate batch jobs, over a period of days. While some technical experts expressed the hope that error reconciliation would be easier when payroll is in HRS, and thought that the system would be able to handle the forward loading of future transactions, they remained concerned that the HRS system ­- as it is currently designed -­ forces payroll personnel to scroll through many screens to obtain information which the employee really needs to see "all at once" in order to accomplish a task. This drawback would force payroll employees to continue to need microfiche in order to see all needed information at a glance, a cumbersome requirement that parallels end­users' dissatisfaction with multiple screens in place of a single page electronic form.

Technical experts launched a heated discussion of the demands they face, relative to the resources the university has made available to meet those demands, when queried as to the prognosis for rapid completion of the HRS and putting the PPY out to pasture. The existing technical staff in human resources, payroll, and ITC have been charged with responsibility for both maintenance of the existing systems as well as development of the new system, with only very modest increases in people resources for the work to be done on the University (as opposed to Medical Center) side. A number of recent changes have added to the workload of managing the PPY -­ new health plan, delayed pay, decentralization initiatives, automatic deposit, and frequent changes in IRS policies and reporting requirements. In addition, a flurry of new projects (Information Warehouse, E-forms, process simplification initiatives) have diverted staff resources in core administrative departments away from the HRS development effort. What seems most needed is a firmly established set of institutional priorities and a commitment to bringing projects to a greater state of completion before putting them into production. We need to do fewer things well, rather than many things half­way. The current practice of taking on more projects than we can devote adequate resources to, and the related practice of [putting half­developed systems into production] phasing implementation of system components into production, create the double bind of increasing the maintenance effort needed to make incomplete systems function reliably, while imposing on those same technical experts the continuing burden of completing the unfinished development work.

The technical experts pointed out that both the PPY and the HRS have been highly customized for in­house requirements, some mandated externally and some determined by the university's particular operating practices. Telling is the fact that no more than 20% or so of the existing HRS system is the original Dun &Bradstreet code. The remainder has been developed in­house. The experiences of technical experts over time raise reservations about how far the university would or could go in changing existing business practices to accommodate a "plain vanilla" system.

The managers who serve as stewards of the HRS and payroll systems view the current situation with respect to these systems from very different perspectives. From the standpoint of the department of human resources, the evolution of the HRS over the past 5­10 years, with the ongoing development of automated processes and procedures, has produced a much better environment in which a staff 50% smaller than it was 5 years ago is able to handle effectively a much increased volume of business. Although there is recognition that the system does not currently meet all the needs of end­users, meeting that need is deemed a matter of time, not of ability to achieve the modifications users require. And though reporting directly from the HRS database is not now possible, nor is it envisioned for the future, the data warehouse is viewed as the solution to users' data and reporting needs.

From the point of view of those managers still maintaining the old payroll system (PPY), the merger of HRS and PPY has measurably complicated the work of the payroll staff. Staff must look in two separate places to obtain the information they need. There is less detail available now than was contained on the old paper "profile," so that payroll employees must call HR for clarification. Some information is being transferred from HRS to PPY electronically, while other information must be transmitted in paper format or rekeyed. Because of the various ways information is now transmitted from HRS to payroll, it is easy for transactions to be processed out of sequence. The error rate is up substantially, and errors are hard to detect until after they happen.

Although it is slow, paper intensive, and dependent on many manual calculations, the PPY, like the HRS, has been customized over the years to do many things the university has required it to do. While there is no question about the desire to automate payroll functions, there are questions about whether the payroll module in HRS, without significant modification, will accommodate the internal and external requirements placed upon it. (The HRS, for example, permits a limited number of deductions, does not accommodate other than 12 month appointments, and can report on a calendar year basis but not a fiscal year basis). Stewards of both HRS and PPY note that it has been the university's practice to modify systems extensively to meet both externally and internally imposed requirements. There is widespread concern that the university is not really prepared to make the sort of far­reaching changes in business practices -­ indeed, perhaps does not really comprehend the scope of changes that would be necessitated -­ in order to install a system "off the shelf" with only [minor] "tailoring" and no customization.

Stewards of HRS and PPY are equally eager to "put the PPY out to pasture." When queried as to what it will take to make this happen, the managers of the payroll system echoed the concerns expressed by the technical experts. A number of modules must be built, purchased, or modified ­- and then installed -- before the HRS can take over completely the functions of the PPY. These include a benefits module, a time capture module, a time entry and leave module, a fiscal file, a reconciliation file, and an MEA/TDA module. Progress in developing these modules, however, has been substantially affected by the redirection of university staff efforts toward new projects, including process simplification, the information warehouse, electronic forms, etc.

There was substantial commonality among the concerns raised and recommendations offered by end users, technical experts, and stewards of the human resources and payroll systems. They can be summarized as follows:

1. The university needs to [establish - and abide by - ] better integrate and coordinate the various processes (including process simplification, ITCs internal re-engineering initiatives, and administrative systems development) for setting priorities and allocating people resources for projects involving systems modifications and or replacement.

2. The university needs to allocate sufficient resources, not only to ITC, but to the functional areas that serve as the stewards of the systems (Payroll, Purchasing, HR, etc.) to enable projects to be completed in a reasonable time frame ­- by reducing the number of projects undertaken at a given time, or by allocating additional resources to address a more ambitious schedule. Once developed, new systems must be adequately resourced for implementation and maintenance.

3. New projects need to be more fully developed, tested, and modified in response to feedback from pilot users from all constituent groups before they are put into production.

4. In addition to moderating the pace of new project development, the university needs to devote much more time and resources to training employees in the use of systems, both new and existing. Better training can help to reduce errors, enable employees to obtain needed information and solve problems more independently, and will inevitably elicit valuable feedback from users with respect to the quality of a system's design.


Most of the components of the current systems that were reviewed do accomplish, from an operational point of view, what they need to do. The level of functionality we enjoy is largely the result of having modified the systems extensively over the past 20 years to adjust to changing internal and external business requirements and regulations. Counterbalancing this obvious strength is the fact that some of the systems, because of their age, are paper intensive, require significant manual calculation, are incapable of communicating with modern equipment like laser printers, require significant technical maintenance because of all of the "fixes" that have been implemented over the years, and, ultimately, may be more costly to continue modifying than to replace.

Another characteristic noted to one degree or another in most of the systems was their lack of "user-friendliness," primarily from the standpoint of users' ability to access needed data and to generate reports from data contained in the systems. This weakness can also be attributed to the age and nature of the systems, older mainframe applications that were designed to serve the needs of central administrative offices only. The university has responded positively, however, to this concern, and the development of the Information Warehouse promises to mitigate substantially operating units' concerns regarding access to centrally maintained data for query and reporting purposes - at least for some systems.

The ubiquity of school and departmental shadow systems demonstrates, on one hand, the inadequacy of current systems to satisfy users' needs for complete, current, and accurate information for management and planning. On the other hand, it also highlights units' differing practices and information needs which we may decide cannot be accommodated effectively in their entirety in a central institutional database system. One approach to addressing diverse information needs is to insure that new systems contain user-defined fields which would enable each unit to add to the central database information of particular value to that unit only.

The university has embarked upon a number of projects in the past two years which hold great promise for increasing the efficiency and effectiveness of administrative operations throughout the university - including process simplification projects, on-line processing of employee transactions, design of web-based electronic forms, and the development of the information warehouse. However, many people we talked with have the perception that our ambitions, although well-intended, far outdistance our capacity to manage in a reasonable way the array of projects we have recently undertaken. Existing personnel resources have been stretched too far, and we have put some systems into place before they were tested fully and functioning well. As a consequence, users of the systems, as well as those responsible for maintaining the systems, have had to contend with system design flaws that have increased workloads, reduced productivity, and hampered efforts to complete development of the systems that were put into production prematurely.Perhaps as a consequence of insufficient resources and the pressures associated with an overly ambitious project schedule, we have not always invested sufficient time in obtaining end-user input from administrators and front-line staff in the design and testing of new systems, nor have we invested sufficient resources in training employees to use our systems effectively. Training needs to focus on problem solving and understanding what the data elements in a system are, not just how to input data into a system or read parts of a canned report.

It is important to note that the university is blessed with many highly qualified and intensely dedicated employees in technical support and on the front lines of day to day operations, on whom we have placed extraordinary demands. Throughout our discussions with users, stewards and technical experts, we were continually impressed with the quality of our people.



Allocate the resources to provide effective training in the use of all administrative systems. To be truly effective, a regular schedule of training activities should provide ongoing opportunities for employees to test and increase their understanding after working with a system for a period of time, and especially when changes are made to the system.


Actively solicit input into system design and system change decisions from ALL affected constituent groups (technical experts, system stewards and end users). It is essential that we calculate the impact of systems changes on the way the end user does business, especially as more and more administrative functions formerly handled centrally are delegated out to the operating units. Pressures to move quickly to select and install new systems must be balanced against the critical need to devote sufficient time and effort up front to assess the needs of all affected constituents, particularly those of the end-users of those systems.


Establish priorities and a realistic schedule for completing projects already underway. Devote the necessary resources to accomplish within a relatively short time-frame recommended modifications to the e-forms, information warehouse, and on-line employee transactions projects. The productivity gains to be derived by making these three applications function effectively and by training employees thoroughly in their use are substantial.


Examine policies and procedures at all levels that are perceived as impediments to efficient and effective operations. Determine which can be changed or dropped, and do so. If policy or procedure change is not possible, investigate possible actions that can compensate for the negative impact of the policy or procedure.


The university should evaluate carefully the pros and cons of supporting multiple desktop platforms (DOS, Windows, MAC, UNIX, etc. ) as opposed to adopting a standard hardware and software platform for administrative uses only. Imposing a standard might require the institution to assume centrally the cost of moving non-standard employees to the standard, and would produce, temporarily, significant demand for training. On the other hand, limiting product choices to those developed for all desktop platforms is likely to restrict substantially our options, may result in the purchase of less than optimal solutions for administrative systems, will probably require a greater maintenance effort to keep systems functioning, and creates problems when system upgrades are not available simultaneously on all platforms.

Recommended Replacement of Existing Systems

HR/Payroll is, in the minds of most people we talked with, clearly the most problematic system, from an operational standpoint. While members of Study Group 1 do not feel qualified to judge whether to replace or to complete work on the HRS, it is imperative that we move as quickly as possible to a single HR/Payroll system and retire the PPY. The burdens imposed by -- and the productivity losses associated with using and maintaining -- the current "hybrid" are very costly to the university.

Also high on our collective lists for replacement are a University Budgeting System and a Departmental Budgeting and Accounting Package or Module. It was also noted that it may not be possible to graft new university budget and departmental accounting systems onto an old General Ledger (i.e. FAS), thus bolstering the priority for replacing it as well.

Although we will, inevitably, find reasons to modify and, eventually, replace the Integrated Student Information System, it satisfies, more than any other system, the needs of the various constituencies using it and thus receives our lowest priority for replacement.

The constituent groups with whom we met -- stewards, technical experts, and end users -- approached the evaluation of the strengths and weaknesses of the current systems primarily from an operational point of view. These are the people who use, and maintain, these systems on a daily basis. Thus, our priorities reflect primarily operational needs and concerns. Study Group 1 acknowledges readily that there are other important criteria which must be taken into consideration in determining a priority for replacing these systems. Certainly the "Year 2000 Problem" and the matter of system compliance with the Year 2000 make this issue a critical -- if not the most critical -- criterion in determining the order of system replacement. (Study Group 1 did hear some discussion indicating that because the CAPPS system and, possibly, other older systems may require substantial effort to be made Year 2000 compliant, they should be placed at or near the top of the list for systems replacement.) Because our Study Group does not have the expertise to evaluate this issue at the level of individual systems, and because the university has already appointed a task force to address this issue, we will defer to others the task of factoring in this and other technology issues in determining the order in which systems should be replaced.

Regardless of the order in which systems are replaced, Study Group 1, speaking on behalf of the many individuals who shared the needs and concerns of their units with us, urges the university to make a concerted effort to gauge the impact of system changes on central and unit operations, and in tandem with undertaking replacement projects, devote sufficient resources to correcting sooner, rather than later, the worst of the operations problems within existing systems.


Return to the Integrated Systems Project Home Page

Site maintained by
Updated January 12, 1999