Spring/Summer 2000 - Vol. 51, No. 1
Upgrade It? Replace It? Or Start a Revolution? An Adventure Story from the University of Arkansas
|
Any Capability I Want? As the university contemplated replacement of its existing HR and financial software, it asked what, ideally, a new software package would do. It came up with a lot of answers. The new package would eliminate the need for redundant data entry and the errors and inconsistencies that can result. It would control access to data that should be kept confidential but make all other data widely available for analysis, planning, and reporting, providing quick access and production in multiple formats. It would make transactions that require one or more approvals easy to review and the person who had approved them and the date on which they had occurred easy to determine. It would eliminate paperwork and paper records. It would allow efficient processing of all types of business and personnel transactions. Cost was certainly an important consideration, but the university knew that if it were the only criterion, both present and future options would be limited. Should investment in a technology be based on the speed of its payback or on the meeting of its users needs? Corporate America looks at how well it can meet the needs of its customers and not solely at how quickly it can recoup an investment. Therefore, the university concluded that the meeting of users needs would be its primary goal. Achieving this goal might actually create cost savings. The university examined existing HR and financial software packages and found nothing that met allor even mostof its criteria. In the early 1990s there were far fewer choices than there are today. But even today, the majority of products available were originally designed for business and industry, not academia, though their vendors may routinely promise to and may sometimes make modifications to meet higher education requirements. Commercial programmers seldom understand these requirements, and a university simply cant change its operations and procedures to fit the idiosyncrasies of a commercial system. The reality is that most academic purchasers must customize systems after theyre installed, either using their own programmers or expensive consultants. The Conclusion |
There were still others whom the university believed had to be involved in the development effort. Some call them constituents and some call them customers; they are the everyday users throughout the university. The system would meet the needs of the work-study coordinator, the secretary in the philosophy department, the budget manager in the engineering deans office, and the construction coordinator in the physical plant office as well as the needs of the clerk who issues parking permits, the researcher ordering a million-dollar piece of equipment, and the faculty member traveling to a conference. It would accommodate the reporting needs of the affirmative action office, and the bid requirements of the state purchasing department, the methods for budgeting fringe benefits, the special requirements for processing of grants and contracts, the data needs of retirement program vendors, and the methods for making premium allocations for several health insurance plans. It would also accommodate state and federal tax requirements, I-9s, drug-free workplace acknowledgements, non-resident alien taxation treaties, non-salary compensation administration, and other campus-specific needs.
|