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 all—or even most—of 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 can’t change its operations and procedures to fit the idiosyncrasies of a commercial system. The reality is that most academic purchasers must customize systems after they’re installed, either using their own programmers or expensive consultants.

The Conclusion
The university concluded that the best course was to build its own system. Although it had not thought of software development as one of its core competencies, the university had been modifying and customizing programs for years. And when you customize and modify, what are you doing? Software development. If the university could fix someone else’s system, why couldn’t it design its own system—one that would meet its unique needs, in all respects and from its first day of operation? The programming would be done in-house by systems analysts and programmers in Computing Services. They would use the database manager purchased for the university’s student information system. They would program in Natural, a very efficient programming language for which the university had, fortunately, a local guru, an analyst who quickly built a tool set that other programmers could easily be trained to use.
Introduction
So Many Needs
Any Capability I Want?
A Revolution is Sparked
Modules Away
1, 2, 3 Testing, Testing
Did Someone Mention Mistakes
Reaping the Rewards
But the new system would not be designed by programmers. They don’t know, and it is not their job to know, the day-to-day functions that an administrative software system has to perform. The people who know that are those whom the university came to call the application owners: the budget managers, the purchasing agents, the travel coordinators, the payroll specialists, the leave coordinators, the benefits managers, the classification and compensation analysts, and the taxation experts—in short, a large part of the Finance and Administration staff. They, too, would be part of the development team, designing the specifications that the new system would have to meet.

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 dean’s 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.

Back to Intro     Prev Page     Next Page